Re: officially signed packages

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

On Mon, Apr 07, 2014 at 01:36:10PM +0200, Jan Danielsson wrote:
> On 04/07/14 04:27, Alistair Crooks wrote:
> > On Sun, Apr 06, 2014 at 06:37:36PM +0200, Pierre Pronchery wrote:
> >> I'd say one important thing is the ability to verify package
> >> signatures without relying on any package to be installed already. I
> >> think that's possible for X509-based signatures. In the case of GPG
> >> signatures though, installing security/gnupg is currently required -
> >> and it obviously can't verify itself while installing.
> > 
> > That's what security/netpgpverify is meant for - it has zero pre-req
> > packages. As a bonus, it also verifies ssh key signatures.
> > 
> > As far as X.509 signatures go, the problem is not the signatures
> > themselves, it's how the trust is conveyed to go with the key.  I've
> > yet to sign someone's X.509 key.  In fact I've yet to have someone
> > sign my X.509 key.
> 
>    Apart from the fact that you don't have one .. it may also be because
> that's because that's not how X.509 typically works.

Ugh, that's what I get by being obtuse - I will try to be a bit less
assumptive in future.  However, you got me started on a particular
rant of mine...

>    In X.509 PKI you trust certificates (read: public keys) _through the
> Certificate Authority_.  Instead of determining which certificates to
> trust using a web of trust, you verify the certificate against the CA
> chain.  If it verifies ok, then you know the CA issued it, and you can
> trust the certificate.  Note the implied trust model: You must know that
> you can _really_ trust your CA, and you must know that the CA will only
> issue certificates to trusted parties.  That's how you know you can
> trust a certificate in X.509.

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

        https://www.cs.utexas.edu/~shmat/shmat_oak14.pdf

make me discount X.509 certs as a good basis for the signing of packages.

Furthermore, CAs are not above milking the business for its own purposes -
look at all the EV certs which are nothing more than a protection racket,
with little to no extra verification being used before issuing.
 
>    (You can - obviously - use a separate web of trust in X.509 too, but
> .. why would you? Then you might just as well use PGP..).
>
>    I used to (very) strongly prefer PGP over X.509, nowadays I see them
> as being equally useful, but in different situations.  In the case of
> signing packages, X.509 PKI is well-suited because TNF is a perfect type
> of entity to be a CA.  That being said, the X.509 tools out there are
> user-hostile, counter-intuitive, ugly, annoying, and down-right bad[*].
>  So while conceptually I'm all for TNF becoming a CA, the lack of
> non-user-hostile tools makes me feel that the PGP route is better in the
> end.  ..as long as we have netpgp(verify).
> 
> 
>    [*] I think this may be a direct result of X.509 being very
> "Enterpise":ish. "Enterprise" environments need counter-intuitive tools
> in order to survive.

Amen.

Best,
Alistair