On Tue, May 18, 2004 at 07:22:06PM +0200, Love wrote:
> 
> "Steven M. Bellovin" <smb@research.att.com> writes:
> 
> > So -- what do we want to be checkable, by whom or what, and in what 
> > sort of environment?
> 
> I want to be able to check binary pkgs and releases (the tarballs and in
> the future, syspkg's). Also having the install media signed is a
> requirement.
> 
> I think it would be cool if pkgsrc's distinfo files could be signed (or the
> equvalent), but I don't know how well that would work.
> 
> I want the able to have a "update-(sys)pkg" in my cron to fetch the latest
> security fixes for src/pkgsrc in releases.

Right, to me this is why X.509 seems like the obvious way to go.

Once you have installed the operating system for the first time, ideally
the rest of the work should be done by programs, possibly even in the
background without you explicitly invoking them for each update.  And
every update you make to the operating system should be with data
signed either by:

1) A key explicitly authorized by TNF for such signing.

or

2) A key *you have explicitly decided to trust for this particular
   purpose*.

Now, #1 is a straight trust-flows-outwards hierarchical trust model, *and*
you want key usage restrictions encoded in the key/signature -- it basically
screams for X.509 certificates.

On the other hand, it might seem like #2 would lend itself to PGP and the
"web of trust", but I have serious doubts about that.  As Steve has
pointed out, GPG's automatic trust calculations can produce questionable
results; but more importantly, trusting *that someone's key actually belongs
to him* so you can send "him" email by that key and *trusting someone to
replace arbitrary executables on your machine* are not the same; and there
is no system for computing *trust of a key for a specific purpose* in GPG;
there's not even any support for authorizing keys for particular purposes
in the key/signature format.

Sure, you could hand-authorize a particular PGP key to sign packages for
installation on your machine; but at that point, you might as well just
use X.509 and gain the benefit of having only one tool and using only
one signature format.

What it might be entirely reasonable to use PGP/GPG for would be detached
signatures of the initial OS install media.  This is where you'd get the
NetBSD CA certificate; it is your introduction to the hierarchy of trust
that controls the rest of your use of the system (signed or not, you're
trusting us as soon as you install our software; you can't really avoid
that).  So it might be nice to let others provide PGP signatures to assure
you that, in fact, the CA certificate and executables you're about to
bootstrap yourself with are, indeed, from the people you think they're
from.  I would support that alongside use of X.509 signatures for update
and package installation within the OS.

Thor