There is a lot to this and this messages services to establish a new
thread (please don't hijack the ftp thread) about how we might have
configured trust anchors.
I'm mostly only going to talk about requirements.
* the elephant in the room
The entire normal scheme isn't sound. The mozilla root set has a huge
number of CAs, and there are a lot of auditing guidelines. But "not
controlled or coercible by a government the verifier isn't comfortable
with" (which would exclude various CAs for various verifiers) isn't one
of them.
I don't think we have to really address this, but it's important to keep
it in mind because sometimes people seem to think this is totally
straightforward and that anyone who doesn't want to just install the
mozilla set doesn't understand.
* Users should be able to choose how their system is configured.
This means any of:
- add a non-default trust anchor (e.g. US people might add the US
government, anyone might add a particular self-signed cert, or a
private CA)
- remove a default trust anchor (e.g. foreign-controlled CAs,
depending on where you are and which governments you don't like)
- choose not to validate
and these choices should persist across upgrades.
* Defaults should be sane
This means:
Any trust anchors configured by default should be widely viewed as
appropriate for being in the default trust anchor set. I am only
aware of the mozilla set as having this standing.
The NetBSD Foundation is not in the business of deciding if a CA
belongs in or out. This is a similar concept to license approval in
pkgsrc, that defers to FSF, OSI, and Debian.
* trust anchor set update mechanism
CAs could get kicked out of the default set at any time, and this needs
to be pushed, separate from a system upgrade. The update needs to be
delivered securely, which probably means signed by TNF.
The update of course has to not re-add CAs that the user removed, and
not blow away ones the user added.
* old systems and update paths
If someone unpacks new userland and doesn't fully merge etc it would be
nice not to break things.
I think the /etc/openssl/VALIDATE to turn on validation solves this.
* proposal
So, I think this leads to:
rule is that NetBSD installs the mozilla set by default and when
that's done, it set /etc/openssl/VALIDATE.
verifiers use the system configured set if VALIDATE exists
there's some fetch/update that happens to get new versions
there is some way that there is a config file of certs in mozilla not
to use, and some way to put certs that one wants as trust anchors, and
this is respected by the update process
Attachment:
signature.asc
Description: PGP signature