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

On Sat, May 15, 2004 at 01:05:10PM -0400, Greg A. Woods wrote:
> [ On Saturday, May 15, 2004 at 10:56:27 (+1000), Daniel Carosone wrote: ]
>=20
> But if I understand correctly it's still not a true web-of-trust.
> There's still one root certificate that ultimately has to be trusted.

Yes. That actually is the point.

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=20
think it's exactly what we want for what we're talking about doing.

As part of this, we need a root certificate for TNF. I envision it as=20
something the board guards, say keeping it on a USB memory stick in a=20
corporate safe-deposit-box.

TNF then lists policies it requires before it will sign something, and=20
thus its signatures represents a satisfaction of those requirements.

I'd suggest folks who are interested in this read, "Understanding PKI,=20
Second Edition," by Carlisle Adams and Steve Lloyd, ISBN 0-672-32391-5.=20
It does a good job of describing what a PKI can do, and what current=20
implementations can do now.

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.

As an example, we could come up with a cert extension that will indicate=20
what releases a certificate can sign. So when the TNF board authorizes a=20
release-signing cert, they can encode the fact that it will only sign a=20
given release or release family. So the 2.0 release key can't be used to=20
sign the 3.0 release, for instance.

> There is no one root in the PGP web-of-trust (especially if people do
> some regular, even if random, out-of-band verification of key
> fingerprints for any keys they've retrieved from public key servers or
> other potentially untrusted sources such as "finger" or SMTP).

A web-of-trust, which PGP does well, solves a different problem. It's
great for identfying someone (or specifically an EMail address) you don't
know and who isn't within the same administrative entity. But for signing
releases, I think we want something more structured than a web-of-trust.

I think two questions have gotten confused. One question is how do we know
the TNF root cert? In the long run, I think the right answer is that it
will be in the OS, like how Windows has a copy of the public key for
driver signing, etc. Before updating, you'll be able to verify a new
download is ok. Then once it's installed, it will have a copy of the TNF=20
cert in it.

A second question is how do we get there? We don't have the root cert out=
=20
& about yet. I think that PGP could be quite useful here in that a number=
=20
of NetBSD developers could sign the TNF root cert, thus bootstraping=20
ourselves with an existing PKI. I also think that PGP is a great PKI for=20
doing this.

Take care,

Bill

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

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

iD8DBQFAqXGhWz+3JHUci9cRAlgvAJ4pzaqhuS9ghaP7vpRAQqUcwQMbPACffvdE
wiQUN3HTWkA++CvePnPhfVM=
=hU2R
-----END PGP SIGNATURE-----

--DiL7RhKs8rK9YGuF--