Hi, On 02.09.21 23:02, Ansgar wrote:
As it is now, I can install a Debian system where no X.509 certificate authorities are trusted.
That doesn't change with the proposal?
- If I deselect all CAs in the configuration dialog of the ca-certificates package, what mechanism will allow apt to work?
If people intentionally detrust them, they have to deal with the fallout.
So this introduces a policy that users need to mark X.509 CAs as trusted?
People can also detrust Debian's OpenPGP signing keys; it's not much different.
The Debian signing keys have separate trust setup, and are trusted for nothing but APT updates.
If we wanted the same for X.509, we'd need /etc/apt/ca-certificates or something such, and apt to configure the list of accepted CAs explicitly in the TLS layer rather than using the default settings.
Accessing www.debian.org will also not work on such systems (and unlike deb.d.o that does not even offer non-https). It's not Debian's problem.
There are a lot of systems out there that have no need to access www.debian.org, but do need to access deb.debian.org.
- Do we want to pin the certificate provider for Debian mirrors, in the knowledge that we want to be bound to this provider for several years, do we want any "root" CA to be able to provide a trust anchor?
Probably not?
So what do we want then? A list of root CAs that users have to mark as trusted, possibly with an "are you sure?" dialog in ca-certificates?
This isn't a simple change of default, because this simple change pulls in a lot of dependencies. That users can override the default means adding another work step for users, either a manual step that needs to be performed after a manual installation, or an automated step that needs to be integrated into users' deployment processes.
- Is there a revocation mechanism by which we can mark "root" CAs as untrustworthy?
If we don't have one, shouldn't we worry more about that given the widespread use of TLS?
We have a big hammer, shipping a new ca-certificates package. If we want something that only affects apt, but not other packages, that mechanism doesn't exist yet.
Do we have a revocation mechanism by which we can mark OpenPGP signing keys as untrustworthy (say for apt)?
Yes, by shipping an update.
- do we have a contingency plan if deb.debian.org hosting on Fastly is no longer feasible?
As far as I know there is also at least https://cdn-aws.deb.debian.org/ if you don't like Fastly.
It's not about what I like, but on what external services we want to depend. Simon
OpenPGP_signature
Description: OpenPGP digital signature
