From: Bill Studenmund (wrstudennetbsd.org)
Date: Wed May 19 2004 - 16:01:48 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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?
>
> 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
responsible for establishing and administering the CA's policy. While I
think it would be good for whatever we do to support other CAs, I think
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
it's not, it's not. Note I realize we'll need a bit more than that as just
because we have a cert in the system doesn't mean we want to necessarily
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".
>
> 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
can sign code is to just list them in a config file. openssl.conf comes to
mind.

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

> Hopefully there'll be some decent defaults and automation and tools
> and user interface and so forth to make this easier.
>
> 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.
>
> 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.
>
> Thoughts?

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

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

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

Take care,

Bill

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

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

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]