Subject: Certificate vs. directory DN schemas

From: "Bob Jueneman" <[email-masked]>
Date: Fri, 22 Sep 2000 09:38:34 -0600

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