Subject: RE: ;binary

From: Christopher Oliva <[email-masked]>
Date: Fri, 22 Feb 2002 10:57:45 -0500

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.

---

From: "Steven Legg" <[email-masked]>
Date: Mon, 25 Feb 2002 10:46:43 +1100

Chris,

Christopher Oliva wrote:
> As I have shown above, the client would know what they are getting
> since the server has replied with ";binary".

Unfortunately, client implementors often don't take into account all
the potential responses they can get. They usually do enough to make
their client work with their preferred LDAP server and leave it at
that. So even if we explicitly specify that servers are allowed to return
";binary" without it being requested, there will still be people
implementing clients that don't expect it.

Apropos of the current discussion, I've found a good reason for NOT
specifying that the native LDAP encoding for some syntax is the
same as its ";binary" encoding. I've just submitted an I-D for
an LDAP profile of X.500's Basic Access Control (it should appear in
a few days) which uses the ACI Item syntax from RFC 2252. I've defined
a human-readable native LDAP encoding for this syntax. However, I
would have had a problem if the native LDAP encoding for this syntax
had been previously defined to be the same as its ";binary" encoding.

By not defining the native LDAP encoding to be the same as the ";binary"
encoding for syntaxes that don't have a defined human-readable encoding,
we leave open the possibility that we might define one in the future.

Regards,
Steven