Peter,
I'm still trying to find out just what in the PEM RFCs, presumably only in
RFC 1422, that needs to be "aligned" with SD-5. Would you please try to
explain it to me in small words? Mr. Stefferud points out that there are
"many subtle concepts" involved, and I obviously don't understand what is
going on here. Mostly, I don't understand why anyone would think that
"PEM and friends appear to want to establish a new (different) global name
registration system in parallel with the existing national civil naming
infrastructures."
Is this whole thing just a confusion arising from choice of language in RFC
1422??
Ella Gardner suggests that the following paragraph, which is found in RFC
1422 in 3.4.2.2, Ensuring the Uniqueness of Distinguished Names, appears to
make the CA a registration authority for names.
To complete the strategy for ensuring uniqueness of DNs, there is a
DN subordination requirement levied on CAs. In general, CAs are
expected to sign certificates only if the subject DN in the
certificate is subordinate to the issuer (CA) DN. This ensures that
certificates issued by a CA are syntactically constrained to refer to
subordinate entities in the X.500 directory information tree (DIT),
and this further limits the possibility of duplicate DN registration.
CAs may sign certificates which do not comply with this requirement
if the certificates are "cross-certificates" or "reverse
certificates" (see X.509) used with applications other than PEM.
Having worked on PEM for a long time, I know that this does not mean that
the PEM infrstructure registers DNs. Names are "registered" somewhere
else. The only thing a CA does is bind a name to a public key, and also
list CA names in a registry that allows PCAs to avoid duplciation. Is the
use of the word "register" the source of all the excitement?
I have pulled out of RFC 1422 each piece of text that includes the word
fragment "regist":
-----
The infrastructure specified in this document establishes a single
root for all certification within the Internet, the Internet Policy
*Regist*ration Authority (IPRA).
[The name IPRA has already been changed for legal reasons. (Steve Crocker,
would you remind us of the new name?) Anyway, names are not being
registered, just the fact that a particular authority is associated with a
particular policy and public key.]
Initially, we expect the majority of users will
be *regist*ered via organizational affiliation, consistent with current
practices for how most user mailboxes are provided. In this sense
the *regist*ration is analogous to the issuance of a university or
company ID card.
[This is just a background discussion of PEM's environment, in which
somebody (not us) registers DNs.]
[The next use of *regist*er is a little confusing. It means that a PEM
user who want a certificate that is not subordinate to an organizational CA
can get one. So maybe it should say "who wish to BE ISSUED A CERTIFICATE
independent of any organizational certification."
Some CAs are expected to provide certification for residential users
in support of users who wish to *regist*er independent of any
organizational affiliation. Over time, we anticipate that civil
government entities which already provide analogous identification
services in other contexts, e.g., driver's licenses, may provide
this service. For users who wish anonymity while taking advantage of
PEM privacy facilities, one or more PCAs will be established with
policies that allow for *regist*ration of users, under subordinate CAs,
who do not wish to disclose their identities.
The
architecture describes procedures for *regist*ering certification
authorities and users, for generating and distributing certificates,
and for generating and distributing CRLs.
[The DNs are not being registered. We are just registering that fact that
an entity with an (already registered, hopefully) DN is going to be a CA,
or that the entity is going to be a PEM user under a certain CA.]
A certificate provides a representation of its subject's identity in
the form of a Distinguished Name (DN). The fundamental binding
ensured by the key management architecture is that between the public
component and the user's identity in this form. A distinguished name
is an X.500 directory system concept and if a user is already
*regist*ered in an X.500 directory, his distinguished name is defined
via that *regist*ration. Users who are not *regist*ered in a directory
should keep in mind likely directory naming structure (schema) when
selecting a distinguished name for inclusion in a certificate.
The following sections
identify four types of entities within this architecture: users and
user agents, the Internet Policy *regist*ration Authority, Policy
Certification Authorities, and other Certification Authorities. For
each type of entity, this document specifies the procedures which the
entity must execute as part of the architecture and the
responsibilities the entity assumes as a function of its role in the
architecture.
[The following is not name registration either.]
3.4.1.2 User *regist*ration
Most details of user *regist*ration are a local matter, subject to
policies established by the user's CA and the PCA under which that CA
has been certified. In general a user must provide, at a minimum,
his public component and distinguished name to a CA, or a
representative thereof, for inclusion in the user's certificate.
(The user also might provide a complete certificate, minus the
signature, as described in RFC 1424.) The CA will employ some means,
specified by the CA in accordance with the policy of its PCA, to
validate the user's claimed identity and to ensure that the public
component provided is associated with the user whose distinguished
name is to be bound into the certificate. (In the case of PERSONA
certificates, described below, the procedure is a bit different.) The
certifying authority generates a certificate containing the user's
distinguished name and public component, the authority's
distinguished name and other information (see Section 3.3) and signs
the result using the private component of the authority.
[Is the problem that in the foregoing the CA is not required to make sure
that the DN provided in the "complete certificate, minus signature" is
already properly "registered" somewhere?]
3.4.2 The Internet Policy *regist*ration Authority (IPRA)
[Name change aside, no DNs are being registered in this section, only the
fact that an entity with a given DN is associated with a given policy and
public key.]
3.4.2.1 PCA *regist*ration
As part of *regist*ration, each PCA will be required to execute a legal
agreement with the IPRA, and to pay a fee to defray the costs of
operating the IPRA. Each a PCA must specify its distinguished name.
The IPRA will take reasonable precautions to ensure that the
distinguished name claimed by a PCA is legitimate, e.g., requiring
the PCA to provide documentation supporting its claim to a DN.
[Here we point to the fact of a registration outside the PEM certification
system]
However, the certification of a PCA by the IPRA does not constitute a
endorsement of the PCA's claim to this DN outside of the context of
this certification system.
In support of the uniqueness requirement, the IPRA will establish and
maintain a database to detect potential, unintended duplicate
certification of CA distinguished names. This database will be made
accessible to all PCAs via an email interface. Each entry in this
database will consist of a 4-tuple. The first element in each entry
is a hash value, computed on a canonical, ASN.1 encoded
representation of a CA distinguished name. The second element
contains the subjectPublicKey that appears in the CA's certificate.
The third element is the distinguished name of the PCA which
*regist*ered the entry. The fourth element consists of the date and
time at which the entry was made, as established by the IPRA. This
database structure provides a degree of privacy for CAs *regist*ered by
PCAs, while providing a facility for ensuring global uniqueness of CA
DNs certified in this scheme.
[Perhaps this last use of *regist*ered could be changed to certified or
some other word?]
[In the next, we are *regist*ering the fact that a DN has already been
taken for use by a CA. Perhaps we could say *list*ing?]
In order to avoid conflicts, a PCA should query the database using a
CA DN hash value as a search key, prior to certifying a CA. The
database will return any entries which match the query, i.e., which
have the same CA DN. The PCA can use the information contained in
any returned entries to determine if any PCAs should be contacted to
resolve possible DN conflicts. If no potential conflicts appear, a
PCA can then submit a candidate entry, consisting of the first three
element values, plus any entries returned by the query. The database
will *regist*er this entry, supplying the time and date stamp, only if
two conditions are met: (1) the first two elements (the CA DN hash
and the CA subjectPublicKey) of the candidate entry together must be
unique and, (2) any other entries included in the submission must
match what the current database would return if the query
corresponding to the candidate entry were submitted.
In support of the uniqueness requirement, the IPRA will establish and
maintain a database to detect potential, unintended duplicate
certification of CA distinguished names. This database will be made
accessible to all PCAs via an email interface. Each entry in this
database will consist of a 4-tuple. The first element in each entry
is a hash value, computed on a canonical, ASN.1 encoded
representation of a CA distinguished name. The second element
contains the subjectPublicKey that appears in the CA's certificate.
The third element is the distinguished name of the PCA which
*regist*ered the entry. The fourth element consists of the date and
time at which the entry was made, as established by the IPRA. This
database structure provides a degree of privacy for CAs *regist*ered by
PCAs, while providing a facility for ensuring global uniqueness of CA
DNs certified in this scheme.
In order to avoid conflicts, a PCA should query the database using a
CA DN hash value as a search key, prior to certifying a CA. The
database will return any entries which match the query, i.e., which
have the same CA DN. The PCA can use the information contained in
any returned entries to determine if any PCAs should be contacted to
resolve possible DN conflicts. If no potential conflicts appear, a
PCA can then submit a candidate entry, consisting of the first three
element values, plus any entries returned by the query. The database
will *regist*er this entry, supplying the time and date stamp, only if
two conditions are met: (1) the first two elements (the CA DN hash
and the CA subjectPublicKey) of the candidate entry together must be
unique and, (2) any other entries included in the submission must
match what the current database would return if the query
corresponding to the candidate entry were submitted.
[Finally, does the following subordination requirement contradict or become
impossible under the NADF rules? I don't think so. If so, please point
out the text for us.]
To complete the strategy for ensuring uniqueness of DNs, there is a
DN subordination requirement levied on CAs. In general, CAs are
expected to sign certificates only if the subject DN in the
certificate is subordinate to the issuer (CA) DN. This ensures that
certificates issued by a CA are syntactically constrained to refer to
subordinate entities in the X.500 directory information tree (DIT),
and this further limits the possibility of duplicate DN *regist*ration.
CAs may sign certificates which do not comply with this requirement
if the certificates are "cross-certificates" or "reverse
certificates" (see X.509) used with applications other than PEM.
The IPRA also will establish and maintain a separate database to
detect potential duplicate certification of (residential) user
distinguished names. Each entry in this database will consist of 4-
tuple as above, but the first components is the hash of a residential
user DN and the third component is the DN of the residential CA DN
which *regist*ered the user. This structure provides a degree of
privacy for users *regist*ered by CAs which service residential users
while providing a facility for ensuring global uniqueness of user DNs
certified under this scheme. The same database access facilities are
provided as described above for the CA database. Here it is the
responsibility of the CAs to coordinate whenever the database
indicates a potential conflict and to resolve the conflict prior to
(residential) user certification.
Users may wish to obtain certificates which do not imply any
organizational affiliation but which do purport to accurately and
uniquely identify them. Such users can be *regist*ered as residential
persons and the DN of such a user should be consistent with the
attributes of the corresponding X.521 object class. Over time we
anticipate that such users will be accommodated by civil government
entities who will assume electronic certification responsibility at
geographically designated points in the naming hierarchy. Until
civil authorities are prepared to issue certificates of this form,
residential user CAs will accommodate such users.
The public component needed to validate certificates signed by the
IPRA is made available to each user as part of the *regist*ration or
via the PEM installation process. Thus a user will be able to
validate any PCA certificate immediately. CAs are certified by PCAs,
so validation of a CA certificate requires processing a validation
path of length two. User certificates are issued by CAs (either
immediately subordinate to PCAs or subordinate to other CAs), thus
validation of a user certificate may require three or more steps.
Local caching of validated certificates by a UA can be used to speed
up this process significantly.