Subject: RE: Issues in LDAP schema IDs

From: "Steven Legg" <[email-masked]>
Date: Fri, 1 Aug 2003 14:14:19 +1000

David,

David Chadwick wrote:
> Peter and I have resolved all the issues described at the PKIX meeting
> today, apart from one, which is what should be the attribute 
> type to be
> used to hold the X.509 DER encoded attribute. Should it be 
> the original
> attribute type name e.g. userCertificate or a new attribute 
> whose schema
> says it must be single valued. Comments please to the list to help us
> resolve this final issue.

If the original attribute type name is used in the child entry then
a client that uses the X.509 matching rules, or component matching rules,
to match certificates in situ will get each certificate twice. Once in a
subject's entry and once in a child entry of the subject. If a new
attribute type is used then the child entries will not normally be seen
by clients directly matching on certificates.

Clients not using direct matching have to be configured to search on
the extracted attributes. Configuring them to also ask for the new
attribute type shouldn't be a serious impediment.

Regards,
Steven

---

From: Michael Ströder <[email-masked]>
Date: Fri, 01 Aug 2003 15:14:59 +0200

Steven Legg wrote:
> subject's entry and once in a child entry of the subject.

Steven, I see your point. But doesn't that depend on the syntax used for the 
attribute?

> attribute type shouldn't be a serious impediment.

Unfortunately while most clients (e.g. MUA) allow to tweak an LDAP filter 
they won't allow you to configure the attribute from which to grab the cert.

Ciao, Michael.

---

From: "Steven Legg" <[email-masked]>
Date: Tue, 5 Aug 2003 10:00:23 +1000

Michael,

> Steven, I see your point. But doesn't that depend on the 

Huh? The old and new attribute types would have the same syntax
(i.e. Certificate).

Regards,
Steven

---

From: David Chadwick <[email-masked]>
Date: Tue, 05 Aug 2003 13:54:40 +0100

Steven Legg wrote:
> to match certificates in situ will get each certificate twice.

Steven

In this scenario, the LDAP server supports direct matching on X.509
attributes, and therefore does not need to store the child entries.
Therefore only one attribute will be there to be retrieved. The child
entries, and associated attribute extraction mechanism, has only been
introduced because LDAP servers and clients dont support direct matching
on X.509 attributes. If they had, then attribute extraction would never
have been needed. As it is, only one attribute (in the child entry) will
be retrieved by today's LDAP clients.

I do however agree that there will be a migration issue, if and when
some LDAP clients and servers support the direct matching, whilst others
dont. The direct matching clients will receive two entries, with
different RDNs, containing the same attribute. But this is not a real
problem is it? They can be configured to ignore the child entries since
these DNs wont match the DNs in the certificates. How long the problem
will persist will depend upon how quickly implementors move from the
extraction mechanism to the direct matching mechanism.

> Once in a

The reason I dont want to use a new attribute type, is that thousands
(if not millions) of clients are already using the currently defined
attribute types, and I dont want to have to make them change
unnecessarily.

> attribute type shouldn't be a serious impediment.

I am not in a position to state whether it will or will not be a serious
impediment to PKI clients to change the names of the attributes that
they are using today. I suggest it could be a serious impediment to
some. It would be nice to hear from PKI client vendors and users about
this.

regards

David.

> Steven

-

---

From: Leif Johansson <[email-masked]>
Date: Sat, 09 Aug 2003 11:38:05 +0200

David Chadwick wrote:

<snip>

>extraction mechanism to the direct matching mechanism.
You assume that directory dn structure and certificate dn structure 
match in
general. That sounds like a pretty big assumption to me.

       Cheers Leif