If you yourself have made this error ... it is very possible that some vendor has made the same error and might explain broken implementations.
I for one think the spec is ambiguous ... let me explain:
RFC 2251, clause 4.1.5 defines attribute descriptions as subtypes of the attribute without any options. Neither this clause nor clause 4.1.5.1 says anything special about this not holding for ";binary". The first problem is that subtypes are not defined in this RFC. As it turns out, the X.501 definition explicitly says that values can be accessed via the "supertype" as well as the subtype (I'm paraphrasing).
Now, clause 4.1.5.1 says that "clients MUST NOT expect servers to return an attribute in binary format if the client requested that attribute by name without the binary option". The implication is that servers may infact, return the binary encoding even if the binary option was not used by the client since the clause says nothing about the behaviour of the servers in this instance.
So who's wrong here? The server for generating the binary encoding? Not according to the RFC.
This is in my opinion, sufficient proof that there is ambiguity. There is sufficient grounds to say that servers should be allowed to return binary encodings if a client makes a request without ";binary".
Now look at RFC 2252.
Clause 6.5 defining the certificate syntax says this:
"... 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'."
The main point being stressed by the MUST is the transfer encoding. One could argue that the MUST only applies to the transfer using the binary encoding but not necessarily to the following clause that talks about the attribute descriptions.
Now look at the word "or" between 'requesting' and 'returning'. It is possible that the word "or" was used instead of the word "and" in order to account for the fact that clients might request userCertificates without the ;binary option. This directly conflicts with the MUST NOT of 4.1.5.1 from RFC 2251 above. This same thing could be used to justify a server returning userCertificate instead of userCertificate;binary.
Chris.
> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> Sent: Thursday, February 21, 2002 1:50 PM
> To: Christopher Oliva
> Cc: 'mcs@netscape.com'; Ramsay Ron; Christopher Oliva; LDAP BIS
> Subject: RE: ;binary and userCertificate (Was: Private email ...)
>
>
> At 10:20 AM 2002-02-21, Kurt D. Zeilenga wrote:
> >Additionally, client
> >developer's would have to be warned that some
> >servers might use ;binary transfer even though
> >the native string was requested. As this is a
> >behavior which the existing specification allowed
> >(due to an ambiguity in the specification which,
> >I hope, will be removed).
>
> I mispoke. The ambiguity I refer to above doesn't
> does apply in the certificate case as the existing
> specification mandates use of ;binary for certificate
> syntaxes. Hence, this warning would not be needed.
>
> My apologies for any confusion caused by my error.
>
> Kurt
>
>