--BQPnanjtCNWHyqYD
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, May 18, 2004 at 11:45:25AM -0400, William Allen Simpson wrote:
> Bill Studenmund wrote:
> >=20
> > For NetBSD releases, I don't think we want a web-of-trust. I think we w=
ant
> > 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.
> >=20
> U.S. President Truman, actually.

My appologies.

> 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=
=20
TNF's cert. The "top of a tree" part has to do with the former, and you're=
=20
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=
=20
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=
=20
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=
sed
> > certificate system is probably the best way to go as we can add extensi=
ons
> > to the cert which we in turn can use to encode policy.
> >=20
> This of course is a whole 'nother can of worms.  Is "policy" encoding=20
> meaningful?  Is machine interpretation of encoded policy meaningful?
>=20
> 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
>=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,=
=20
> "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
>=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.

Take care,

Bill

--BQPnanjtCNWHyqYD
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFArChPWz+3JHUci9cRAsXgAJ9oiRVbs68ObldNCLLhEMsW4S8TVACfb/GN
M1ffjnHbkVBEsw0MYZ77mZM=
=n01L
-----END PGP SIGNATURE-----

--BQPnanjtCNWHyqYD--