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

On Thu, May 13, 2004 at 11:53:21PM -0400, Andrew Brown wrote:
> the user shouldn't have to download keys, sign keys, or upload keys.

Exactly, for the general release-consuming mass populace.

However, as far as making a workable system, consider two points:

1) "user" in this context does include at least some number of
developers who would be building and signing packages of various kinds
(snapshots, iso's, patch/test builds, pkgsrc binpkgs, etc), and ought
to have appropriate trust paths. The certification is easy, the policy
framework around allowing one or another such user to be trusted for
various purposes is harder.

> they shouldn't need to sign anything either (or were we considering a
> way that people could provide their own "signed" packages?). =20

2) I would like to have the mechanism flexible enough to allow
individuals to use it for their own purposes.  As a NetBSD site
administrator, I want to do my own builds (say for security updates,
or binary packages) and have them distributed around my various
machines with appropriate validation.  At its simplest, I generate my
own self-signed cert and drop it into an appropriate trust path
repository, with appropriate policy flags as above, on my machines.

> we can also probably (though i've not checked) coerce the nbwww key
> into signing the "NetBSD CA" key, thereby establishing a line (note,
> not a web) of trust back to one of the "globally recognized CAs".

We can, but the "problem" with this is getting the client to follow
the trust back to the CA.  It shouldn't, because the path and basic
constraints on a www cert don't allow it to be trusted (as opposed to
used) for signing other certs. =20

This was the famous microsoft vulnerability year or two ago, where
their stuff didn't check those constraints properly when validating
certificate chains. Much fuss was made about the potential for website
impersonation, but I expected the potential for authenticode abuse was
much much higher, give the number of users who trust signed .ocx's and
=2Emsi's and so forth.

We should not do this, it would be Wrong. :)

--
Dan.

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

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

iD8DBQFApFKCEAVxvV4N66cRAv2vAKCUKcuk+qYt8uC/UpWGLMlxPZbqsACfXAgG
9npRvjorrdr8FJ6xW7VuPF4=
=qkqO
-----END PGP SIGNATURE-----

--I33OQG5IFrqF2BWt--