Re: officially signed packages

[Jan Danielsson <jan.m.danielsson%gmail.com@localhost>]

On 07/04/14 22:51, Thomas Klausner 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,
> 
> I'm probably missing something, but what's the problem with including
> one CA root certificate with pkgsrc, created by TNF, and certifying
> bulk builders with it?

   Nothing, if the root CA distribution can be trusted.

   Slight tangent follows..

   It seems most people are used to OpenPGP networks, but aren't as
accustomed to X.509 PKI structures, so I'll briefly mention the "full"
bootstrap in preparation for using a PKI identity's public certificate
to verify signatures (assume all the bells'n'whistles, with intermediate
CA's and CRL's):

   1) Get root CA from a _trusted_ source (if the root CA can not be
trusted, we're screwed).
   2) Get intermediate CA's from a public repository.
   3) Get the latest CRL (Certificate Revocation List) for the CA.
   4) Verify the CRL using the CA (chain).
   5) Get the certificate of the signing identity from a public repository.
   6) Verify the certificate against the CA (chain) and CRL.

   As I tried to imply earlier, the strength in X.509 PKI structures is
that if the CA fulfills its role properly, an end user just needs to
acquire the CA certificate through a secure channel, and then she can
use it to verify all other X.509 objects which are supposed to be from
the same organization using the CA chain.

   If done properly, the user would need to keep the CRL up to date, and
regularly check to make sure that the sign certificate hasn't been revoked.

   If one doesn't use intermediate CA's, and doesn't use CRL's (which I
gather is the plan), the model becomes even simpler. (Get CA, get cert,
verify cert using CA, done).

   While I definitely agree that there are huge problems with making
CA's into a business, let's differentiate between "business CA's" and
pure "organizational CA's".  Even if X.509 would be used in an even more
"formal" way than what Joerg suggested (i.e. TNF would become a root CA,
and would create sign certificates for builders), it's still just an
organization-local CA; it doesn't suffer from the profit motives third
party business CA's have.

   If X.509 would be discard as an option, I would prefer it not be for
reasons which aren't applicable to TNF/pkgsrc.  While I think there's
merit in complaining about commercial CA's; I don't think their problems
really apply to a closed organization, in particular in the use case
we're talking about in pkgsrc.


   Even more on a tangent: I just happen to know about a national ID
project which got borked by business interests.  Some companies got
inolved and tried to apply "find creative ways to make money" thinking
to X.509 PKI, so the scheme they hatched was to hand out national ID in
the form of a smart cards, and in them include a PKI identity for the
citizen, but they planned on keeping the root CA to themselves.  The
idea was to sell the public CA certificate chain to other businesses
which wanted to be able to verify client certificates.


-- 
Kind Regards,
Jan