[Date Prev][Date Next]
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
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.
;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.
It's spelled out in RFC 2251, Section 220.127.116.11.
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).
>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,
>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.
This attribute is to be stored and REQUESTED in the binary form, as
'userCertificate;binary'. (emphasis added)
... values in this syntax MUST only be transferred using the
binary encoding, by requesting or returning the attributes
with descriptions "userCertificate;binary" or
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.
>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, 18.104.22.168.
>I do agree with Chris that ;binary was a BAD idea.
IMO, ;binary, as "intended" by 22.214.171.124, is a useful feature