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

On Wed, May 19, 2004 at 09:51:45AM +1000, Daniel Carosone wrote:
> How about this for a model, illustrated with technology-specific
> examples for the sake of brevity?
>=20
> Every new NetBSD host generates its own openssl x.509 CA, analogous to
> the way it might currently generate ssh host keys, but the owner
> (root) is asked to enter a passphrase to protect the private key.

I'm puzzled by this. By making each box its own CA, we make each admin=20
responsible for establishing and administering the CA's policy. While I=20
think it would be good for whatever we do to support other CAs, I think=20
the common case should just be to trust the TNF root CA.

> That key is installed in the relevant places (/etc/openssl/certs), and
> flagged as trusted and usage contraints / critical oid's relevant to
> our needs (to be designed).

Note that this implicitly is a CA. :-) If a cert is ok, it's installed. If=
=20
it's not, it's not. Note I realize we'll need a bit more than that as just=
=20
because we have a cert in the system doesn't mean we want to necessarily=20
use it as a code signer.

> The user gets to decide which other certificates to trust, based on
> whatever criteria and process they prefer - including other
> cryptosystems, established public record, or "the one that came with
> the release I just installed".
>=20
> That trust decision is mapped by either installing additional certs in
> the directory, or (preferably) by issuing a cross-certificate to it
> from the host's CA (again, with suitable constraints for purpose) and
> installing that.[*]

Why use cross-certificates? I think an easier way to indicate what certs=20
can sign code is to just list them in a config file. openssl.conf comes to=
=20
mind.

Cross-certs would make a lot of sense if we had two full-fledged CAs and=20
wanted to merge/integrate them. I don't think we need that much here.=20

> Hopefully there'll be some decent defaults and automation and tools
> and user interface and so forth to make this easier.
>=20
> If our administrator is looking after a site with a large collection
> of machines, they would of course use just the one CA, and install
> that trust root on all their machines.  Such a site would quite likely
> generate some additional certs of their own, such as for signing their
> own builds, patches, binary packages, etc.
>=20
> This seems like it would work quite nicely for packaging, as well as
> facilitating other uses like server and user certificates for local
> https/imaps/ike, etc.
>=20
> Thoughts?

If a site wants to run its own CA, I think it's great to merge all the=20
different uses together. However I don't think most users want all that. I=
=20
think we can get by with something much simpler, and then have a HOW-TO on=
=20
www.netbsd.org describing how to do what you list above (which I think we=
=20
need anyway!).

> [*] I'm not sure if openssl processes cross certificates, anyone know?

I think that certificate hierarchy verification is something openssl=20
leaves to the application. There is so much policy that can get worked=20
into this that I think openssl's doing the right thing. It's a pain, but=20
probably for the best.

Take care,

Bill

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

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

iD8DBQFAq8s8Wz+3JHUci9cRAt1dAJ92Eh3ZVZ7UpMFpeYBoFxDOJPdWgACeKlWT
vq6VASwDzDiGDJNOyjaDl6g=
=xsQP
-----END PGP SIGNATURE-----

--liOOAslEiF7prFVr--