Subject: Re: key trust management (Re: adding gpg to src/gnu/dist)
To: William Allen Simpson <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 05/19/2004 20:38:55
Content-Type: text/plain; charset=us-ascii
On Tue, May 18, 2004 at 11:45:25AM -0400, William Allen Simpson wrote:
> Bill Studenmund wrote:
> > For NetBSD releases, I don't think we want a web-of-trust. I think we w=
> > TNF to say, "This is our release." Or, "This is a developer." Or, "This=
> > a security advisory." To paraphrase U.S. President Eisenhower, we want
> > "The Buck" to stop with TNF. That's a hierarchical trust model, and I
> > think it's exactly what we want for what we're talking about doing.
> U.S. President Truman, actually.
> I agree that "the buck stops" at TNF. I disagree that TNF gains that=20
> trust by being at the top of a tree, without externalities certifying=20
> that the TNF authority matches some certificate or another.=20
As I muttered in another note in this thread, there are two different=20
trusts involved here. There is trusting TNF, and trusting you really have=
TNF's cert. The "top of a tree" part has to do with the former, and you're=
talking about the latter.
> The way that X.509 certifies the certificate is the certificate shows=20
> up in a commercial release of something, and you imply trust in the=20
> commercial entity. That's counter-intuitive, especially for this=20
> application where it's the release itself that is being certified.
Not necessarily. You're confusing the certificate type with the security=20
model. X.509 certificates can be used with any trust model. The security=20
model you describe above is known as the "Web" model. But it's by no means=
the only one.
> Therefore, I don't think that you can have anything other than web of=20
> trust! Somebody outside somewhere has to certify the TNF certificate!=20
> Preferably many somebodies.=20
Not necessarily. While having a number of folks sign the TNF cert would be=
a great way to seed its distribution, it's by no means necessary. The=20
point is you either trust a root cert or you don't.
> > Also, on a somewhat related but different issue, I think an X.509 v3 ba=
> > certificate system is probably the best way to go as we can add extensi=
> > to the cert which we in turn can use to encode policy.
> This of course is a whole 'nother can of worms. Is "policy" encoding=20
> meaningful? Is machine interpretation of encoded policy meaningful?
> Really, all policy interpretation has to be mediated by a human. It=20
> could be that each human personally examines and specifies and tests=20
> the mechanical interpretive code, but that's a bit much to be asking=20
> for this case (that is, distributing the code).=20
> That's why web-of-trust is more useful for this application. The=20
> identity (and policy) is encoded in a human readable form (for example,=
> "NetBSD release 2.0"), and a group of 16 humans of which I can verify=20
> at least 2 has signed that identity, saying it really is what it says.=20
> What humans can read is the only thing that matters here. The policy=20
> would be that the certificate would only be used for releases, and no=20
> other policy matters. =20
That's a far-more limited policy model than the rest of us have in mind.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----