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

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

I made a few changes to the documentation:

- Added /usr/share/certs/mozilla to hier(7).
- Reworded text about /etc/openssl/untrusted in certctl(8) to call it
  a private state directory.
- Reworded certctl list/untrusted as suggested.
- Reworded certctl untrust/trust to say `certsdir' and emphasize that
  they take effect immediately.
- Reworded description of `manual' in certs.conf to emphasize that
  certctl untrust/trust still update /etc/openssl/untrusted.
- Suggested /etc/openssl/certs.local in an example that has additional
  site-local certificates.  I didn't suggest /etc/openssl/manual
  because certctl(8) is still used to manage /etc/openssl/certs in
  this example, so `manual' is off, and it would be confusing to have
  `manual' off but then have an input called `manual'.

Can you read through the new hier(7) and certctl(8) man pages to see
if that helped to clarify things?


Regarding the interpretation of certdata.txt and /etc/openssl/certs, I
think we can boil all the subthreads down into a couple questions.

But first, I would like to stipulate that priority #1 here is secure
TLS validation.

- Everyone on the modern internet has to use TLS ubiquitously.

  There's all kinds of automation that relies critically on TLS
  validation for security; everything about the modern web depends on
  it.

- There's a serious, mature governance system for TLS CAs.

  The CA/Browser Forum has enormous industry investment, has mature
  standards, has serious audit requirements and observability like
  certificate transparency logs which can be verified on-line with SCT
  in OCSP stapling, and has a decade-long track record of enforcing
  requirements even against major industry players like Symantec whose
  business (including the historic Verisign business) was killed by
  failing audits.

The same cannot be said of S/MIME, even if there are users in large
organizations (mostly with IT departments that can configure managed
installations) -- most people have no contact with S/MIME and don't
rely on it for anything.

For governance, there appears to be a recently-formed working group of
the CA/B Forum for S/MIME -- formed only in 2020 with baseline
requirements drafted only last year, and I have no idea how much
investment the world has in it.

So supporting S/MIME validation is a stretch goal that absolutely must
not get in the way of secure TLS validation.  If getting secure TLS
validation means temporarily breaking some S/MIME users in pkgsrc, so
be it.  And that's aside from other purposes for trust anchors, like
CMS in other application protocols (e.g., pkg_add), which already have
their own mechanism to configure trust anchors.


All that said, I think the subthreads boil down to:

1. What is /etc/openssl/certs used for today?

   => I'm confident the vast majority of applications use it for TLS
      trust anchors.

      I'm not counting the number of package directories in pkgsrc
      (although I wouldn't be surprised if it wins on that); I'm
      estimating how often things are used and how important the uses
      are, based on how many applications rely on TLS for security,
      especially in automated decisions.

   => /etc/openssl/certs is homologous to /etc/ssl/certs on FreeBSD,
      /etc/pki/tls/certs on Fedora, and generally SSLCERTS in pkgsrc.
      If any application uses these paths for non-TLS purposes that
      sounds like an application mistake.

   => S/MIME applications usually use something else for S/MIME trust
      anchors -- e.g., mutt uses ~/.smime (set up with the smime_keys
      tool), gpgsm uses something under ~/.gnupg, anything nss-based
      doesn't use /etc/openssl at all.

2. What _should_ applications use for TLS trust anchors?

   => OpenSSL provides no way to filter some global idea of trust
      anchors by which ones are fit for {TLS, S/MIME, ...}.

      Hence applications that use OpenSSL the obvious way and need TLS
      trust anchors _must_ use a directory that is limited to TLS
      trust anchors.  We can't change this without changing OpenSSL
      and all the applications that use it.

      So it doesn't even make sense -- and never has made sense -- for
      applications to use a directory that is combined with other
      purposes.  Those applications have traditionally used
      /etc/openssl/certs, which would be a mistake to change at this
      point.

3. How should we expose Mozilla's CA trust decisions to applications?

   => I made sure to install everything where there is an easy binary
      `yes' or `no' answer to `Does Mozilla trust this?' and the
      answer is `yes', under /usr/share/certs/mozilla in either
      `server', `email', or `code', to make it easy for downstream
      consumers -- mainly to make certctl(8) easily configurable from
      a static data source in /usr/share, but it's easy to contemplate
      other consumers too, including S/MIME.

   => I made sure to configure /etc/openssl/certs so that existing
      applications get Mozilla's trusted TLS CAs out of the box for
      modern TLS validation.  This is the critical thing that matters
      most.

   => There are lots of grey areas and edge cases that will never
      affect 99% of users and can't be resolved without additional
      application engineering and possibly changes to the OpenSSL API,
      like restricting Tubitak Kamu SM to *.tr domains or moving the
      expiration date sooner.  I punted on those by failing closed and
      treating them as untrusted.

Note: The formal PKIX language has a way for a CA certificate to
express that the CA it represents is authorized to sign certificates
for TLS server authentication.  But it has no way for an application
(or operating system installation) to restrict a CA or its
subsidiaries from doing that.  That's additional information provided
by, e.g., Mozilla certdata.txt annotations, or by the separation of
select trust anchors into /etc/openssl/certs (vs, say,
/etc/smime/certs), which exists only outside the PKIX certificate
language.


Some other point-by-point replies below:


> Date: Mon, 09 Oct 2023 21:04:06 -0400
> From: Greg Troxel <gdt%lexort.com@localhost>
> 
> Taylor R Campbell <riastradh%NetBSD.org@localhost> writes:
> 
> > 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".

It would be absolutely bonkers for all applications to be required to
use a single global set of trust anchors for all purposes.

I can't imagine that even the most ardent PKIX ideologues would
suggest that all applications should share the same set of trust
anchors for all purposes and let the CAs and their subsidiaries
themselves dictate what they're authorized to do.

For example, if we were using X.509 certificates and CMS signatures on
automated binary updates for NetBSD, this would be a non-starter.
We're not going to have an automated system where we'll accept a
signature from a public key with a certificate issued by just any
public CA that formally self-asserts code-signing authority.  Instead,
we'd just have trust anchors _for that purpose_ in /etc/nbsdupdate or
whatever.

> 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?

I applied the rule `if it's DISTRUST_AFTER at all, just say no',
because there is no way to transmit that information to applications
via the OpenSSL API.

> 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!

I'm drawing a distinction between precious configuration
(/etc/openssl/certs.conf, /etc/openssl/untrusted) and disposable cache
(/etc/openssl/certs).

The cache isn't lazily filled -- it has to be there for applications
to use it, and it's privileged in /etc so it doesn't make sense for
unprivileged applications like ftp(1) to fill it on-demand.

But there is nothing precious in it: you can blow it away and rebuild
it and nothing will be lost.

In these respects it is like the fontconfig cache.

> >> 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.

If you can suggest a mechanism to `remove a CA' that works more
reliably, I'm all ears.

The obvious things to store are:

- CA name according to trustdata.txt (which is uniquified as a file
  name),
- subject name or hash,
- public key or hash.

None of these uniquely determines a human organization that we call a
CA.  So I picked the easiest one to work with: the file name.

> 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.

I bet people are widely unaware that there is anything other than TLS
CAs in this set.  I bet I'm not the only one who was or would be
unpleasantly surprised to learn that mozilla-rootcerts puts non-TLS
CAs in /etc/openssl/certs.

I think it will be more confusing to say anything at all here about
S/MIME because 99% of users don't care and don't have a reason to
care, and the more verbiage we add, the harder everything is to
understand.  So I'm trying to be judicious about what and how much I
say in the certctl(8) and hier(7) man pages.