Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
Re: key trust management (Re: adding gpg to src/gnu/dist)
From: Bill Studenmund (wrstudennetbsd.org)
Date: Wed May 19 2004 - 22:38:55 CDT
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 want
> > TNF to say, "This is our release." Or, "This is a developer." Or, "This is
> > 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
> trust by being at the top of a tree, without externalities certifying
> that the TNF authority matches some certificate or another.
As I muttered in another note in this thread, there are two different
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
> up in a commercial release of something, and you imply trust in the
> commercial entity. That's counter-intuitive, especially for this
> application where it's the release itself that is being certified.
Not necessarily. You're confusing the certificate type with the security
model. X.509 certificates can be used with any trust model. The security
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
> trust! Somebody outside somewhere has to certify the TNF certificate!
> Preferably many somebodies.
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
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 based
> > certificate system is probably the best way to go as we can add extensions
> > 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
> meaningful? Is machine interpretation of encoded policy meaningful?
> Really, all policy interpretation has to be mediated by a human. It
> could be that each human personally examines and specifies and tests
> the mechanical interpretive code, but that's a bit much to be asking
> for this case (that is, distributing the code).
> That's why web-of-trust is more useful for this application. The
> 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
> at least 2 has signed that identity, saying it really is what it says.
> What humans can read is the only thing that matters here. The policy
> would be that the certificate would only be used for releases, and no
> other policy matters.
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-----