--ik0NlRzMGhMnxrMX
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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.

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).

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.[*]

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?

--
Dan.

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


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

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

iD8DBQFAqqGREAVxvV4N66cRAp15AKD0FNSqk55sKWssBQ7bCSXZO0z1eQCgpzMl
pJjrTNkaNcPMMQPuZx3Klcw=
=snjN
-----END PGP SIGNATURE-----

--ik0NlRzMGhMnxrMX--