Proposal on interim TLS roots behavior

proposals/2024-02-23-interim-tls-roots.md

+# Proposal on interim TLS roots behavior
+
+## Background
+
+`stboot` configures its TLS roots by reading a hard-coded file named
+`/etc/ssl/certs/isrgrootx1.pem`.  This file can contain any number of TLS roots,
+and they need not correspond to the Let's Encrypt certificate authority.
+
+`stprov` configures its TLS roots by reading standard locations such as
+`/etc/ssl/certs`, i.e., not just a single file in `/etc/ssl/certs`.
+
+An earlier [accepted proposal](./2023-12-05-clean-up-ca-selection.md) outlined
+this background in more detail, and concluded that the single file
+`/etc/trust_policy/tls_roots.pem` should be read instead.  This would be a
+breaking change that makes the behavior of `stboot` and `stprov` consistent.
+
+## Proposal
+
+Make the behavior of `stboot` and `stprov` consistent by locating TLS roots in a
+standard directory: `/etc/ssl/certs`.  This behavior will be obsoleted by the
+already [accepted proposal](./2023-12-05-clean-up-ca-selection.md) later on.
+
+## Motivation
+
+We are trying to get our reference specifications in better shape before
+breaking interfaces (such as renaming files).  With this proposal, we can say it
+is up to the user to put their trusted TLS roots in `/etc/ssl/certs` and name
+them accordingly.  Any name will do -- no fictional Let's Encrypt lock-in.
+
+At the same time, any old setup that uses `/etc/ssl/certs/isrgrootx1.pem` in
+custom ways will continue to work because this proposal reads that file and
+more.  Behavior is not expected to change in old setups because (to the best of
+our knowledge) such old setups never include more than this certificate file.
+
+## Other alternatives considered
+
+Do nothing, let our documentation describe that it is a bit messy that the
+certificate file is called `isrgrootx1.pem` for no good reason.  Implement this
+behavior in `stprov` so that it is consistent with `stboot` (or accept that the
+behavior in `stprov` is more permissive than that of `stboot`).  This option is
+not precluded, but it seems easier to just relax the currently hard-coded
+reading of `/etc/ssl/certs/isrgrootx1.pem` until we can change it properly.
+
+Another alternative would be to implement the accepted proposal, and for some
+time support both that and the old behavior.  Also not precluded, but it
+similarly seems easier to have a single behavior and rework properly later.
+
+XXX: Please feel free to disagree if you think any of the above two options are
+better than what is being proposed here.  Especially the second option doesn't
+seem that bad when typing it down.  The change to `stboot` would be to read one
+more file.  The change to `stprov` would be to start reading the same two files.
+From a documentation point of view, we would document the new behavior and then
+somewhere describe backwards-compatibility considerations (which we anyway
+already need to do in stboot for, e.g., obsolete host configuration fields).
+
+## Required changes
+
+`stboot`: delete code, use Go's defaults that consult [standard locations][].
+
+`stprov`: no changes, already uses Go's defaults.
+
+`stauth`: out out scope for now.  Note that reading a single file makes it
+easier to measure the right values into PCRs.  This is another argument for
+moving forward with the earlier accepted proposal that uses a single file.
+
+[standard locations]: https://github.com/golang/go/blob/ad377e906a8ee6f27545d83de280206dacec1e58/src/crypto/x509/root_linux.go#L9-L24
+
+## How to document this change
+
+There is no complete reference documentation on TLS roots yet.  Such reference
+documentation will be added, and warn that there are planned changes later on.

[Rasmus Dahlberg]

Turns out old systems actually doesn't use the named file that is in stboot main now. It was changed from /etc/https_roots.pem to /etc/ssl/certs/isrgrootx1.pem on Fri Jan 27 10:53:11 2023 +0100.

Maybe we should just go ahead with the refactor we wanted all along and in our release notes say that stboot build scripts need to change the location of their file with trusted HTTPS roots. It is not a that big ask as long as we make it clear.

[Rasmus Dahlberg]

I could be swayed to go either way here, but if we want to minimize the amount of work needed right now I still think it is the right thing to move this proposal forward as typed up here.