RE: Basic Cert-2-Directory mapping question

[Sharon Boeyen <sharon.boeyen@xxxxxxxxxxx>]

Hi Skip,

 

What I meant by the tools was that the SRV records are populated by CAs, some of which use the geopolitical DN style and others that use the dc style. Regardless of what style of DN they use, all queries for SRV records are based on a domain name. If that domain name is known, or can be derived (e.g. by the email application from the email address), then the SRV records can direct you to the right PKI repository.

 

The need for a screwdriver is when you don't know the domain name and can't derive it, but need to identify and locate the PKI repository for a geopolitically structured DN that you do know.

 

Cheers,

Sharon

-----Original Message-----
From: Slone, Skip [mailto:skip.slone@xxxxxxxx]
Sent: Monday, January 15, 2001 12:54 PM
To: 'Sharon Boeyen'; 'Stephen Kent'
Cc: ietf-pkix@xxxxxxx
Subject: RE: Basic Cert-2-Directory mapping question

[Sharon]  It seems that we are basically in agreement that both the 'civil attributes' type of DNs and the domain

component attributes for DNS structured DNs are currently being used and will likely continue to be used.

 

[Skip]  Agreed.

 

[Sharon]  We also seem to be in agreement that both are hierarchical name structures.

 

[Skip]  Agreed.

 

[Sharon]  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.

 

[Skip]  I'm not sure I understand what you mean by "the [tools] we already have ... seem adequate ... for both types of DN structures."  Maybe I'm overlooking the obvious, but I don't see support structures for civil-attribute-based DNs.

 

[Sharon]  The single exception to this is, as pointed out by Skip, the one where all the following conditions are met:  <snip> 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. 

 

[Skip] I see this need most acutely in those instances that occur near the boundaries of a business relationship. That is, when a relationship is in the early stages of being formed, or if some break has occured in a business relationship (due to mergers, acquisitions, etc.), there is a sharp drop in the likelihood that the requisite knowledge is already in place.  Once a relationship has been established, the whole repository locator issue becomes a moot point. Until then, it can be a big deal.  The "problem certs" are not the ones that are commercially issued; the problem arises when certificates are issued by a private CA that is certified (directly or indirectly) by a commercial CA that I happen to trust.

 

[Sharon] 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,

 

[Skip] In the absence of a well-connected DIT (complete with globally accessible first-level DSAs, a functional c=US, etc.) distributed X.500/LDAP name resolution has been, and will continue to be an unmitigated failure.  By leveraging an existing, global, ubiquitous infrastructure, the mapping I've suggested is intended to solve a big portion of this name resolution problem.

 

[Sharon]  I agree with Steve that this directory issue is not one that PKIX needs to tackle in general.

 

[Skip] While I completely agree that the charter of PKIX is NOT to solve general directory issues, it seems to me that it is within the charter of PKIX to consider problems that users report with PKIX as currently defined, and to give due consideration to whether any proposed solution does indeed solve the reported problem.  If the solution is then deemed to be too general, the work can, of course, be moved elsewhere.

 

[Sharon] 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.

 

[Skip] Agreed.  I can offer some cycles to do some of this work.

 

[Sharon] Otherwise, we already have all the tools we need to satisfy the PKI information retrieval problem.

 

[Skip] I'm still looking for something other than a hammer :-)

 

 -- Skip

-----Original Message-----
From: Sharon Boeyen [mailto:sharon.boeyen@xxxxxxxxxxx]
Sent: Friday, January 12, 2001 9:19 AM
To: 'Stephen Kent'; Slone, Skip
Cc: ietf-pkix@xxxxxxx
Subject: RE: Basic Cert-2-Directory mapping question

OK now we're getting to the 'focal' point I was hoping we would.

 

It seems that we are basically in agreement that both the 'civil attributes' type of DNs and the domain

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.

 

Sharon 

 

 -----Original Message-----
From: Stephen Kent [mailto:kent@xxxxxxx]
Sent: Thursday, January 11, 2001 4:56 PM
To: Slone, Skip
Cc: ietf-pkix@xxxxxxx
Subject: RE: Basic Cert-2-Directory mapping question

Skip,

I would just like to add that, in addition to X.521 and some LDAP specs, the ability to recognize civil naming attributes in the issuer and subject fields of an X.509v3 cert is mandated in RFC 2459 (ref section 4.1.2.4) and in son-of-2459.

Ironically, the requirement for support for Issuer names (DNs) vs. allowing an Issuer alname in lieu of a DN, arose because the S/MIME WG was relying on the presence of an Issuer DN in their design, and I believe the motivation for it (Russ can confirm or correct this notion) was to facilitate directory lookup for certs in S/MIME!

<snip>

Steve