Distributing mozilla root certs is hardly "TNF takes on the role of a trusted CA source".
And we need to start thinking laterally here. Certs are necessarily transitory, and we wish any form of added trust to be enduring over a period of time. + Can we use ssh fingerprints of project machines as part of the trust-booting procedure, or as a light form of 2FA? + Can we ship just a subset of root certs to get, in a trusted way, to NetBSD.org, and then download (with a bit more assurance than just a straight HTTP GET request) an updated set of mozilla root certs? + Can we ship a full set of root certs, as a bootstrap mechanism to getting a more up to date set? What is the fallback in this case - no service? + Can we talk have the certs mirrored, and use a number of similar replies from untrusted sources as a bootstrap mechanism? + Do we put all of our eggs in one basket, pin the cert, and then rely on that being the one true way? + How should true revocation be done? + root certs which are signed with NetBSD ssh host keys could be an interesting area of opportunity + Everything else I've forgotten On 4 July 2017 at 14:02, Jan Danielsson <jan.m.daniels...@gmail.com> wrote: > On 07/04/17 21:15, Benny Siegert wrote: >>> There are other stories as well, but that's a good illustration of >>> why it's a bad idea to just hand over a bunch of CA's to users without >>> any mechanism for keeping the CA database, and CRL's, up to date. >> >> I expected this argument, but it is finally irrelevant. This is because most >> users do one of two things: >> >> (a) do nothing and effectively trust all certificates, because none are >> installed; >> (b) install the mozilla-rootcerts package and trust the mozilla set. >> Maybe add >> (c) users who consciously select a subset of those certificates — probably a >> tiny minority> Compare with root certificates in the base system: >> Users in (a) gain cert verification. Users in group (b) do not have to do a >> manual step. Users in group (c) lose nothing, because they still can futz >> with root certificates manually. >> >> I assert that having a somewhat outdated set of Mozilla’s root certificates >> is better than having none at all and implicitly trusting everyone — or >> worse, trusting no one and having, say, Mercurial refuse to clone repos over >> https by default. > > Perhaps, but I think you're mixing two different issues together. > > If users choose to disable certificate verification, that's on them. > > If TNF takes on the role of a trusted CA source, then that implies a > lot of responsibility that they don't currently have. They can't say > "here, have a bundle of outdated root certificates; we ship them only so > that some programs will shut up." -- that's irresponsible and it's > certain to cause unflattering comments. > > Don't take me wrong, I want a solution which would make the X509 > experience in NetBSD smoother. But being a trusted CA source means > splotlight and willingness to answer questions if something goes wrong. > I wouldn't be willing to take on that responsibility myself, so I'm not > going to ask TNF to do it. (Though I would obviously be delighted if > they assigned a Chief PKI Officer role and offered a proper CA > distribution solution). > > With all that being said, you're not wrong about the complexities of > X509 actually lowering security in many instances, but it's still the > user's choice to do so. > > -- > Kind Regards, > Jan Danielsson >
