Subject: Re: strawman trust model
To: Daniel Carosone <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 05/19/2004 14:01:48
Content-Type: text/plain; charset=us-ascii
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=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=
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=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".
> 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=
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.
> 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.
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=
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=
> [*] 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----