3.4.2.2 Ensuring the Uniqueness of Distinguished Names

A fundamental requirement of this certification scheme is that certificates are not issued to distinct entities under the same distinguished name. This requirement is important to the success of distributed management for the certification hierarchy. The IPRA will not certify two PCAs with the same distinguished name and no PCA may certify two CAs with the same DN. However, since PCAs are expected to certify organizational CAs in widely disjoint portions of the directory namespace, and since X.500 directories are not ubiquitous, a facility is required for coordination among PCAs to ensure the uniqueness of CA DNs. (This architecture allows multiple PCAs to certify residential CAs and thus multiple, distinct residential CAs with identical DNs may come into existence, at least until such time as civil authorities assume responsibilities for such certification. Thus, on an interim basis, the architecture explicitly accommodates the potential for duplicate residential CA DNs.)

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 registered 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 registered 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 register 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.

If the database detects a conflicting entry (failure of case 1 above), or if the submission indicates that the PCA's perception of possible conflicting entries is not current (failure of case 2), the submission is rejected and the database will return the potential conflicting entry (entries). If the submission is successful, the database will return the timestamped new entry. The database does not, in itself, guarantee uniqueness of CA DNs as it allows for two DNs associated with different public components to be registered. Rather, it is the responsibility of PCAs to coordinate with one another whenever the database indicates a potential DN conflict and to resolve such conflicts prior to certification of CAs. Details of the protocol used to access the database will be provided in another document.

As noted earlier, a CA may be certified under more than one PCA, e.g., because the CA wants to issue certificates under two different policies. If a CA is certified by multiple different PCAs, the CA must employ a different public key pair for each PCA. In such circumstances the certificate issued to the CA by each PCA will contain a different subjectPublicKey and thus will represent a different entry in this database. The same situation may arise if multiple, equivalent residential CAs are certified by different PCAs.

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.

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 registered the user. This structure provides a degree of privacy for users registered 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.