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

From: "Ramsay, Ron" <[email-masked]>
Date: Thu, 21 Feb 2002 13:55:27 +1100

Kurt,

Replies inline. See [RR]

Ron

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
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). 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). Also, the section
assumes there is an ASN.1 definition. If you assume that X.520 is implied,
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. I believe, though, as in the case of DistinguishedName, that
LDAP was actually trying to break away from X.500.

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!

>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?

>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!

>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. No other syntaxes have been given an
ASN.1 form. If you look at the mailing list of the time (asid?) you will see
that the interpretation of this paragraph was to wrap the string
representation in an octet string. Once again, except for certificate
related stuff, the BER was taken to be 04 xx ......

>I do agree with Chris that ;binary was a BAD idea.

IMO, ;binary, as "intended" by 4.1.5.1, is a useful feature
of LDAPv3. 

[RR] I think this thread has revealed that others regard it as a BAD idea.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 20 Feb 2002 22:32:10 -0800

At 06:55 PM 2002-02-20, Ramsay, Ron wrote:
>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
>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.

>ASN.1 syntaxes.

They are specified, see 4.3.2 of RFC 2252.

>I believe, though, as in the case of DistinguishedName, that

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.

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

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

>[RR] Once certificates are taken out of the base spec, conformance it moot!

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

>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