tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: [PATCH] HTTPS/TLS CA certificates in base



Overall I like this.  Thank you for listening to the various comments
and coming up with a mechanism that is configurable for almost all
possible policies that have been expressed.


I'd like to see three things handled (which might be already):

1)

  a way for a user to install a CA cert (as a trust anchor -- I think it
  would be good for docs to use pkix terminology) that is not part of
  the mozilla root set, such that as updates/etc. happen, the trust
  anchor set remains
    union of
      user-configured
      mozilla set, if opted into, minus those excluded

This is just code and I don't care if the user has to put the cert in
/etc/openssl/manual-trust-anchors or someplace like that to be available
for unioning, which would make certctl be able to just write /certs.
I am guessing your patch already handles this somehow, but I wanted to
comment quickly before reading this since I have ranted so much.

2) On installation, either

  a yes/no question "do you want to configure the Mozilla root
  certificate set as trusted"?

or

  a "trust mozilla root certificate set" as a yes/no option in
  configuration where you turn on sshd/ntpd, and I don't really care how
  it defaults.


We should absolutely install them in their own dir always; this is only
about whether the certctl.conf file has "include mozilla" or doesn't,
and is thus super easy to change.

3) If a user wants to configure (as an example)
   The US DOD root (a "real CA" not in the mozilla set)
   a personal CA that they created
   Let's Encrypt, and 8 other specific CAs from mozilla
   
then that should be supported somehow in the certctl config file.  I
suspect you've enabled that, and it's just omitting the "use the mozilla
set" and adding lines for "use this" and "use that".


minor comments:

A) I think it's fine to only have "postinstall fix" run certctl in the
DESTDIR=/ case and not at all urgent to address.   This is sort of like
how we do'n build locate/man db etc. in images but only on real systems.

(Alternatively we could run certctl rehash at boot if certctl=YES,
default YES and skip it from postinstall.  I have not thought through
pros and cons.)

B) There is talk of enforcing validation, but we already enforce
validation with an empty list.  I think the only change is installing a
bunch of CAs as trust anchors (in a manageable way), and there is no
change to validation.  If I'm confused on this point please tell me.


C) The openssl nomenclature /etc/openssl/certs is confusing because it
blurs what is a certificate and what certificates are trust anchors; it
really (I think) means the latters.  I realize that few understand this
naming distinction, but a CA cert is just a cert whose private key can
sign other certs, and you may or may not care, unless it is a trust
anchor or reachable from one.


Home | Main Index | Thread Index | Old Index