Subject: RE: Basic Cert-2-Directory mapping question

From: Sharon Boeyen <[email-masked]>
Date: Mon, 15 Jan 2001 15:13:27 -0500

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:[email-masked]]
Sent: Monday, January 15, 2001 12:54 PM
To: 'Sharon Boeyen'; 'Stephen Kent'
Cc: [email-masked]
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:[email-masked]]
Sent: Friday, January 12, 2001 9:19 AM
To: 'Stephen Kent'; Slone, Skip
Cc: [email-masked]
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:[email-masked]]
Sent: Thursday, January 11, 2001 4:56 PM
To: Slone, Skip
Cc: [email-masked]
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

---

From: Oscar Jacobsson <[email-masked]>
Date: Tue, 16 Jan 2001 11:18:29 +0100

All,

this thread has progressed a bit since last I checked, so I hope you'll
forgive me for skipping to the front.

Regarding our precious screwdriver, the primary functional requirement
for said tool, to paraphrase Sharon, would then appear to be:

"The screwdriver shall identify and locate PKIX repositories for
Distinguished Names."

Or is it important that this method only be used failing derivation or
a-priori knowledge of the repository location?

Is it also important that the DN be "geopolitically" structured, or can
I interpret that as "non-domainComponent" structured?

Skip has already proposed a solution, which I'd like to address:

"What I'm proposing is the development of a new DNS RR type that allows
the registration of arbitrary attribute value assertions (such as
"o=Something" or "ou=Something Else"). These new RRs (let's call them
AVA RRs) would resolve to a domain name that could subsequently be used
to construct the right hand portion of a PKIXREP query (or some other
SRV-seeking query).  A remaining critical piece is the specification of
c=XX as equivalent to a corresponding ccTLD. As an example, when
resolving a DN ending in o=Entrust, c=CA, one would first query .ca for
an AVA record matching "o=Entrust", and would get a response such as
"entrust.com" which would then be used to generate a query along the
line of _PKIXREP._LDAP.entrust.com."

One issue I have with this is that it violates one of the central
premises of Sharon's "soapbox address" by placing the assumption on DNs
that they employ a specific naming scheme, in this case one with a
"C=xxx, O=xxx" root.

Regards,

//oscar

Sharon Boyen wrote:
> 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