Re: draft-zeilenga-ldap-user-schema

[Russ Housley <housley@vigilsec.com>]

Harald:

> I found the definition of ;binary with a little searching.
> RFC 2252, from December 1997:
>
> 4.3.1  Binary Transfer of Values
>
>   This encoding format is used if the binary encoding is requested by
>   the client for an attribute, or if the attribute syntax name is
>   "1.3.6.1.4.1.1466.115.121.1.5".  The contents of the LDAP
>   AttributeValue or AssertionValue field is a BER-encoded instance of
>   the attribute value or a matching rule assertion value ASN.1 data
>   type as defined for use with X.500. (The first byte inside the OCTET
>   STRING wrapper is a tag octet.  However, the OCTET STRING is still
>   encoded in primitive form.)
>
>   All servers MUST implement this form for both generating attribute
>   values in search responses, and parsing attribute values in add,
>   compare and modify requests, if the attribute type is recognized and
>   the attribute syntax name is that of Binary.  Clients which request
>   that all attributes be returned from entries MUST be prepared to
>   receive values in binary (e.g. userCertificate;binary), and SHOULD
>   NOT simply display binary or unrecognized values to users.
>
> Formally, this is not obsoleted, and draft-zeilenga does not touch it.
> (BTW, ;binary was ADDED in the transition from LDAPv2 to LDAPv3.... I 
> think something like it had been used without specification in LDAPv2, but 
> I think the first formal definition was in LDAPv3 - exactly to fix the 
> certificate problem).
This is not the history that Kurt Zeilenga shared when we met face-to-face 
to discuss this intertwined issue.  He said that ;binary is used with 
LDAPv2 to fetch certificates and CRLs, and that it is no longer used in 
LDAPv3.  Perhaps he was describing real implementation behaviour.

> From RFC 2798, "The LDAP inetOrgPerson object class", one can see that 
> userSMIMECertificate and userPKCS12 have the ...121.1.5 syntax.
> The "userCertificate" attribute does NOT have this syntax (but that 
> definition is rather useless anyway).
There is a separate long history on that point.  Let's not confuse the 
issues.  This one has enough complexity.

> RFC 2985, the PKCS#9 republication, specifies the ..121.1.5 syntax for all 
> its crypto-related attributes. So those attributes are intended to be 
> handled as "binary" anyway.
>
> WRT referenced drafts:
>
> draft-klasen-ldap-x509certificate-schema "explodes" a certificate into its 
> component elements, so that matching can occur on any certificate element.
Yes.  This is the proposal that the working group does not 
support.  However, there are at least two implementations.  This is the 
reason that the supporters want to publish it as an Informational or 
Experimental.  My BIG issue is that the attributes are stored in different 
places DIT.  So, a direct read of the attributes is not possible unless the 
embedded client knows which schema is being used by the server.  So, if 
both are permitted to go forward.  clients will have to use searches, even 
when they know the Distinguished Name and the exact attribute that they want.

> draft-legg-ldapext-component-matching describes a matching rule of quite 
> horrific complexity, but with the power to match any ASN.1 component of 
> any object represented in ASN.1 - so that you could theoretically ask for 
> matching on the middle initial of an X.400 address embedded in a 
> certificate that is part of a CRL list. It also presupposes that LDAP 
> servers have access to the ASN.1 definition of the syntax for data stored 
> as ASN.1 - something that is rather horrifying to me.
Yes.  This is the solution that the working group wants to make a 
standards-track RFC.  No installed server can do the on-the-fly ASN.1 
processing today.

> But still - I can't find the linkage between 
> draft-zeilenga-ldap-user-schema and the ;binary mess - I can't see how 
> approving (or not) draft-zeilenga-ldap-user-schema affects certificate storage.
I have come to the same conclusion.  I sent a no-objection vote last 
night.  However, this issue is coming,  It will need to be handled 
soon.  We should probably spend a few minutes talking about it on the retreat.

> The link I can see would be blocking anything in LDAP space until they 
> have sorted out the cert mess - but that's a RATHER drastic measure.
Agree.

> Delaying this until the retreat seems like a sensible course; there are 
> few disasters that will occur in 2 more weeks.
As I said, I am not going to delay this document, but I do look forward to 
airing this issue with the whole IESG at the retreat.

Russ