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

On Thu, May 13, 2004 at 09:50:20PM -0700, Simon J. Gerraty wrote:
> >Yes, although we'll at least potentially want some slightly
> >finer-grained distinctions within that - releases, pkgs, perhaps
> >patches and security updates.  This helps avoid problems with key
> >disclosure if everything must be signed with the same key.
>=20
> Ah but that's the whole beauty of a cert based model.
> Eg.  you want a hierarchy of certs:
>
>  [diagram]

Yup, this is exactly the kind of thing I was alluding to, without
elaborating at the moment.

Amongst your other good points, this has the added advantage that the
root CA private key can be completely offline, and almost never
actually used.  This is important to minimise the risk of compromise,
as the root of trust and with a long-lived cert.

It also assists the policy-based mechanisms.  If we, for the sake of
argument, use different certs and possibly different ICA's for
autobuilds, releases, and security updates, an administrator can
adjust thier configuration to trust binaries from only a subset of
these - perhaps excluding nightly autobuilds on production stable
systems.

If we allow multiple signatures in the format, it leaves scope for
other signatures to add value - perhaps allowing snapshots to be
"blessed" by a testing team after rigorous shakedown (either a netbsd
or site-local testing team).

I'm quite fond of using the term "decorate" for signatures, after the
java decorator pattern, when used like this.

> Anyway, the good bit is that provided the user has one of the CA certs
> that sits above a particular signing cert (the cert associated with a
> signing key - eg NetBSD-2.0 above), then they can verify the signature
> of an otherwise unknown key.  Its the NetBSD-RootCA that they need to
> trust (at least wrt signatures relating to NetBSD).

Yes, and that leads into the policy questions. Name constrains, path
constraints, various usage constraints, etc.

> Ok, a sufficiently paranoid user will be paying attention to CRL's -
> Certificate Revocation Lists, but the majority of users will just
> click "install" and think nothing more about it.

I note with interest an email from my Thawte subscription that they
are now publishing their OCSP URI in all new certs, in anticipation
that newer browsers are shipping with OCSP checking on by default.
Given their Verisign parentage, I have my suspicions about their true
motives here (I'm sure there's interesting data to be mined from the
queries), but it's nonetheless a good thing.

> >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.=3D20
>=20
> The web of trust model is a good one for apps like peer to peer e-mail
> signing and such, but for something simple like distributing s/w the
> complexity is not worth it - except to folk who already use have
> already adopted that model.

=2E. or when the nature of the software distribution is itself
distributed, with a web of vendors (including local admins). Just
something to keep in mind.

--
Dan.

--CRrRoVXEpX/Dc4YP
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFApFZwEAVxvV4N66cRAuwkAJ9V8wBbtJHGqlGPQ1xQApZmyJZkfgCgp024
FVjCTlAd/weXEqVUIhRoGO8=
=j4m1
-----END PGP SIGNATURE-----

--CRrRoVXEpX/Dc4YP--