RE: ;binary and userCertificate (Was: Private email ...)

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

Kurt,

It seems that much of your argument hinges on ASN.1 definitions of LDAP
syntaxes. You referred me to RFC 2252 Section 4.3.2 for this. I read that
section but could find no ASN.1 definitions.

You also seem to think there are two ways to use DNs, in particular, the use
of a DN as an attribute value allows the X.500 encoding. But look at Section
6.9 of RFC 2252 -

   Values in the Distinguished Name syntax are encoded to have the
   representation defined in [5].  Note that this representation is not
   reversible to an ASN.1 encoding used in X.500 for Distinguished
   Names, as the CHOICE of any DirectoryString element in an RDN is no
   longer known.

That is, ALL DNs are strings and no other definition exists for them.

You also make some statement about X.500 gateways. This is surely an
implementation issue. If gatewaying were part of the LDAP standard then
rules would have to be defined, particularly, rules for converting LDAP
values to and from X500 values would have to be specified.

Regarding the ;binary encoding of attributes on the mailing list, I just
read, memorise and delete. I think Tim Howes was advising someone about
wrapping strings, particularly that there would be two octet string tags
around the string.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Thursday, 21 February 2002 17:32
To: Ramsay, Ron
Cc: LDAP BIS
Subject: RE: ;binary and userCertificate (Was: Private email ...)


At 06:55 PM 2002-02-20, Ramsay, Ron wrote:
>-----Original Message-----
>From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
>Sent: Thursday, 21 February 2002 13:03
>To: Ramsay, Ron
>Cc: LDAP BIS
>Subject: RE: ;binary and userCertificate (Was: Private email ...)
>
>
>At 05:00 PM 2002-02-20, Ramsay, Ron wrote:
>>Where is your idea of returning an X500 DN by asking for dn;binary spelled
>>out?
>
>I was referring to attributes of DN syntax, not to a DN
>of an entry.  Maybe using attributes of directoryString syntax
>in the example would make a less confusing.
>
>[RR] I was also referring to attributes.
>
>;binary applies to all attributes.  A client can request CN;binary,
>member;binary, userCertificate;binary, etc..  In all cases, if the
>server supports ;binary for that attribute, the server returns
>BER encoded values.
>
>[RR] For most attributes this BER is simply an octet string wrapping.
>Certificate stuff is the exception.
>
>It's spelled out in RFC 2251, Section 4.1.5.1.
>
>[RR] This section is more a hint than a spelling-out. Note that the only
>attributes that this is expected to apply to are certificate releated (last
>sentance of the section).

No.  The last sentence only provides an example.  The example
does not constrain use of the mechanism with other attributes.

The second to last sentence states: "This option is intended to
be used with attributes whose syntax is a complex ASN.1 data type,
and the structure of values of that type is needed by clients."

Directory String is a complex ASN.1 data type.  Distinguished
Name is a complex ASN.1 data type. ....

>It would not be possible, for example, for a
>server to reconstitute the X500 definition of DirectoryString because the
>actual CHOICE tag has been lost (was never supplied).

Just as an LDAP/DAP gateway can infer the CHOICE when mapping
between LDAP and DAP, an LDAP server can infer the CHOICE.  Where
the client desires a particular CHOICE, it should use ;binary.

>Also, the section assumes there is an ASN.1 definition.

Yes. Each and every LDAP syntax is defined in terms of an ASN.1
data type definition.

>If you assume that X.520 is implied,

I do, LDAP is an access protocol to an X.500 Directory.

>you can make up ASN.1 values, in principle, but as I've indicated with
>DirectoryString, it is not always possible to go from the possible to the
>actual. But if this were to be possible, LDAP should have specified these
>ASN.1 syntaxes.

They are specified, see 4.3.2 of RFC 2252.

>I believe, though, as in the case of DistinguishedName, that
>LDAP was actually trying to break away from X.500.

No.  LDAP was trying to make things easier on clients to
access an X.500 directory.  LDAP is an access protocol to
an X.500 directory.

>One of its primary uses is in security applications, see
>RFC 2252 9.2 (but s/Binary syntax/binary transfer/ in last
>sentence for it to make sense).
>
>[RR] This is just certificate stuff again!

The example is certificate related.  However the issue as
well as the mechanism provided to address the issue are
general.


>>I would expect LDAP servers to regard the DN as a string and simply wrap
it
>>with an octet string tag. In fact, I don't remember any description of a
>>non-string encoding of DN in the LDAP documents.
>
>DNs transferred in fields of LDAPDN type in the protocol are
>RFC 2253 strings.  Assertion and attribute values of distinguishName
>syntax can be transferred using the native (octet) string
>encoding, e.g. an RFC 2253 string, or using ;binary transfer,
>e.g. BER.
>
>[RR] You seem to be saying that DNs can't be returned in their X500 form?

LDAPDN fields are restricted to the LDAP string representation.
However, assertion and attribute values of distinguishedName
syntax can be transferred using BER.

Both are X.500 forms.  That is, both are encodings of the
X.500 distinguishedNames.

>>As regards your other arguments, I have trouble getting a handle on them.
>>The only attributes that MUST be requested with ;binary are the
certificate
>>bunch. A client MUST always expect these to be returned with ;binary
>>regardless of the request.
>
>And the client MUST request them as ;binary.
>
>RFC 2256:
>   This attribute is to be stored and REQUESTED in the binary form, as
>   'userCertificate;binary'.  (emphasis added)
>
>RFC 2252:
>   ... values in this syntax MUST only be transferred using the
>   binary encoding, by requesting or returning the attributes
>   with descriptions "userCertificate;binary" or
>   "caCertificate;binary".
>
>RFC 2256:
>   clients MUST NOT expect servers to return an attribute in
>   binary format if the client requested that attribute by name
>   without the binary option.
>
>A client which requests "userCertificate" (without ;binary)
>does not conform to the specification.
>
>[RR] Once certificates are taken out of the base spec, conformance it moot!

The RFC 2251 statement remains, it is not certificate specific.

>>Requesting other attributes with ;binary just seems wrong.
>>(I reject your notion that servers will perform some
>>unspecified action to return a novel encoding of an attribute.
>
>It's specified quite clearly in RFC 2251, 4.1.5.1.
>
>[RR] That waffle is not clear. The only clear statement is that it is
>expected to apply to certificates.

Examples are just examples.  The interpretation of the section
is the same whether it's "userCertificate;binary", "member;binary"
or "

>If you look at the mailing list of the time (asid?)

Do you have a copy of the archives?  If so, please forward me a
copy of it so I can make it publicly available.

Kurt