Re: mozilla rootcerts in base

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Tue, 29 Aug 2023 08:11:00 -0400
> From: Greg Troxel <gdt%lexort.com@localhost>
> 
> Taylor R Campbell <riastradh%NetBSD.org@localhost> writes:
> 
> > (And as a side note, I noticed that mozilla-rootcerts includes a bunch
> > of trust anchors designated for S/MIME, not for TLS validation, so
> > those shouldn't be put into /etc/openssl/certs...)
> 
> Why do you say that?  openssl can be used as a library for things less
> than TLS, certainly including pkix validation.  The trust anchor certs
> ought to have usage extensions that limit this, and validation calls
> should be specificying usage.   After all, this going in is a decision
> to drink the pkix koolaid.
> 
> Why is the base system setting up for TLS only, vs pkix validation in
> general?  TLS is just one specific case.

Most applications that need trust anchors use them for TLS validation,
and the recent changes in base are designed to enable that.  This
isn't about drinking PKIX koolaid in some grandiose formalization of
trust -- it's just about TLS validation.

The formal PKIX limitations don't work the way I think you think they
do:

- A certificate can formally assert (via basic constraints and key
  usage) that its subject is authorized to sign certificates or sign
  messages.

- An end-entity (non-CA) certificate can formally assert (via extended
  key usage) that its subject is authorized to authenticate servers,
  clients, email, code, &c.

- But there is no language for a certificate to formally assert that
  it is authorized to sign certificates that are only authorized for
  email.

So although there are CAs in Mozilla certdata.txt used for email
(maybe by Thunderbird), there is nothing in the CA certificate itself
that discriminates between email and TLS validation for its end
entities; that's in additional data alongside the CA certificate in
certdata.txt.

The ones that Mozilla trusts for signing TLS server certificates are
installed in /usr/share/certs/mozilla/server, and those are the ones
that certctl(8) is configured to symlink into /etc/openssl/certs by
default to expose a safe set of trust anchors for TLS validation to
applications.

That said, if you want the ones Mozilla trusts for email, they're
installed at /usr/share/certs/mozilla/email.  You could use certctl(8)
to manage a symlink farm at, say, /etc/smime/certs if you want, and
point your mailer at that.

There are other restrictions in certdata.txt too, and at
<https://wiki.mozilla.org/CA/Additional_Trust_Changes>.  What gets
installed in /usr/share/certs/mozilla is intended to conservatively
respect all of those restrictions.

> Agreed, but I think we probably should have
> 
>   mk/pkix-trust-anchors.mk
> 
 > which sets variables and then perhaps depends on something.  However, in
> the brave new world of "OS configures trust anchors" which we are
> arriving in as NetBSD does, this should ~always be the system-configured
> set, and never use the mozilla set within pkgsrc.  Except if it's asked
> for with a variable probably.
> 
> I think we should keep mozilla-rootcerts indefinitely, and allow people
> to set cert.conf to load from it instead of the set included in base.

That all sounds reasonable, except it should be tls-trust-anchors.mk.

There may be applications for other purposes than TLS, but the _vast_
majority of trust anchor users are TLS and we need to optimize safely
for those before overgeneralizing to the handful of niche applications
of PKIX for other purposes.  TLS is critical for everyone in the
modern world; S/MIME and PKCS#11 and whatever else, not so much.

If, as future work, you want to define a file hierarchy for trust
anchors for other purposes like /etc/smime/certs or /etc/krb5-pkinit,
and a scheme of pkgsrc variables pointing there on NetBSD or
/etc/pki/smime on Fedora to bake into packages, that's fine -- but it
must not get in the way of security and usability of TLS.

> Perhaps that package should omit the install script when built for an OS
> that has native management.

I assume you mean the sbin/mozilla-rootcerts command, or the
sbin/update-ca-certificates command in security/ca-certificates?

These can coexist with certctl(8) by putting `manual' in
/etc/openssl/certs.conf -- that minimizes the effort to maintaining
the existing management of the system on upgrade if it already uses
mozilla-rootcerts or ca-certificates.

> We have been mostly talking about openssl because that's what base uses,
> but there are multiple programs that can do pkix validation:
>   openssl
>   [openssl variants]
>   gnutls
>   gnupg2
>   qca2-qt5
>   p11-kit (it seems; see file:///usr/pkg/share/gtk-doc/html/p11-kit/trust.html)
> 
> 
> The big point that I take away is that there are a number of formats,
> perhaps just a symlinks/files method and a bundle method, for this, and
> I hope certctl already prepares both, even if openssl only uses one.

certctl(8) puts in /etc/openssl/certs:

1. .pem symlinks
2. hashed openssl symlinks
3. a concatenated bundle ca-certificates.crt

That covers OpenSSL, anything that scans for *.pem, and anything that
wants a single-file bundle.

> (I still don't want to do any of this pre-branch.  I think it's unhealthy
> to rush and I don't want to deal with any more churn/grief than is
> already going to happen for unrelated reasons.)

I agree, with one exception: security/hs-x509-system depends on
mozilla-rootcerts-openssl, which has always been wrong and is now
likely to cause trouble in practice.  So I think we should either
remove the dependency or make it conditional on NetBSD<10.  I expect
this should be fairly low-risk for 2023Q3.