RE: Basic Cert-2-Directory mapping question

component attributes for DNS structured DNs are currently being used and will likely continue to be used. We also seem to be in agreement that both are hierarchical name structures. I think it is also fairly safe to say that the extensions we already have in certificates, combined with the PKI repository locator service seem adequate for identifying and locating the PKI repository of interest in most cases for both types of DN structures. The single exception to this is, as pointed out by Skip, the one where all the following conditions are met: A relying party needs to obtain an end-entity certificate for which it does not know the domain name and it cannot be easily derived from information the relying party does have (and therefore the PKI repository locator service won't provide the required information) and the relying party's local environment does not have a priori knowledge of the remote domain's repository. I guess typically this would be an environment where there is more than one internediary certificate in a path because if two domains directly cross-certify with one-another they would provide repository access information to each other, otherwise the cross-certification makes no sense.

While I don't disagree with Skip's assertion that the mapping of civil DNs to DNS names might be useful in the general directory sense, I agree with Steve that this directory issue is not one that PKIX needs to tackle in general. However, if the scenario above is one that PKIX needs to find a solution to (as opposed to determining that its not relevant since Internet applications will generally have domain names and can therefore use PKI repository locator service regardless of the DN structures in the certs or the directory entries), then we have some work to do. Otherwise, we already have all the tools we need to satisfy the PKI information retrieval problem.