Re: Call for testing: certctl, postinstall, TLS trust anchors

[Greg Troxel <gdt%lexort.com@localhost>]

Taylor R Campbell <riastradh%NetBSD.org@localhost> writes:

>> Date: Sun, 08 Oct 2023 10:54:13 -0400
>> From: Greg Troxel <gdt%lexort.com@localhost>

> See above: if you know of applications that rely on /etc/openssl/certs
> for S/MIME, and it's not just a joke (which most open-ended
> interorganizational use of S/MIME that I'm aware of is --
> intraorganizational uses managed by a corporate IT department purely
> for internal or partner use aside), I'm curious to see.

I can't point to use of /etc/openssl/certs, but I get mail from random
people (mostly in .eu) on public lists with s/mime signatures, from
public CAs.  And, I have experience with actually sending S/MIME mail
back and forth with people working at a different government
contractor.  I believe this was with public CAs; the guvvies have certs
from the DoD CA.

>>   4) This is all not obvious, and
>>      a) It's not the least bit clear that the right thing is happening.
>>      b) I expect ~nobody to understand this.
>
> Is any of the text in the certctl(8) or hier(7) man pages unclear
> about this?  I tried to clarify the purpose of /etc/openssl/certs for
> TLS trust anchors specifically in that text.

What's not obvious is that if you know that pkix is not just about TLS,
and are a bit unclear on how mozilla deals with things, are a bit
unclear on whether openssl can do pkix validation in general, and how
one would do that for non-TLS (but know that obviously you can), then
it's not entirely clear.

What's missing is a remark that mozilla publishes two lists, one for
"servers" (which today means TLS) and one for email, and that certctl by
default configures the server list into openssl.  And that it will
therefore be used for all validation operations.  Which is pointing out
that the purpose restriction on mozilla's set isn't aligned with openssl
behavior (after all it's for nss), or that I don't understand something
else.

>> Looking in /usr/share/certs/mozilla, it continues to be non-obvious.
>> The idea that 'all' has "untrusted CAs" seems crazy; if they aren't
>> trusted, why are they in the root set, which is by definition the set of
>> CAs which meet the rules and are therefore trustworthy?
>
> `all' has everything in certdata.txt.
>
> `server' has only what Mozilla has chosen to trust for TLS.
>
> `email' has only what Mozilla has chosen to trust for S/MIME.

So yes, the "mozilla root set" contains things which are not eligible to
be in the set of configured trust anchors, because that is only things
in the set with a certain flag.  This is really surprising and I had no
idea.  I suspect many others have the same sorts of feelings.

> Yes.  The certdata.txt format has a way to say that trust anchors are
> fit for code-signing, so for completeness I exposed that via the
> directory /usr/share/certs/mozilla/code, but (a) there are no trust
> anchors in certdata.txt that use it, and (b) there is nothing in
> NetBSD that would use such trust anchors anyway.

ok, but as more than a nit, the customer set for openssl configuration
is any program anybody would build on NetBSD, not just the base system.

> These exclusions also match my knowledge of the history:

That all makes sense.

> As far as I'm aware, S/MIME is only ever seriously deployed within a
> single organization at a time (or a closed set of partnering
> organizations).  So I don't expect anything about it to seriously work
> out of the box and I have no idea what public CAs do about it.

Public CAs issue email certs to people just like they issue web server
certs.  It all works just about as well as TLS certs, in that with a
hundred CAs, it's hard to really believe anything with high assurance,
but it mostly works.  I am unclear on today's practice but in 2016 it
was normal in the big company world, the kinds of places that just could
not cope with OpenPGP.

> I'm prioritizing effort on TLS, but I _installed_ the email
> certificates as pem files under /usr/share so that they're available
> in case someone wants to do something with them like declare
> /etc/smime/certs as the place to find the trust anchors and configure
> them with certctl(8) using a different config file.

This is the part I don't get, but I need to look at pkix, to see if
there is standards support for this "different set of trust anchors
depending on flavor".

> The situation with security/mozilla-rootcerts is actually worse
> because it doesn't interpret the DISTRUST_AFTER annotations, so CAs
> that _were_ trusted for TLS but have _now_ been sunset are still
> included.  That was news to me too...

Grepping and sort/uniq:

  25 CKA_TRUST_SERVER_AUTH CK_TRUST CKT_NSS_MUST_VERIFY_TRUST
   1 CKA_TRUST_SERVER_AUTH CK_TRUST CKT_NSS_NOT_TRUSTED
 144 CKA_TRUST_SERVER_AUTH CK_TRUST CKT_NSS_TRUSTED_DELEGATOR

  53 CKA_TRUST_EMAIL_PROTECTION CK_TRUST CKT_NSS_MUST_VERIFY_TRUST
   1 CKA_TRUST_EMAIL_PROTECTION CK_TRUST CKT_NSS_NOT_TRUSTED
 116 CKA_TRUST_EMAIL_PROTECTION CK_TRUST CKT_NSS_TRUSTED_DELEGATOR

 165 CKA_NSS_SERVER_DISTRUST_AFTER CK_BBOOL CK_FALSE
   3 CKA_NSS_SERVER_DISTRUST_AFTER MULTILINE_OCTAL

so one has to parse DISTRUST_AFTER at build time, and the contents will
change later?  Or is our approach to say "if it's DISTRUST_AFTER at all,
just say no"?  Or something else?

>> Given the man page, I expected to have an empty /usr/openssl/untrusted
>> directory but that is not in any of the sets.  Perhaps the idea is that
>> it is created on demand, but I didn't figure that out from the man page.
>
> It is created on demand.  Not sure it's worth including in sets, just
> more trouble with set lists for an empty directory with no
> user-serviceable parts.

OK, but it would be nice to be in FILES to say that it has
certctl-private data that has the state necessary for the untrust
mechanism.

> It is very much an implementation detail and I didn't want to put too
> much thought into the details.  The really important thing is that the
> interface work so that we can distribute SAs that give remediation
> steps like:
>
> # certctl untrust TrustCor_ECA-1.pem
>
> and they will work.  I am not committing to the implementation because
> the expedient thing was grody but good enough for now, and I may want
> to change it.

Sure, am just wanting the user to know that this directory currently has
state.

Another thing that is not 100% clear is that untrust, in addition to
storing state, removes it right now.

The use of "cache" is puzzling, as this is creating the directory that
openssl uses, and there is no mechanism to fault in things.  It feels
more like "certctl reads source paths and state from untrust, and
prepares a directory of trust anchors".  But maybe it's just me, and my
words confuse more than one person!

>> What's not obvious and is part of the interface is that if I untrust a
>> cert (e.g. because I don't believe that the CA is sound), then when that
>> CA cert is updated in the mozilla set, will be untrust persist, or not?
>> I am guessing not, and this is hard to fix but I think it's important to
>> tbe clear on "what does it mean to untrust a cert", because people may
>> think it does what they want instead of more narrowly what it says.
>
> If you do `certctl untrust TrustCor_ECA-1.pem', then it will remain
> untrusted on update.

And if TrustCor_ECA-3.pem is added (because in this example mozilla
thinks they are ok and I don't) as part of normal
new-root-cert-every-10-years, then that will get picked up.  So it is
really removing a particular named cert, not removing a CA.

>> What's not obvious is a recommended place to put a CA cert (not in the
>> mozilla set) that I wish to have as a trust anchor.   I realize from
>> reading that it can be literally any pathname on the entire system.  But
>> certctl says "you can no longer use /etc/openssl/certs like used to".
>> 
>> I think I lean to /etc/openssl/manual, but that is probably just me.
>
> I figured that you might install other trust anchors as static data
> files from packages, e.g. /usr/pkg/share/gdt-rootcerts, and link them
> in through another `path' directive in /etc/openssl/certs.conf.

Sure, if using packages.  But there's the usual sysadmin manual config,
like putting things in etc.   It's clear paths can be anything.

>> Not really, but certctl untrusted man page paragraph is confusing.  It
>> should simply say have been excluded and the "so that" should be omitted
>> or at most a perenthetical remark.   It feels like opencoding the doc
>> for another command as if it is not just a reference, and I find such
>> things confusing.
>
> How about this?
>
>      untrusted   List absolute paths to certificates that have been
>                  excluded by certctl untrust.  certctl rehash will not
>                  put these in certsdir.  Paths are printed one per
>                  line, encoded in vis(1) format to escape any shell
>                  metacharacters.
>
> And, correspondingly:
>
>      list        List absolute paths to trusted certificates.  certctl
>                  rehash will populate certsdir with these.  Paths are
>                  printed one per line, encoded in vis(1) format to
>                  escape any shell metacharacters.

I like that.

>> What is not clear is why the email ones are left out, and if they'd be
>> not used for server validation due to key usage flags, or the rationale
>> for the policy shift from the pkgsrc package approach.   I'm not saying
>> it's wrong, but I had viewed this as "do the same thing, but move it to
>> base and change the mechanism", and now it's clear to me that it's more.
>
> I'm not sure it's as much a policy shift as implementing the policy
> that was suggested in the DESCR and implicitly assumed by
> applications, and then realizing mozilla-rootcerts was doing it wrong
> all along.  From DESCR:
>
>    It also provides a script, mozilla-rootcerts, which can be used to
>    install the root CA certificates distributed by the Mozilla Project
>    into a location that makes them usable by TLS implementations, extract
>    them to the current working directory, or rehash the existing
>    certificates.
>
>    NB: This package provides certificates, but does not as a consequence
>    of installation place them in a location that makes them immediately
>    usable by SSL/TLS implementations.

There's a lot of historical baggage, and it's confused because the
mozilla set, I now understand, is both server and email.  Fair point
that this is the existing text.

I'm fine with leaving this all for another day, but would like a

  While the mozilla root set also contains a list of CAs that are
  trusted for validating email (S/MIME) certificates, the default
  certctl configuration only installs CAs that are trusted for
  validating server (TLS) certificates.

which clues in people about this split, which I bet is widely
non-understood.