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."
I'll try to explain it. I was not at the Boston IETF, so I'm unfamiliar
with the animosity that has developed between some members of the PEM WG
and Mr. Stefferud.
Is this whole thing just a confusion arising from choice of language in RFC
1422??
Not as far as I know. I brought up initial comments based on what I had
heard during selection of DNs for beta testing of TIS/PEM. Some of the
suggested and requested DNs were not in line with what is currently used
in the Internet Pilot and what is sugggested by NADF SD-5.
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?
For me, the use of the word "register" is not the source of my "excitement."
I will admit that limiting the possibility of duplicate DN registration does
seem out of place if the registration is already done outside of the scope
of PEM, but again, this is not the issue I was raising.
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.]
Yes, but it does not (at this point) constrain someone from setting up a
DN registry that is not aligned with the current X.500 practices. I used
to be a student at UC Berkeley. I could have had a DN of, say,
US, UCB, Peter Yee. What about University of Colorado, Boulder? The point
is that if my org DN is aligned with SD-5, I have no such problem. This is
not precisely a PEM problem (you're right, PEM shouldn't be in the
"registration" business), but a problem of ensuring that when PEM chooses
to align to a registration authority, that it chooses the "right" authority.
I've been suggesting that since X.500 is expected to play a large role in
certificate management and retrieval, that PEM choose to align to X.500
DNs (as used or suggested in the current NADF documents and the Internet
Pilot). Without naming name, I've heard of a case where an organization
wished to use its DNS name as part of its DN. Use, it would have been
a unique DN. Yes, the portion of the DN that had to be unique would have
been registered with a naming authority. But it would not have fit in well
with what we are doing with X.500. That's one of the situations I wish to
avoid. By being up front about selecting DNs and DN registration authorities,
PEM can avoid problems down the line.
[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."
Yes, that would help to ensure that CAs don't get into the registration
business unnecessarily.
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.]
And in my mind, it is merely a question of who did the registration of the
DN. Joe's Auto Garage and Distinguished Name Registry is probably not my
choice for the source of DNs used by PEM.
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.
Care should be taken with the last sentence. This has the not-currently-
registered user selecting his own distinguished name, hopefully with
some consideration taken. But the possibility certainly exists that
the user can choose a "bad" DN as well.
[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?]
That could be a problem. If I handed you a "complete certificate, minus
signature" with a DN that read US, NASA, ARC, Peter Yee, it would seem
reasonable. However, my real DN (and the one that the world knows me by)
is US, National Aeronautics and Space Administration, Ames Research Center,
Peter Yee. The first DN will only work during searches of the directory.
A direct read of that DN will fail because the components used are not
made of RDNs for those nodes in the directory. I don't wish to say that
I'm asking that PEM CAs be burdened with obtuse requirements for DN
validation, but I must state that without some validation of all DNs used
by PEM (CAs and users), there may be problems when PEM implementations
begin to rely on the growing X.500 infrastructure.
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]
Yes. Whose registration authority, though?
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
I take it that this means that you [PEM] is trying to prevent a CA from
registering more than once with the same DN.
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
Which encoding? BER? DER? PER? [Not important to my discussion!]
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?]
That would certainly be better.
[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.
I must have missed the point. Why, other than for a CA registering more
than once, would you have a duplicate DN? I assume you that a hash
collision (for two distinct values) doesn't really count as a non-unique DN.
[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.
I don't see this a contradicting the NADF suggestions, in light of what
has been discussed earlier. The term registration, though, is probably
not desirable.
In summary, my comments are PEM should not be in the registration business
(I believe we agree here), that PEM should rely on external registration
authorities for establishing DNs, and that PEM should rely on the "right"
authority, if it is to have any hope of interworking with X.500.
Hope that clarifies things.
-Peter