Re: trust anchors and the base system

[David Brownlee <abs%absd.org@localhost>]

On Fri, 2 Sept 2022 at 19:24, Greg Troxel <gdt%lexort.com@localhost> wrote:
>
> 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

I'm happy with the proposal as-is, but at the risk of sidetracking into colours:

It might be nice to have some tools (ftp) display a warning if
VALIDATE is not present, or if has not been updated for some (long)
time - the latter assumes the update process will touch or write some
status into VALIDATE. Could have an environment variable or command
line option to disable the warning, but we risk getting into ever
decreasing circles. tl;dr - if pkg_add/pkgin downloads something
across https without validation, a warning is probably appropriate

David