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.
