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

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

(I've been putting off thinking about and dealing with this due to
juggling too many other things.)

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

> The new certctl(8) tool is provided to manage the TLS trust anchors
> configured in /etc/openssl/certs with a simple way to change the
> source of trust anchors or distrust individual ones -- and with a
> manual override, if you would rather use another mechanism to do it,
> like the commands available in the security/mozilla-rootcerts or
> security/ca-certificates packages, or the special-purpose
> security/mozilla-rootcerts-openssl package.

This says "TLS trust anchors", but I wonder if that's accurate.  Isn't
this "pkix trust anchors, for which the most common case is TLS"?  I
have not dug in to the openssl library calls, but my impression is that
openssl the installed software does pkix validation in general, and the
installed trust anchors will be used for invocations to validate pkix certs
separately from TLS.

After reading, I think what's going on is

  1) mozilla rootcert situation is a bit of a mess smantically
  2) certctl is installing the subset that is intended for TLS
  3) the installed certs will be used for all uses, not just TLS
  (e.g. SMIME), and because certs intended for SMIME but not "server"
  are missing, the wrong thing will happen sometimes, but because many
  CAs do both (?) it will often be ok.
  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.

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?

I see code is empty.  I'm going to ignore this.

With a bit of ls/sort/uniq/comm, I see that there are certs in all that
do not appear in email or server:

  Explicitly_Distrust_DigiNotar_Root_CA.pem
  Symantec_Class_1_Public_Primary_Certification_Authority_-_G6.pem
  Symantec_Class_2_Public_Primary_Certification_Authority_-_G6.pem
  TUBITAK_Kamu_SM_SSL_Kok_Sertifikasi_-_Surum_1.pem
  TrustCor_ECA-1.pem
  TrustCor_RootCert_CA-1.pem
  TrustCor_RootCert_CA-2.pem
  Verisign_Class_1_Public_Primary_Certification_Authority_-_G3.pem
  Verisign_Class_2_Public_Primary_Certification_Authority_-_G3.pem

Looking at email vs server, I see 88 in common, 21 email only, 52 server
only.

How is SMIME supposed to work?  Are SMIME validators, which presumably
use openssl as an engine, supposed to maintain a different trust anchor
set?  Where? 

I see that mozilla-rootcerts-openssl has 169 certificates, so that must
be all, which appears to be a really serious bug.

Maybe we don't want to deal with this, but I think it needs to be
clearer, especially as this upgrade to certctl from
mozilla-rootcerts-openssl does:

  resolves a security issue where "untrusted" certs were trust anchors (yay)

  removes trust anchors for email, likely breaking some SMIME uses (but
  not sure in practice how much, given tbird uses internal and gpg2 uses
  gnutls).  (theoretical boo)


I'll also observe that it's mostly because I have avoide digging in
until today, but this larger situation of the subsets, what was and what
is, is news to me today.  

> So it would be helpful if you could test updating NetBSD in whatever
> way you do it (sysinst, untar/etcupdate/postinstall, etcmanage,
> something even more bespoke), and let me know if anything goes wrong
> with the TLS trust anchors:

I did an update via

  Existing system is netbsd-10 from august, upgraded since 2003 from
  netbsd-wicked-old, both software and hardware.

  Existing system has mozilla-rootcerts-openssl.

  Built release from netbsd-10 (normally via build.sh).

  Upgraded via INSTALL-NetBSD from etcmanage, which unpacks kernel and
  non-etc sets, unpacks etc/xetc to /usr/netbsd-etc and then runs
  etcmanage to merge those to /etc, never touching a user-modified
  file.

> 1. Does postinstall work smoothly for you?

Ran "postinstall -s /usr/netbsd-etc check", got warning about certctl,
which seems right.  Ran with fix, got:
  certctl: existing certificates; set manual or move them
which also seems right.

> 2. Does it blow away any configuration you had?  (I don't think it
>    should, but if you back up /etc you should be able to see.)

The mozilla-rootcerts-openssl certs and one cert I had there manually
remain.  So correct behavior.

> 3. Do you end up with the trust anchors you expected?

I expect things I have changed in /etc not to be modified in an upgrade,
so yes.

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.

> 4. Are the answers obvious or do you have to go digging?

I'm not a really good test case for this, but it seems pretty clear that
/etc/openssl/certs has contents and thus certctl won't touch it, and
that reading the man page tells me how to configure it so it does what I
want.

I don't understand the "distrust" mechanism.  The intent is obvious, but
there must be some data stored someplace.  I think it's
/etc/openssl/untrusted, where if a cert is present (or symlinked?) and
matches bit-for-bit, it's excluded.  But that is really non-obvious from
the certct man page, even for me.   I realize that may be a
implementation detail not specified by the interface, but a

  (While not part of the defined interface to certctl, the untrust
  mechanism is implemented by placing a copy of the untrusted
  certificatee in /etc/openssl/untrusted.)

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.

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.

> 5. Do you hit any messages or warnings or failures that you don't
>    understand?

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.

> 6. If you previously used mozilla-rootcerts, ca-certificates, or
>    something else, and you want to switch to certctl(8), is it obvious
>    what you need to do?  If not, where did you consult to find what
>    you need to do, where you didn't find the answer?

It is clear enough for me to get to what's intended.  I moved my
non-mozilla desired .pem to /etc/openssl/manual, added a path line,
pkg_delete'd mozilla-rootcerts-openssl, ran certctl rehash, realized I
needed to nuke the symlink from my manual cert, and ran it again.


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.