Peter,
I think there is some confusion here. Appendix B is not yet
written, as you may have guessed, and that may have added to the
confusion. But I think the concern you raised is based on a
misinterpretation of the service provided by the ICA DN conflict
avoidance databases.
These databases, for CAs and for residential users, do not
cause certificates to be issued. The entries do not contain the DNs
of the CAs or users they represent, only hashes thereof. Creation of
an entry in either of these databases merely indicates an intent to
issue a certificate by a PCA or CA. You do make a good point in
noting that controlling access to the databases may be useful, but
I don't think such access control is critical to prevent issuance of
bogus certificates. I had envisioned using PEM (MIC-ONLY) messages to
access the database, but I'm holding off on that detail until it can
be discussed at the IETF meeting.
Also, you suggest that a centralized database might become a
bottleneck, which it might, but do recall that these database are
accessed only by PCAs and residential CAs, not by ALL CAs or by ANY
users. The informal model for use of the databases is as follows:
Scenario A (PCA use)
1. A PCA is asked to certify a CA. The PCA requires some
form(s) of identifying data from the entity requesting certification,
in support of the claimed DN.
2. The PCA queries the CA database to see if it or any other
PCA has registered a CA with the same DN.
3. If no matches are found, the PCA makes an entry and may
certify the CA. If there are matches, the PCA contacts the PCA(s)
which have registered the same DN to determine if there is a real
conflict. (Remember that the same CA may be registered under two
different PCAs, so long as two different component pairs are
employed.) If there is a real conflict, the two PCAs involved must
coordinate to resolve the conflict before the new CA can be certified.
The database is such that it will NOT accept duplicate DNs with
identical public keys, so it enforces some level of DN conflict
resolution, although the real responsibility is that of the PCAs.
Scanario B (Residential CA use)
1. The (residential) CA requests some form(s) of
identification from the user in suppotr of the user's claim to the DN.
2. The CA queries the residential user database to determine
if there are any residential DN already certified are in conflict.
3. If no matches are found, the CA makes an entry and
certifies the user. If there is a match, the CA contacts the CA which
registered the conflicting DN to resolve the conflict. Resolution
might be effected by requiring more information from a user, to
differentiate among the conflciting DNs. Also, as above, it is
possible that the residential user wants to be certified under two
different policies offered by different residential CAs, in which case
the entry can be made so long as the user employs two different
component pairs. Once the conflict is resolved, the residential user
can be certified, and an entry made for him in this database.
Note that organizational users and subordinate organizational
CAs are NOT registered in either database, since the uniqueness of
their names is ensured by the DN subordination rule of the ICA policy.
Finally, your message began with a sugegstion about including
text that would help to show how DN conflicts are avoided by the
overall certificatin system. I do believe that the answer is
contained in the text, but it probably is not concisely stated. We
can try to addres that by providing a summary, focused on that topic,
at some point in the document.
Steve