I think it is possible to build and deploy an ldapv3 compliant system where the clients request certificates without ";binary" and actually receive valid BER encoded certificates from the server. Let me explain:
First, look again at 6.5 of 2252. Because of the particular wording that is used, it is possible to interpret the clause as follows: as long as the encoding used is the binary encoding, either the request or the response can use the ";binary" attribute option but not necessarily both. This makes perfect sense. If the client requests "userCertificate" then the server returns "userCertificate;binary" and the condition is satisfied (the client knows what they are getting).
Now look at 4.1.5.1 of 2251. The statement is 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."
Note that nothing prohibits the client from actually performing the search without ;binary - it only says "don't expect this to work". Similarly, nothing prohibits the server from responding to a request where the search did not use ";binary".
Now, to deal with the "MUST NOT expect" clause, there are two possibilities - first, because of the interpretation of 6.5 shown above, the client actually can expect this request to work, for the Certificate syntax, since the 6.5 clause allows it (the expectation is provided by the 6.5 clause). The generic "MUST NOT expect" statement then applies to other syntaxes but not to the Certificate (and the other X.509 syntaxes).
The second possibility is that the "MUST NOT expect" clause directed to the clients can be easily dealt with. All that is needed for an ldapv3 compliant client is to show that there is reasonable error recovery procedures that have been implemented. Since the RFC does not indicate what those error processing procedures can be, almost anything can satisfy this statement. The MUST NOT expect statement does not actually preclude this query from actually working.
I submit to you that this type of system can exist and that the revisions of LDAPbis and PKIX must account for the given ambiguity. I also suggest the perfect way to do this is to accept the suggestions for the new PKIX I-D.
More comments below.
> At 06:50 PM 2002-02-21, Christopher Oliva wrote:
> >There is sufficient grounds to say that servers should be
> allowed to return binary encodings if a client makes a
> request without ";binary".
>
> The problem with this is that if a server is allowed to
> return ;binary when the client makes a request without
> ;binary then the servers might actually do that. That
> would be bad as client wouldn't get what they asked for.
>
As I have shown above, the client would know what they are getting since the server has replied with ";binary".
> The solution is simple, a client gets what they ask for.
> If they ask for "foo", they get "foo". If they ask for
> "foo;binary", they get "foo;binary". While RFC 2251
> did say "foo;binary" is to be treated as a subtype as
> "foo", it also said clients MUST NOT expect
> "foo;binary" when "foo" was requested.
>
I have explained above why the "MUST NOT expect" clause does not apply for Certificates.
> The approach specified in -06 lets the MUST NOT trump
> the "is to be treated as" statement. This leads to a
> specification would addresses the ambiguity while not
> break existing LDAPv3 compliant implementations.
>
> Kurt
>
If this -06 breaks the scenario I have described above, it should be changed in order to satisy existing ldapv3 compliant implementations.
Chris.