Subject: Re: 2459 disapproved by MSFT and VeriSign?

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 22 Sep 2000 01:03:09 +0200

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: "Robert Klerer" <[email-masked]>
Date: Fri, 22 Sep 2000 12:32:35 -0400

Please forgive my input on a debate that some feel is long past closed, but
Anders does bring up an interesting issue that has been annoying me lately.

That is the fact that in many current implementations of pki, we have
mapping mechanisms for names.  If the name in the certificate must be
translated for use by the  Relaying Parties, whether they be human or
software, does that infer some doubt in it veracity of the certificate?

Robert

----- Original Message -----
From: "Anders Rundgren" <[email-masked]>
To: "Philip Hallam-Baker" <[email-masked]>; "'Stephen Kent'"
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, September 21, 2000 7:03 PM
Subject: Re: 2459 disapproved by MSFT and VeriSign?