Re: mozilla-rootcerts woes

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

> Date: Mon, 09 Oct 2023 21:12:28 -0400
> From: Greg Troxel <gdt%lexort.com@localhost>
> 
> From a public discussion on current-users@, I now believe that
> mozilla-rootcerts and mozilla-rootcerts-openssl are:
> 
>   installing both email and server certs (which I think is probably ok
>   and we should fix DESCR)

Strongly disagree, at least for what goes in /etc/openssl/certs.

This is absolutely not OK and the package is broken with a security
issue right now.

mozilla-rootcerts was clearly intended to process _only_ the CAs for
server authentication, i.e., TLS, by searching only for the
CKA_TRUST_SERVER_AUTH and not CKA_TRUST_EMAIL_PROTECTION or
CKA_TRUST_CODE_SIGNING designations.

And this intent, documented in DESCR, matches application needs:

- Loads of applications rely on /etc/openssl/certs for TLS validation.
- There's no way to tell OpenSSL that some CAs in it are not for TLS.
- Very few applications are likely to make the mistake of relying on
  /etc/openssl/certs (on NetBSD, /etc/ssl/certs on FreeBSD,
  /etc/pki/tls/certs on Fedora) for S/MIME validation.
- Even if they do, TLS validation is immeasurably more important than
  S/MIME validation.

For context, the other discussion is here, including expanded
commentary around /etc/openssl/certs usage and the priorities of TLS
vs S/MIME:

https://mail-index.netbsd.org/current-users/2023/10/11/msg044518.html

In the case of mozilla-rootcerts, it was a mistake in the parsing of
the CKA_TRUST_* lines that led to this bug.

> Would somebody who is an expert.rootset.mozilla like to dig in and
> assess/fix?

The correct fix is to treat CKT_NSS_MUST_VERIFY_TRUST as untrusted,
not as trusted.

Better: Treat _only_ CKT_NSS_TRUSTED_DELEGATOR as trusted and reject
anything else -- with a noisy warning if it's something new -- so we
are less likely to be screwed up by another renaming.  Should also
treat anything _without_ any CKA_TRUST_SERVER_AUTH line at all as
untrusted.  This is what security/ca-certificates does, and what the
certdata.awk import script for certctl(8) in NetBSD base now does.

Background: At some point a few years ago, these labels were shuffled
   around in nss, ditching the old CKT_NETSCAPE_UNTRUSTED, and the
   script never got updated.

   The three-way distinction between `trusted', `must verify', and
   `not trusted' is about merging databases, with `must verify' as a
   neutral element: (trusted * must verify) = trusted, (not trusted *
   must verify) = not trusted, (must verify * must verify) = must
   verify.

   The distinction between CKT_NSS_TRUSTED and
   CKT_NSS_TRUSTED_DELEGATOR is that CKT_NSS_TRUSTED means trusted for
   the listed purpose but not as a CA, while CKT_NSS_TRUSTED_DELEGATOR
   means trusted as a CA to issue certificates for the listed purpose.

CAs with DISTRUST_AFTER in certdata.txt, which have narrower validity
periods than the certificate asserts, should also be excluded, because
there's no way to represent the narrower validity period to OpenSSL.

> Can anyone shed light on how mozilla's concept of server/email maps to
> concepts in pkix and API calls in openssl?

Although it's hard to find a clear statement of the meanings of all
these labels, I believe this boils down to a very simple rule:

- If certdata.txt has a line in the trust section for a CA saying

  CKA_TRUST_SERVER_AUTH CKT_TRUST CKT_NSS_TRUSTED_DELEGATOR

  then Mozilla trusts that CA to issue TLS server certificates --
  possibly subject to a narrower validity period than the certificate
  asserts, according to the DISTRUST_AFTER lines.

- If not, it doesn't, and it is a security bug for us to put it in
  /etc/openssl/certs.  If a CA without this line issues a certificate
  authorizing extended key usage including server authentication,
  Mozilla's assessment is that applications shouldn't believe it.

Same deal for CKA_TRUST_EMAIL_PROTECTION and extended key usage
including email authentication, &c., except that there is no standard
location for applications to find S/MIME trust anchors.  We could
invent a standard location like /etc/smime/certs if we care but that
should be driven by actual application needs which I haven't
catalogued -- only skimmed enough to decide it's very low-priority.