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

[Taylor R Campbell]

Correcting a small error in the previous message:


> Date: Wed, 11 Oct 2023 18:47:02 +
> From: Taylor R Campbell 
> 
> 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.

Actually, it can't even express that, as far as I know.

The certificate can say it is authorized to sign certificates (basic
constraints: CA=TRUE, extended key usage: cert sign), or it is
authorized to authenticate TLS servers (extended key usage: server
auth).  But it can't say it is authorized to sign certificates only
for entities authorized to authenticate TLS servers.

That is, it can't be _restricted_ from doing that in the X.509
language, so _any_ CA can always sign certificates for _any_ purpose.

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

[Taylor R Campbell]

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
  

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

[Greg Troxel]

Taylor R Campbell  writes:

>> Date: Sun, 08 Oct 2023 10:54:13 -0400
>> From: Greg Troxel 

> 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 

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

[Steffen Nurpmeso]

Rhialto wrote in
 :
 |On Sun 08 Oct 2023 at 16:04:20 +, Taylor R Campbell wrote:
 |> 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.
 |
 |mail/mutt supports S/MIME signing at least out of its box, but by
 |default it uses its own management program `smime_keys` to manage the
 |keys, stored in ~/.smime. That's the closest I know of.

The MUA i maintain can also S/MIME via the pretty easy usable
OpenSSL API (aka native not via command line tools).  It will be
easier to auto-save and auto-encrypt S/MIME with the next release
(also via a dedicated certificate folder).

 |Sometimes I receive a mail signed with S/MIME from some mailing list but
 |I don't think that mutt ever told me that the signature matched (due to
 |the certificates not being set up).

The PGP community started sending their "certificates" aka public
keys in an attached way, protected by the signed envelope.  Ie you
can save the attachment and, with that, verify the email.  Ie
after they all cancelled their key server (also Universities and
such) following that "toxic waste attack", and the keyserver pool
dried out, you can do WKD (which is not really easy to setup as it
"documented somewhere", and requires special handling, for example
what i called

  RFC 6189: ZRTP specific base32 (RFC 4648); and see
  human-oriented-base-32-encoding.txt (hihi)

(laughter and what they think is human-oriented that is), as well
as, of course, your own domain and webserver storage, and there
is not much aside from that, IETF standardized an ACME Let's
Encrypt thing for S/MIME, but i bet that will never truly make it,
and i bet again i will not loose that bid, but am not in a fever
on that either.

DKIM is cool, but they would need to allow mailing-lists and such
to store the modified things away to a known place, and verifiers
would need to support restoring that along the chain / stack of
things, and then user interfaces would have to adopt and show
hints on all that.  (What _will_ happen is that they automatize
and inject tons of ARC and such s..t no matter what.  And i will
not use DMARC or ARC until that messed system will not work
without it no more.)
DKIM of course "protects" the domain, not a human sender.

I like S/MIME.  In fact i would have hoped OpenSSL providing tools
to (detach) sign and verify files, as anything is there to create
and verify signatures.  Like this all use cases for PGP would have
vanished from my point of view.  I mean, OpenSSL uses standardized
algorithms, and standardized file formats (CMS, X509).

What i like better with PGP is the MIME approach (i have forgotten
about RFC 1847, 2015, 3156 for now).  But, ideally, users do not
have to deal with that anyway, as the user interface abstracts it,
so then it does not matter.
Anyhow PGP support the MUA i maintain will not get before the big
MIME rewrite, then it will come via external tools.
Unfortunately NetPGP was not funded to death, it was such a small
forgiving thing.  It is understandable that someone forked the
code, but that thing (the name of which i have forgotten, too),
last i looked, was really much more potent, but used languages and
dependencies that deterred me.  (Maybe timelines wrong, but C++ is
now in every base system that i practically use, shall it have
been that, one problem vanished.  Anyhow, it is all too big.)

Well so for me S/MIME will then just be setting a variable, and
the hook should catch it and act accordingly:

  define on-compose-leave {
...
\if -N smime-sign && -N _smime-sign-cert
  \local vput fop _smime-sign-cert expand "$_smime-sign-cert"
  \if -r "$_smime-sign-cert"
\digmsg create -
\digmsg - attachment insert "$_smime-sign-cert"
\digmsg remove -
  \en
\en
...

And i thought, since i wanted to write this saturday night, that
the special compose-mode digmsg object should spring into
existence automatically.  Anyhow this is a long way to go, until
it will really rock.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


steffen@sdaoden.eu.crt
Description: application/x509-ca-cert


smime.p7s
Description: S/MIME digital signature

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

[Rhialto]

On Sun 08 Oct 2023 at 16:04:20 +, Taylor R Campbell wrote:
> 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.

mail/mutt supports S/MIME signing at least out of its box, but by
default it uses its own management program `smime_keys` to manage the
keys, stored in ~/.smime. That's the closest I know of.

Sometimes I receive a mail signed with S/MIME from some mailing list but
I don't think that mutt ever told me that the signature matched (due to
the certificates not being set up).

-Olaf.
-- 
___ Olaf 'Rhialto' Seibert
\X/ There is no AI. There is just someone else's work.   --I. Rose


signature.asc
Description: PGP signature

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

[Taylor R Campbell]

> Date: Sun, 08 Oct 2023 10:54:13 -0400
> From: Greg Troxel 
> 
> (I've been putting off thinking about and dealing with this due to
> juggling too many other things.)

No worries, glad you found some time to review it!

> Taylor R Campbell  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.

If you know of applications that uses /etc/openssl/certs on NetBSD (or
/etc/ssl/certs on FreeBSD, or /etc/pki/tls/certs on Fedora), or SSLDIR
in pkgsrc, to find trust anchors for anything other than TLS, I'd like
to hear about it.

My guess is that such cases are very rare if they exist at all, and
they are totally dominated by applications that rely on it for TLS
validation.

> After reading, I think what's going on is
> 
>   1) mozilla rootcert situation is a bit of a mess smantically

Not really.  The CAs are clearly marked in certdata.txt for different
purposes.  I imported the content according to the metadata about
Mozilla's trust; more below.

>   2) certctl is installing the subset that is intended for TLS

Correct.

You can also use the same certctl(8) program to install trust anchors
in another path for other purposes, like /etc/smime/certs.  I made
sure it would work (both for testing and for other possible uses) but
didn't lift a finger to make it happen because TLS is critical and
everything else is niche.

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

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.

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

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

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

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.

> 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

That looks correct.  It matches what I see in certdata.txt and the
special annotation about Tubitak Kamu SM at
.  See
external/mpl/mozilla-certdata/share/Makefile for notes on how this
particular sausage is made.

These exclusions also match my knowledge of the history:

- Digi-Notar was infamously compromised by the Iranian state a decade
  ago.

- Symantec's CA was nixed after a series of certificate misissuance
  incidents and audit failures a few years ago:
  

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

[Greg Troxel]

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

Taylor R Campbell  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

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

[Lloyd Parkes]

On 4/09/23 08:47, Taylor R Campbell wrote:

We're preparing to ship TLS trust anchors in base and configure them
so that applications like ftp(1) and pkg_add(1) can do TLS validation
out of the box.


Nice.

I will have to wait until after the repository conversion systems come 
back online. Oh well.


Cheers,
Lloyd

Call for testing: certctl, postinstall, TLS trust anchors

[Taylor R Campbell]

We're preparing to ship TLS trust anchors in base and configure them
so that applications like ftp(1) and pkg_add(1) can do TLS validation
out of the box.

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.

I've added some logic in postinstall(8) to handle the transition when
you update.  Tried to anticipate all reasonable paths into the update,
and handle them all gracefully.  But no doubt I missed something.

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:

1. Does postinstall work smoothly for you?

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

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

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

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

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?