Re: draft-zeilenga-ldap-user-schema

[Harald Tveit Alvestrand <harald@alvestrand.no>]

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).

> 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).

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.

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.

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.

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.

Delaying this until the retreat seems like a sensible course; there are few 
disasters that will occur in 2 more weeks.

                          Harald