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

On Fri, May 14, 2004 at 01:46:28PM +0200, Love wrote:
>=20
> Daniel Carosone <dan@geek.com.au> writes:

[ about the fact that gpg allows multiple signatures on it's
"certificates" and x.509 doesn't. ]

> > For the case of key management, it's the biggest downfall of the x.509
> > cert format, compared to pgp.  GPG allows that inherently, which is a
> > good thing, and something we wouldn't want to "lose" otherwise -
> > though it does complexify the key trust decisions.=20
>=20
> I think you get this wrong, how can you from a pgp certificate figure out
> if the signer is approved by NetBSD to be distribution binaries when its =
in
> your web of trust from your "trust anchor" ? By name, by keyid, one hop, N
> hops ?

The same way you would with a x.509 cert. In the x.509 world, you'd
have a "NetBSD distribution certifier" (I)CA, that would sign the keys
used for each release (or sign the distribs directly, whatever).

In the gpg world, you'd have the same signature on a release signing
key, it's just that there might be other sigs on it as well.

In both cases, you need to authenticate the trust anchor somehow, and
then follow the chain of trust through. THAT is the part that we need
to get right, especially if its to be implemented with something
automatic for users, regardless of the format.  GPG puts that process
closer to the format, but the process still needs to be done correctly
and can still be very confusing for unsophisticated users.

> The strict hirarky and intended keyusage is something that is very
> important for this problem.

Agreed, the same issues always apply (how do i trust this key), but
the choices and the places things get implemented move around.

Sometimes a little flexibility is essential. Sometimes getting rid of
flexibility helps you resolve ambiguities or other difficulties
easily. Sometimes client-side trust decisions and evaluations are
important, sometimes they're dangerous.

Complexity is the enemy, but complexity is defined by how you measure
it - sometimes doing a lot of work up front makes later efforts
simpler, sometimes its best to leave issues until later for experience
to sort out the real requirements.

I'd really rather we didn't get hung up on the technicalities of what
certificate format is "better", especially when we don't know what we
want from it.  They can all be made equivalent, provided exactly one
requirement - that end users (administrators) are allowed to choose
their own trust anchors, and the system will allow multiple anchors.
Let me illustrate by hypothetical example:

I can, using pgp, set up a strict hierarchy of trust.  If all the
users decide to trust only my pgp signature on other people's keys,
and to trust that signature absolutely, then we have a single CA
issuing certs.  If, furthermore, I publish and sign something the
users can verify and feed to "gpg --import-trustdb", then I can
delegate to sub-CAs.

I can, indeed, set up and run a commercial CA service dishing out pgp
signatures for a fee (strength or otherwise of any such business case
aside :) - and end users can decide how valid they think those
signatures are for themselves.

I can, in a strict x.509 hierarchical model, implement a web of trust.
Something often forgotten by those who haven't worked in the CA space,
is that there is usually a two-step process to getting a certificate,
at least under the hood, and sometimes exposed - especially for
outsourced user CA's.  There's often a registration authority (RA)
that collects user data, validates their identities according to
relevant criteria for the PKI scheme/policy in use, and then passes
the CSR to the CA for generation of the cert.

Lets say, for sake of example, that I set up a NetBSD CA. I generate a
root certificate, use it to sign some ICA certificates for a number of
purposes, publish these certificates, and then lock away the root
private key forever.  Never mind, just for the moment, how I get the
relevant root certs into people's trust chains.

Now, one of the ICA's I set up is the "NetBSD user Web-of-Trust
CA". Under this CA, my criteria for signing x.509 certs are that I
receive a CSR signed by a PGP key (of matching name) that has achieved
enough points to be valid according to my PGP web of trust. PGP (with
my personal ownertrust settings) is the RA.  In this instance, the
signature on the x.509 certificate bridges the two cryptosystems - an
x.509 relying party can look at the single certificate, and that
embodies complex external rules it doesn't need to understand.

Thawte's "freemail" s/mime certificates work in a somewhat similar
manner - the CA issues certs based on trust settings that are
accumulated in a web-of-trust manner between users, with a points
scheme.  I tend to call it "Certrimetics" because it has a surface
similarity with the various MLM schemes, but it's a practical and
effective illustration of the point.

If I have a distribution I want to vaerify before I install, I can
collect a number of different (detached, parallel, nested, etc)
signatures on it, in potentially several different forms - pgp,
s/mime, xml, sha1 hashes published on an ssl webserver, etc - from
potentially several different sources, and use the union of those as
the basis of my decision to install it.

And, of course, any scheme can introduce any other, simply by using
one to sign a certificate for another. So I could help people
validate the authenticity of my CA's root x.509 cert by signing it
with various PGP keys, committing it to the repository with my ssh
key, giving it to other people I know in person, etc.

We have the technology(ies), we have the expertise, what we need is
the requirements. =20

I'm not averse at all to saying we should sign distributions with PGP,
especially where they are built by developers with known keys. Nor am
I averse to saying we should sign them with in an x.509 scheme,
perhaps as a more official blessing from various project teams
(releng, etc).  As far as I'm concerned, no *signature* is likely in
itself to make the signed file less secure.

What will detract from the scheme, and potentially make things less
secure, is if it is too complex for end users to understand, and
particularly if implementation mistakes allow automated tools to apply
inappropriate trust to the usage of various certificates or keys.

Once a user has a running NetBSD system, they can be using our tools
(eg, in-tree pkg_* tools linked with openssl libraries, and
preinstalled trusted distribution keys for our releases, patches,
etc).  There's some design effort required here, certainly.

But even if we decide (perhaps, to avoid excess effort) there will be
no in-tree similar usage of gpg, we still want to gpg-sign the
installation media (.iso's? install floppies?) that a *new* user will
use to bootstrap their use of our tools and trust paths.

None of the above is necessarily a recommendation or a suggestion of
any particular way of doing things, just simply an illustration that
the concentration on particular technologies and certificate formats
is premature.  We can implement what we want in a number of ways, if
only we know what we want.

--
Dan.

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

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

iD8DBQFApWq7EAVxvV4N66cRAhqBAJ9aISZbx2b+OVP269l9NHUtaXNRrQCghY34
mWhq3PZxCJXBhsGsHUCnjss=
=7hY/
-----END PGP SIGNATURE-----

--G2kvLHdEX2DcGdqq--