Re: Shipping SSL certificates in the base system

[Alistair Crooks <agc%pkgsrc.org@localhost>]

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.danielsson%gmail.com@localhost> 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
>