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

From: "Slone, Skip" <[email-masked]>
Date: Thu, 11 Jan 2001 10:45:19 -0500

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.  
 
In terms of a requirement for this WG, as I see it, we have a requirement to
be able to find the associated repository for any validly constructed
PKIX-compliant certificate. The pkixref draft solves the problem for certs
with names constructed according to 2377, but it doesn't solve the problem
for PKIX-compliant certs with names constructed otherwise.  (As far as the
argument of plucking the domain name off the email containing the cert, I'm
not convinced that we will always and in all cases be able to make an
association between a cert and an email address.)
 
I'm open to suggestions on HOW to resolve these domain-amiguous certs.  I've
outline one possible approach (using country-to-ccTLD mapping in conjunction
with a new type of DNS RR).  An alternative approach might be to define a
new certificate extension containing a repository URL.  Another suggestion
was made to include the repository URL information in the DN.  (I personally
get squeamish every time someone suggests overloading the semantics of yet
another attribute, but I could probably live through it :-)
 
That's my two cents' worth for now...
 
 -- Skip

-----Original Message-----
From: Sharon Boeyen [mailto:[email-masked]]
Sent: Thursday, January 11, 2001 8:28 AM
To: 'Oscar Jacobsson'; Slone, Skip
Cc: [email-masked]
Subject: RE: Basic Cert-2-Directory mapping question

The naming scheme (at least the higher levels of it) that is being
referenced is 
originally outlined in an informative annex to X.521 and its also in some
LDAP specs. 

In some countries this type of naming is being more readily adopted than in
others. It 
is my VERY strong belief that trying to impose a single naming structure or
a single naming 
hierarchy for all applications and all environments simply is a recipe for
disaster. The US 
has historically been the absolute most difficult place to do this in the
past (reference 
the North American Directory Forum effort that Bob references). Regulatory
differences and 
differing business models and operating environments lead to different
naming structures. 

Borrowing from Marshall Rose's writing style, let me step on my soapbox for
a minute: 

Rather than try to name the world and every object in it, I believe a more
constructive approach 
is to accept the fact that different parts of the world and different
environments will have 
use a variety of nameforms and work within that context to make the best use
of the tools we have 
at our disposal to find the information that is needed. We should not be
trying to solve the "global 
directory problem", we are the PKIX WG. We should ensure that appropriate
PKIX information can be located and 
retrieved. We are not the global naming police either and should not try to
impose the rules that 
anyone uses to name entities to which they issue certificates. Finding a
particular certificate is 
one problem and determining whether or not to 'trust' and make use of it is
another. Repository 
locator discussions should be restricted to the former. 

Step off soapbox. 

I do agree that 2377 and the PKIX repository locator document are a nice fit
and will satisfy a 
lot of the requirement for many environments. Those that use the
geographical, DNS or other style 
of DNs for the certs and directories can all be supported for applications
where the domain name is 
known. There may however be some additional support tools that can defined
to ease the 'knowledge' 
gathering process as Skip suggests. One that was raised earlier on the list
and for which we don't yet 
have an answer is the provision of search base data for LDAP SRV records for
PKI repositories. If there 
is a way to add additional information to DNS that will help resolve these
types of issues then I'm 
all for it. Another option that might be worth exploring is piggybacking
repository locator information 
in certificate management protocols (e.g. when one CA sends a cert request
to another CA it could provide 
the details of how to access its repository in that cert requests - it is
relying parties from the issuer's 
domain that will need that access). Again that won't satisfy every case,
since strict hierarchies that 
don't cross-certify with other domains wouldn't be covered). Skip, I'm not
necessarily objecting to the 
mapping you are proposing, but am trying to understand within the context of
PKI requirements and I'm not 
quite there yet :-) 

However, I really would like to see us work from a focused 'requirements'
standpoint rather 
than from the abstract level that a lot of this thread seems to have. 

Sharon 

> -----Original Message----- 
> From: Oscar Jacobsson [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Thursday, January 11, 2001 4:47 AM 
> To: Slone, Skip 
> Cc: [email-masked] 
> Subject: Re: Basic Cert-2-Directory mapping question 
> 
> 
> "Slone, Skip" wrote: 
> > Since civil-to-DNS name mapping typically fails to yield to a 
> > character string transliteration algorithm (e.g., "o=Joe's Bar and 
> > Grill" does not readily translate to are-you-hungry.com), 
> this leaves 
> > us with a choice of either registering the translations or 
> > complaining that it can't be done. 
> 
> Pardon my ignorance of these matters, but where exactly is this civil 
> naming scheme outlined? 
> 
> IMHO the DNS-based naming scheme for in RFC 2377 has been around for a 
> couple years now, and when combined with the repository locator 
> documents I'd say it provides the information necessary for an RP to 
> locate the relevant repository. 
> 
> //oscar 
>

---

From: Oscar Jacobsson <[email-masked]>
Date: Thu, 11 Jan 2001 17:38:37 +0100

"Slone, Skip" wrote:
> 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.  

True, and I don't think "recognizing" them as certificates is the issue
here. More on this as we get to your proposed requirement.

> In terms of a requirement for this WG, as I see it, we have a
> requirement to be able to find the associated repository for any
> validly constructed PKIX-compliant certificate.

I would prefer this requirement restricted to apply only to those
certificates that were consciously created for deployment on the
Internet.

Come to think of it, maybe this would be better off split into two
separate discussions. One on creating/endorsing/applying a naming scheme
that will allow us to deploy PKIs over the Internet, for which I'd say
that repository discovery would be a must, and another on handling the
"legacy" (as in non-Internet based) X.521-style certificates already in
use, probably most importantly those shipped along with our web
browsers.

> I'm open to suggestions on HOW to resolve these domain-amiguous
> certs.

The problem here is in their very ambiguity. The subjects of these
certificates are not necessarily directory entries in the first place. I
know I've personally held a sizeable amount of certificates, the
subjects _and_ issuers of which have been completely fictitious. Or
maybe not fictitious, but completely arbitrary anyway. Of all the
certificates ever issued to me, no two have ever used the same DN.

Regards,

//oscar

---

From: Stephen Kent <[email-masked]>
Date: Thu, 11 Jan 2001 16:55:31 -0500

Skip,

>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: "Jim Schaad" <[email-masked]>
Date: Fri, 12 Jan 2001 14:31:04 -0800

This does not match my memory of what was going on at the time.  My memory
said that the Issuer DN was made required to simplify the chaining issues
for building names.  I do not remember this as being pushed from the S/MIME
working group although several of us from the S/MIME working group probably
gave comments on this issue.

jim
  -----Original Message-----
  From: Stephen Kent [mailto:[email-masked]]
  Sent: Thursday, January 11, 2001 1: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: Russ Housley <[email-masked]>
Date: Mon, 15 Jan 2001 14:20:41 -0500

Jim:

There is an issue with S/MIME.  It was ONE of the reasons that we
require a non-empty issuer distinguished name in RFC 249.  In RFC
2315 (and in RFC 2630 for backward compatibility), SignerInfo structure
includes IssuerAndSerialNumber to specify the certificate that contains
the public key needed to validate the signature.  If an empty issuer
name were permitted, this match would be impossible.  Similarly, the
RecipientInfo field in the EnvelopedData uses IssuerAndSerialNumber to
specify the certificate of the intended recipient.  Again, an empty
issuer name would be counter productive.

Russ

At 02:31 PM 1/12/2001 -0800, Jim Schaad wrote:

This
does not match my memory of what was going on at the time.  My
memory said that the Issuer DN was made required to simplify the chaining
issues for building names.  I do not remember this as being pushed
from the S/MIME working group although several of us from the S/MIME
working group probably gave comments on this issue.

jim

-----Original Message-----

From: Stephen Kent
[mailto:[email-masked]]

To: Slone, Skip

Cc: [email-masked]

Skip,

<?fontfamily><?param Arial><?color><?param
0000,0000,FFFF>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.

<?/color><?/fontfamily>

<?fontfamily><?param Arial><?color><?param
0000,0000,FFFF>

<?/color><?/fontfamily>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!

<?paraindent><?param right,left><snip>

<?/paraindent>

Steve