Subject: Certificates by e-mail address in directory schemas

From: [email-masked]
Date: Mon, 25 Sep 2000 19:45:04 -0400

Since PKIX suggests that e-mail addresses be placed in the
SubjectAltName extension, and much relying party software would find
looking certificates up by e-mail address highly useful, what publication
technique is endorsed which would allow relying party software to find
certificates in a directory using the e-mail address as the primary input
to their "find heuristic"?  Irrespective of where in the certificate the
e-mail address should go, relying parties are interested in where in the
directory they can find the certificate.  This does not imply that there is
anything wrong with having S/MIME, TLS, or CMS send the originator's
certificate (IMO that is perfectly reasonable), but that many applications
want to discover a potential recipient's e-mail certificate without having
to rely on a previous message sent by that user.
     I am not sure whether it should be part of the PKIX LDAP schema work
to define where in the directory CA's who wish to publish a certificate
under its e-mail address should put it, or whether that work belongs in the
S/MIME WG, but shouldn't the location be defined within one of those
efforts?
     BTW, In view of some of the reasons why e-mail addresses are
deprecated within DN's, I am fairly sure that the MPEG of your cat would be
better placed in SubjectDirectoryAttributes.

          Tom Gindin

P.S. These opinions are mine personally, and not necessarily those of my
employer.

"Bob Jueneman" <[email-masked]> on 09/22/2000 11:38:34 AM

To:   <[email-masked]>
cc:   <[email-masked]>
Subject:  Certificate vs. directory DN schemas

Anders,

As someone who was once rather infamous for suggesting that I  could
include an MPEG movie of me playing with my cat in the  DN of my
certificate and still be in conformance with  X.509, I feel your pain.

(I would point out that such a bizarre usage would be a  syntactically and
semantically valid RDN, as opposed to  stuffing an RFC822 name into a
commonName, or inscribing  liability statements in OUs.  That sort of
egregious  mistyping of RDN components should have disappeared with X.509
version 1.)

I think we can easily agree that matching the directory and  certificate DN
schemas is pretty easy for a CA -- if they  don't like the proposed DN,
they won't issue the  certificate.

But I'm more interested in your thoughts about the role that  the directory
plays for the relying party.

At present, of course, virtually all of the protocol standards  are at best
agnostic and at worst verging on hostile to the  notion of a directory, and
so SSL and S/MIME implementations  insist on wasting bandwidth and in some
cases storage, sending the same certificates down the line over and over
again, instead  of looking them up as required.  (The inappropriate use  of
real-time validation protocols such as OCSP instead of  cacheable CRLs make
this problem even worse, but that is a  different discussion.)

But you said:

>In IIS (MS Webserver), you can apply "rules"
>to DN  interpretation which of course is due to the fact that there seldom
is
>a  clean 1-1 match between a DN and OS user, customer etc. etc.
>By using  such mechanisms an RP can BTW handle a lot of certificates
>and CAs  WITHOUT having all DN components in directories.  Just the
"important"  ones.
>(For encryption purposes you have to store the entire certificate  blob
though)

I'd be quite interested to learn what kinds of applications or  servers are
in fact starting to handle such certificates,  and to use directories to
store them in, as well as any  emerging trends you might be seeing.

Are these certificates being used for authentication and  access control,
primarily, or is something closer to true  digital
signatures/nonrepudiation involved?  Likewise, you mentioned encryption --
are you seeing applications other than  standard e-mail packages making use
of encryption for end users?

Where do you think this is going, and when is it going to have  a
noticeable impact on commerce and/or the use of  directories?

Moreover, are you (or anyone else) seeing this across the  board, or is it
more common in certain countries than  others, or with certain servers,
platforms, or  applications?

Regards,

Bob

Robert R. Jueneman
Security Architect

Novell -- the  leading provider of Net services  software.

>>> "Anders Rundgren"  <[email-masked]> 09/21/00 05:03PM >>>
Phil et  al.

> We are all agreed upon
>what the architecture SHOULD look  like. The question is simply one of
>how we migrate towards that  architecture.

Regarding this architecture that we all should migrate  to:

There is AFAIK no standard set of attributes that CAs always  support
which IMO means that DN components is a deployment issue and
are  usually profiled for specific uses.  Due to this lack of  conformance
each certificate class/type needs its own directory  structure.
This assuming that the DN is a multi-valued pointer into a  directory tree
which is definitely not always true.  In IIS (MS  Webserver), you can apply
"rules"
to DN interpretation which of course is due  to the fact that there seldom
is
a clean 1-1 match between a DN and OS user,  customer etc. etc.
By using such mecanisms an RP can BTW handle a lot of  certificates
and CAs WITHOUT having all DN components in directories.   Just the
"important" ones.
(For encryption purposes you have to store the  entire certificate blob
though)

Such solutions were maybe not what the  X509 designers had in mind but this
is where we are.  And it actually  works!

Permanent Identifiers (today usually extracted from DNs and in the  future
implemented through the
coming PI draft) ease this process even more.  And of course diminish the
connection between
a certificate DN and a matching  (X500) directory entry even further.
X509.v3 certificates are  maybe
slowly (but surely) moving away from their original architectural  home?

That CAs usually store certificates in directories exactly matching  their
issued certificates
is natural and easy to do compared to the situation  for RPs that usually
outnumber their CAs by
several orders of magnitude.

<snip>

>My VeriSign Certificate has the email address  encoded in SubjectAltName
>and not in the DN. So we certainly have the  ability to support 2459.
>The 'problem' seems to be that we also support  other profiles if
>the customer selects them.

If the custumer  orders a VeriSign class #1 certificate or uses the MS
CertSrv
(that does not  support the 2459 e-mail solution except by forcing the
customer
to write  their own policy module), you really don't have this option.

Note: I  don't complain about neither VeriSign or MSFT.  It is just an
observation  which
I tried to map on 2459 with limited success.

Regards
Anders

---

From: Nada Kapidzic Cicovic <[email-masked]>
Date: Wed, 27 Sep 2000 10:14:52 +0200

>S/MIME WG, but shouldn't the location be defined within one of those

A way (the way ?) for doing this is for the CA to populate MAIL attribute 
of the EE directory entry with the e-mail address from the subjectAltName 
at the same time when it populates userCertificate attribute with the 
certificate. In this way users have the possibility to search the directory 
tree based on the e-mail addresses, while the naming and directory schema 
is not destroyed by having e-mail as one of the RDNs.

Regards,
Nada

>P.S. These opinions are mine personally, and not necessarily those of my

______________________________________________________________

Nada Kapidzic Cicovic, Ph.D.
Technical Director

Entegrity Solutions AB

phone:  + 46 (0)8 477 77 37
cell:   + 46 (0)70 495 09 03
fax:    + 46 (0)8 477 77 31

Finlandsgatan 60, SE-164 74 Kista, Sweden