On Apr 7, 2014, at 22:13 , Marc Espie <espie%nerim.net@localhost> wrote:
> On Mon, Apr 07, 2014 at 05:50:53PM +0200, Alistair Crooks wrote:
>> Personally, I would never trust a CA-signed cert for this use case,
>> and most use cases of certs in real life won't trust self-signed
>> certs. The reasons are that CAs pure existence is as a trusted third
>> party, and yet their business model calls for them to cover up any
>> breach or leak. Look how quickly Diginotar went out of business.
>> This is before we look at how easy it is to con CAs into signing certs
>> on behalf of domains for which proof of ownership is lacking, and the
>> kinds of openssl fun we're about to see coming up over the next few months
>
> Very nice summary of the current situation...
>
> That's the one reason why we went for pure keys in OpenBSD, without any
> kind of CA.
[…]
> Do you really need chains of trust ? they're actually a complex mathematical
> object that defies intuition (real-world analogies carry you only so far),
> most people don't really understand what's going on, and they tend to fail
> sooner or later.
But what's the alternative ("non-TA") suggestion then?
Having some sort of TNF/pkgsrc TA as Joerg suggested makes it easy for the
clients to install it once (in a standard way) and then trust everything under.
(The newer pkg tool versions could even come preconfigured with the TA)
That's a huge plus on the client usability side, and keeping it simple for the
users also improves security…
/P
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail