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

From: "Tom Gindin" <[email-masked]>
Date: Sat, 13 Jan 2001 02:48:23 -0500

Steve:

     Isn't a substantial part of this problem the question of how to
publish a certificate in a directory where it will be searchable by a field
within SubjectAltName, most importantly the e-mail address when that is
included?  Most of the arguments which I have ever heard for including
e-mail address in the subject DN were actually searchability arguments.
The names in SubjectAltName are typically hierarchically assigned, of
course, but they aren't X.500-based.
     Assuming that an EE wants their certificate published under the e-mail
address, IMHO they should be able to request the RA or CA to perform one of
the following actions on a successful certificate issuance (using the
publication info control or a similar mechanism):
1    Add a directory attribute for e-mail address whose value is the e-mail
address in the SubjectAltName to the directory entry named by the Subject
DN.  Very often, the RA or CA has the privilege and the knowledge to do
this and the EE has only one or neither.
2    Send a certificate announcement to the domain of the e-mail address,
in the hope and (reasonable) expectation that the certificate will be
published there.

     Similar, but less practically important, considerations apply to other
addresses in SubjectAltName.  IMHO we also need to profile which directory
attributes should normally be used when indexing a certificate under fields
within SubjectAltName, especially since there are at least two fairly
common attributes for e-mail address.

          Tom Gindin

P.S. -    The opinions above are my own, and not necessarily those of my
employer.

---

From: "Steven Legg" <[email-masked]>
Date: Tue, 16 Jan 2001 14:56:28 +1100

Tom,

> -----Original Message-----
> From: Tom Gindin [mailto:[email-masked]]
> Sent: Saturday, 13 January 2001 18:48
> To: Stephen Kent
> Cc: [email-masked]
> Subject: Re: Basic Cert-2-Directory mapping question
> 
> 
> 
>      Steve:
> 

Rather than using other attributes as surrogates for searching for
certificates with particular fields (of subjectAltName or any other
component) I think it is more appropriate to have the capability to
search for those certificates directly. The refinement of the component
matching rules in my last reply to David Chadwick would make it possible
to search for entries containing certificates with a particular
SubjectAltName regardless of whether the alternate name was reflected
in any other attribute(s) in the entry. Such a solution avoids questions
about which other attributes to search, and doesn't require RAs or CAs to
populate said attributes.

Regards,
Steven

---

From: Michael Ströder <[email-masked]>
Date: Tue, 16 Jan 2001 11:27:23 +0100

Steven Legg wrote:
> > included?
> The refinement of the component
> in any other attribute(s) in the entry.

1. Now I appreciate the I-D about certificate matching rules for
LDAP very much and I think this is a promising solution for part of
the problem.

2. If subjectAltName is an RFC822 mail address very likely the
directory admin will have no problem putting that attribute in the
entry itself => even applications/servers not implementing these
matching rules will be sufficient. (But this is not the issue here
and should not prevent anybody from adding the appropriate matching
rules for subjectAltName to the I-D).

3. As described in one of my former e-mails I believe that there's a
good chance to locate a person's entry by e-mail address (with SRV
records and doing searches on the located server).

The problem I see that up to now there's no common good practice
1. to add appropriate SRV records for at least the company's
top-level domain and
2. to make a directory-based certificate repository really
searchable.
Most directories I played with are either not public or public but
unbrowsable/limited regarding searches.

Now these problems are what we face most when deploying all this
PKIX stuff. We already have a lot of mechanisms at hand but nobody
is using them. What we need is not a new I-D for defining new
technical mechanisms. IMHO what we really need are I-Ds making clear
recommendations for tying all those relevant RFCs and I-Ds together.
Then we have a chance to get implementors doing it.

Ciao, Michael.