From: Steve Kent <kent(_at_)bbn(_dot_)com>
To: p(_dot_)churchyard(_at_)ic(_dot_)ac(_dot_)uk
cc: pem-dev(_at_)tis(_dot_)com
Date: Thu, 30 Dec 93 12:12:52 -0500
Subject: Re: Name Subordination
Peter,
Each PEM UA must have the IPRA public key available to it.
That key is unique because it is not in a certificate and it is the
root of all certification paths.
Although the Internet hierarchy is important, our experience suggests
it's not adequate to build a PEM implementation that recognizes only
one root for all certification paths. I think it's helpful to have a
mechanism that supports a broader set of certification rules, if only
to handle various transition matters.
If it's possible to open up the model without destroying it entirely,
I think the community would be well served.
I've proposed one model for doing this which is to have each
implementation hold not just one but a set of certification roots, and
to have a separate method of inserting these roots into the local
store. Under this view, the PCAs, not the IPRA, are the roots of the
certification paths. The IPRA can then be viewed as a speaker who
authorizes the insertion of new PCAs into the local store. There
might exist other methods of inserting roots, e.g. manually.
One advantage of this scheme is that a policy can be attached to each
root. The policy can include both a written document and a set of
rules governing name subordination.
The IPRA signs ceretificates only
for PCAs, thus a PCA certificate is easily identified by being signed
by the IPRA. While we have been waiting to the IPRA to come into
existence, a good PEM implementation might provie a facility for users
to accept PCA public keys and insert them into the cache. These have
to be treated specially, in the absence of the IPRA, as they cannot be
signed (other than self-signed) and thus should require some special
effort to be inserted into the cache. There is no requirement for any
special name string to appear in a PCA DN, or for that DN to have a
specific form.
Steve