Subject: RE: LDAP Certificate transfer syntax

From: Sharon Boeyen <[email-masked]>
Date: Wed, 3 Apr 2002 15:32:11 -0500

From the PKIX perspective, I firmly believe that backward compatibility 
with the PKIX LDAP specs is a very important issue. I believe that what 
David is proposing satisfies that important criteria and support the 
proposal.

Sharon 

-----Original Message-----
From: Mark Wahl [mailto:[email-masked]]
Sent: Wednesday, April 03, 2002 2:51 PM
To: David Chadwick
Cc: Kurt D. Zeilenga; Mark C Smith; LDAP BIS; PKIX; [email-masked]
Subject: Re: LDAP Certificate transfer syntax

David Chadwick wrote:
> 
> 
> Now to the backwards compatibility issues. In the table below the only
> problem will come with a new LDAPv3 client that does not use ;binary
> with an existing v3 server that demands it. But we already have an
> inconsistency in these current LDAPv3 servers in that they accept LDAPv2
> queries without ;binary but not LDAPv3 queries without ;binary. 

I do not think LDAPv2-LDAPv3 behavior is sufficient justification to cause 
incompatibility between two LDAPv3 implementations.

Maybe an "LDAPv4" should have a different way for clients to send  
certificate, but LDAPv2 compatibility should not be a concern that causes
this significant a change inside of the LDAPv3 specs.  That is out of scope 
for LDAPBIS.

Mark Wahl
Sun Microsystems Inc.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 4 Apr 2002 20:19:03 +1200 (NZST)

Phil Griffin <[email-masked]> writes:

>It is only when someone tries to reconstruct the certificate from its values
>using the strict DER subset of BER that a mismatch with the signature due to
>BER/DER differences in the encoding can arise.

This would be a problem if anyone actually did this.  Anyone mad enough to even
try it quickly finds that 90% of signatures fail to verify after the re-
coding, and falls back to doing what everyone else does, which is treat the
signed object as a blob which you don't touch (the same with DNs in certs and
many other things).

Peter (who actually tried re-coding DNs into the correct form for awhile, but
       quickly gave up, and who never even tried with certs).

---

From: Christopher Oliva <[email-masked]>
Date: Fri, 5 Apr 2002 18:27:59 -0500

I don't believe there is agreement on your supposition that the 3 cases you
have outlined are non conformant.

Here are some observations on the three cases:

a) and b)
RFC 2252 clause 6.5 only mandates a binary encoding. As previously pointed
out by others, there is no absolute imperative that requires the use of the
";binary" option. The part referring to the userCertificiate;binary and
caCertificate;binary are merely examples of how one could generate the
binary encoding. If one were to include the use of the attribute
descriptions as part of the absolute imperative, this would make it
impossible to construct legal add and modify messages since this clause only
allows the requesting and returning of attributes.

I'm sure you are referring to the "MUST NOT expect" clause of RFC 2251
clause 4.1.5.1. Nowhere does the RFC explain how to apply this clause to an
implementation of the protocol specification (the precise impact of "MUST
NOT expect" in an implementation is undefined). The query is legal and
nothing prohibits the server from replying. If the intent had been to
disallow this query, the specification would have said something like " ...
if the client performs a query for an attribute by name without the ;binary
option, the server MUST NOT return the value in the binary encoding."

c)
Nowhere in the ldapv3 RFCs is there a description of the behavior for this
case. There is no justification to label this as non conformant.

Chris.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Friday, April 05, 2002 3:35 PM
To: David Chadwick
Cc: Mark Wahl; [email-masked]; 'LDAP BIS'; 'PKIX'
Subject: Re: LDAP Certificate transfer syntax

I think adding a LDAP-specific "native" encoding to certificate
is a bad idea and will actually cause more problems than it
solves.

AFAIK, there are no interoperability problem between clients
and servers which adhere to the technical specification.  Things
are basically okay.

This I-D attempts to resolve interoperability problems between
non-conforming implementations and conforming implementations
by altering the specification to require conforming implementations
to accept and support the syntax and semantics of non-conforming
implementations.  However, there are a number of different
ways implementations have not conformed to the specification.

I have seen, in the wild, clients which:
	a) request "userCertificate" and expect the return of
	"userCertificate" using the (updated) LDAPv2 native
	string encoding.
	b) request "userCertificate" and expect the return of
	"userCertificate;binary" using binary transfer.
	c) request "*" and expect the return of
	"userCertificate;binary" using binary transfer.

This I-D caters to case a) in a manner which disallows servers
from supporting case b) and c).   I believe cases b) and c)
are actually for more common than case a).  I know of
implemenations which are liberal in accepting b) or c).  While
there may be implementations which are liberal in accepting
a), it should be noted that a) requires the server not to
be strict in what it sends.

I also note that b) and c) are generally the result of
the specification not be as clear as it should have been.
Where a) is the result of someone apply LDAPv2 syntax and
semantics to LDAPv3.

However, my objection to adding this I-D is that it that
client and server implementations of it won't interoperate
with existing server and client implementations which
conform to the existing specification.

I suggest we only make the minimal changes necessary to
resolve the issues which caused this schema to be removed
from the LDAP "core" technical specification.  It was
removed become of normative reference issues (e.g.,
2nd v 3rd v ... edition of X.500) and to align the
schema with that provided by X.509 (e.g., matching rules).

I note that it was NOT removed because of lack of multiple
independently developed implementations.  We need to
be careful to not to require changes to implementations
which have already demonstrated interoperability.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 05 Apr 2002 18:00:36 -0800

At 03:27 PM 2002-04-05, Christopher Oliva wrote:
>I don't believe there is agreement on your supposition that the 3 cases you have outlined are non conformant. 

Well, I rather not rehash the whole discussion, but I believe
each actually is.

>RFC 2252 clause 6.5 only mandates a binary encoding.
>As previously pointed out by others, there is no absolute imperative that requires the use of the ";binary" option.

How else would you indicate that the "binary" encoding was
requested/used instead of the "string" encoding?

>The part referring to the userCertificiate;binary and caCertificate;binary are merely examples of how one could generate the binary encoding.
>If one were to include the use of the attribute descriptions as part of the absolute imperative, this would make it impossible to construct legal add and modify messages since this clause only allows the requesting and returning of attributes.

So, trimming the imperative down to its essence:
   Values in this syntax MUST only be transferred using the
   binary encoding.

RFC 2251 says:
   If the "binary" option is present in an AttributeDescription, it
   overrides any string-based encoding representation defined for that
   attribute in [5]. Instead the attribute is to be transferred as a
   binary value encoded using the Basic Encoding Rules [11]. 

That is, if ;binary is not present, the string-based ("native")
encoding is used.

>clause 4.1.5.1.

No, I'm referring to the technical specification as a whole.
In particular the first paragraph of RFC 2251, 4.1.5.1 and
RFC 2252, 4.3.

>c) 
>Nowhere in the ldapv3 RFCs is there a description of the behavior for this case. There is no justification to label this as non conformant.

You are right in that the RFC does not explicit state this.

But it should be obvious that "CN;binary" should not be
returned unless "CN;binary" was requested.  Same goes
for userCertificate.

---

From: Christopher Oliva <[email-masked]>
Date: Mon, 8 Apr 2002 21:09:22 -0400

> >As previously pointed out by others, there is no absolute 
> imperative that requires the use of the ";binary" option.
> 

RFC 2252, 6.5 says that ".. values in this syntax MUST only be transferred
using the binary encoding ..". Also, no other encoding is provided therefore
only the binary encoding can be used. Although 4.3.1 lists two reasons to
use the binary encoding, it does not say that other valid reasons or
syntaxes cannot require the use of the binary encoding.

Since the use of ";binary" is not mandatory for the Certificate syntax, and
there is no other possible encoding, then the default encoding that is used
(that must be used) is the binary encoding. If the ";binary" option is used
to explicitly specify the binary encoding, this results in the same
encodings and this would also satisfy the RFC.

> >c) 
> >Nowhere in the ldapv3 RFCs is there a description of the 
> behavior for this case. There is no justification to label 
> this as non conformant.
> 

Attributes must be returned according to their syntax encoding requirements.
The Certificate syntax requires the encoding to be the binary encoding; in
this case, the use of ";binary" is a red herring.

Chris.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 09 Apr 2002 09:28:23 -0500

At 08:09 PM 2002-04-08, Christopher Oliva wrote:
>RFC 2252, 6.5 says that ".. values in this syntax MUST only be transferred using the binary encoding ..".

Yes.  And RFC 2251 makes it quite clear that ;binary is used
to indicate that the binary encoding was used instead of the
native string encoding.  If ;binary is not present, binary
transfer of the binary encoding is not used.

>Also, no other encoding is provided therefore only the binary encoding can be used.

Yes, so ;binary must be used.

>Although 4.3.1 lists two reasons to use the binary encoding, it does not say that other valid reasons or syntaxes cannot require the use of the binary encoding.

But RFC 2251 states when binary encoding is to be used and when
native encodings are to be used.

>Since the use of ";binary" is not mandatory for the Certificate syntax,

I disagree.

>and there is no other possible encoding, then the default encoding that is used (that must be used) is the binary encoding.

There is no such thing as the "default" encoding.  That term is
no where used in the specification.  There is the native string
encoding and there is the binary encoding.  Which one is used
is indicated by the absence or presence of transfer options.
If this wasn't the case, then clients would have no clue as to
what encoding was actually used.

>If the ";binary" option is used to explicitly specify the binary encoding, this results in the same encodings and this would also satisfy the RFC.

;binary must be present when the binary encoding is transferred.
;binary must not be present when the native encoding is transferred.

>Attributes must be returned according to their syntax encoding requirements. 

Values of a syntax can encoded multiple ways for transfer.  The
encoding used is always indicated by the presence or absence of
transfer options such as ;binary.

---

From: Christopher Oliva <[email-masked]>
Date: Tue, 9 Apr 2002 11:05:58 -0400

> >RFC 2252, 6.5 says that ".. values in this syntax MUST only 
> be transferred using the binary encoding ..".
> 

There is no statement that says that if the ";binary" option is absent, that
the syntax encoding cannot be the binary encoding. All the RFC says is that
";binary" overrides a string encoding. But certificates do not have a string
encoding. Since there is no string encoding to override, the ";binary"
option is not necessary.

> >Although 4.3.1 lists two reasons to use the binary encoding, 
> it does not say that other valid reasons or syntaxes cannot 
> require the use of the binary encoding.
> 

All it says is that ";binary" can override a string encoding. It doesn't say
anything about "native" encodings or what happens when no string encoding is
defined. It also does not say what happens when a syntax definition requires
a specific encoding (such as the Certificate syntax mandating the binary
encoding).

The only guide is that the Certificate syntax requires the binary encoding.
Therefore even if ";binary" is not used, the binary encoding must be
generated.

> >Since the use of ";binary" is not mandatory for the 

Others have stated their belief that ";binary" is not mandatory for
certificates. There is no text that supports an absolute imperative that
";binary" MUST be used.

> 
> >and there is no other possible encoding, then the default 
> encoding that is used (that must be used) is the binary encoding.
> 

The term "string encoding" is not defined either. So it is not clear if the
RFC refers to a "native string" encoding or an encoding based on text
(printable) strings.

I note that for Directory String, the RFC does not explicitly identify the
"string encoding" either. But we understand that the encoding mandated for
Directory String is UTF8. The same logic can be applied to certificates.

> 
> >If the ";binary" option is used to explicitly specify the 
> binary encoding, this results in the same encodings and this 
> would also satisfy the RFC.
> 

Where is that stated in the RFC ? There are no such statements.

> transfer options such as ;binary.

The ";binary" only specifies that a "string encoding" was overridden. But if
there is not string encoding to override, then the ";binary" is not required
(there is no text that says ;binary is required when there is no string
encoding to override).

Chris.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 09 Apr 2002 10:18:42 -0500

>Where is that stated in the RFC ? There are no such statements. 

It is implied by the language of RFC 2251.  When a protocol
provides multiple possible transfer encodings for a particular
value, the protocol needs to provide a clear indication of
which transfer encoding is being used.  In LDAPv3, absence
and presence of transfer options is used to indicate which
transfer encoding is used. 

Kurt

---

From: Fantou Patrick <[email-masked]>
Date: Wed, 10 Apr 2002 09:27:52 +0200

Kurt, Peter and Ron, thanks for your comments.

Let me make more precise what i mean whith
*no choice* for *some attributes*

As Peter said, there are additional dependancies directly connected
with the attribute type and the fact that some attributes do not have any string encoding possibilities.

For some attributes like certificates, the only possibility as transfer encoding is the binary encoding.
It is what i mean with "there is no choice".
And in this case, as Ron says, ;binary is redundant.

Other comments in Kurt´s text.
Patrick

> -----Ursprüngliche Nachricht-----
> Von: Kurt D. Zeilenga [mailto:[email-masked]]
> Gesendet: Dienstag, 9. April 2002 18:17
> An: Fantou Patrick
> Cc: Christopher Oliva; David Chadwick; Mark Wahl;
> [email-masked]; 'LDAP BIS'; 'PKIX'
> Betreff: Re: AW: LDAP Certificate transfer syntax
> 
> 
> At 10:44 AM 2002-04-09, Fantou Patrick wrote:
> >I am not sure this discussion really brings us further.
> 
> I think this discussion is bringing us further along.  It has,
> at least, boiled down this particular debate to one issue:
>    whether or not ;binary is required when the binary
>    encoding of a value is transferred in the protocol.
> 

For certificates in any case the binary encoding has to be transferred in the protocol.
So the presence or absence of ;binary cannot change anything here.

> >There is no choice with some attributes like certificates.
> 
> I would have to agree that this is no choice.  But I think
> we disagree on what that choice is.
> 
The choice is string encoding, when it exists, or binary encoding.

> One must transfer certificates in their binary encoding as
> indicates by ;binary.   Note only is this the intent of RFC
> 2251, but we have demonstrated interoperability between
> multiple independently developed implementations of this.
> 

One must always transfer certificates in their binary encoding.
And  i am not sure that interoperability was demonstrated because 
;binary was implemented correctly, or because the presence or the
absence of ;binary was ignored by the servers for the attribute types which do not have
any string encoding.

P.F.