Subject: A plan for PKIX, LDAPv3, and ;binary

From: [email-masked] (by way of "Kurt D. Zeilenga" <[email-masked]>)
Date: Thu, 21 Nov 2002 20:43:23 -0500

[resent to hit both lists -Kdz]

Folks,

Three of the four Chairs (Tim Polk, Bob Morgan, Kurt Zeilenga) of the LDAPbis 
and PKIX WGs and one of the document authors (Steven Legg) met  in Atlanta to 
discuss LDAPv3  PKIX issues, and we have a way forward regarding X.509 
certificate schema and ;binary transfer option.

The PKIX WG will draft a new technical specification describing the 
Certificate, Certificate List and Certificate Pair syntaxes, the value 
preservation requirements for attributes of these syntaxes, and the ;binary 
transfer option used in requesting and transferring attributes of these 
syntaxes.  (Attributes of these syntaxes include userCerificate, cACertificate, 
certificateRevocationList, authorityRevocationList, and crossCertificatePair.)  
The LDAPbis WG will provide any support the PKIX WG requires/requests.

(1) Upon review of the PKIX-LDAP “survey” we see a critical mass of PKI clients 
and LDAP servers that achieve interoperability using LDAPv3 with the ;binary 
option.  As these clients appear to be in the majority, we believe the best 
approach is to maintain this option for the transfer of X.509 certificates and 
CRLs.  Since this is the behavior documented in RFCs 2251, 2252, and 2256 (as 
well as the overarching 3377) this will require the least changes to the LDAPv3 
specifications as well.

(2) Per previous LDAPBIS discussions, the ;binary option need not be maintained 
as a general-purpose LDAP feature.  There is no need to hold up PKIX syntax and 
schema for LDAPBIS to define the general behavior of that feature.  This option 
will be defined in the PKIX syntax and schema document.

(3) The ;binary option as originally defined did not fully meet PKIX 
requirements anyway.  The real requirements are that these attribute values (a) 
be stored on the server in the same form that it was received in; and (b) are 
returned to the requester in the same form as received.  The PKIX syntax and 
schema for LDAPv3 will impose these new value preservation requirements on LDAP 
servers; this is consistent with the current LDAPBIS “Directory Information 
Models” draft.

(4) The lack of a defined LDAP-specific encoding for Certificate, Certificate 
List and Certificate Pair syntaxes is a problem, as a small percentage of 
implementations transfer these attributes without the ;binary option.  Rather 
than be silent, we suggest that the PKIX syntax and schema document state the 
LDAP-specific encoding used in transfer without the ;binary option but 
deprecate its use.  This LDAP-specific encoding has the same transfer 
representation as when the attribute is transferred with the ;binary option.

We believe this represents a straightforward path forward that meets the PKIX 
interoperability requirements while being most compatible with current PKI 
behavior, current LDAPv3 standards, and upcoming LDAPBIS documents.

Thank you,

Tim Polk, RL "Bob" Morgan, Kurt Zeilenga, and Steven Legg

---

From: Harald Koch <[email-masked]>
Date: Fri, 22 Nov 2002 09:47:44 -0500

>  There are clients which
> expect:
>         a) return the certificate using "userCertificate;binary" or
>         b) return the certificate using "userCertificate".
> 
> (as well as clients which accept either)

The problem is complicated by the fact that there are LDAPv3 *servers*,
some that expect 'userCertificate;binary' and some that expect
'userCertificate'.

Then there are servers that support either, and will return whichever
attribute name they think is correct, regardless of the request.

Then there are implementations that perform searches on, and return,
whichever name was used to store the certificate, without treating the
;binary transfer option specially. Requesting 'userCertificate' would
not return any 'userCertificate;binary' attribute stored in the entry,
and vice versa.

(IIRC, one older server could even store *both* userCertificate and
 userCertificate;binary in a single directory entry as separate,
 multi-valued attributes :-).

So sadly, the only thing a truly interoperable client can do is request
both and accept both; performing two searches and merging the results.
Nothing else covers all current implementations, in my implementation
experience.

-- 
Harald Koch     <[email-masked]>

---

From: Christopher Oliva <[email-masked]>
Date: Fri, 22 Nov 2002 12:44:29 -0500

>         b) return the certificate using "userCertificate".

This sounds like a strong argument that supports updating servers to achieve
interoperability with both groups. That's why I would prefer a solution that
requires updated servers to support the native encoding of certificates (as
would be returned when "userCertificate" is requested).

> As a server cannot support both at the same time, there is
> clearly an interoperability divide between implementations

Why is it that a server cannot support both groups ?

If it remains the server's choice of whether or not to support group B, the
interoperability divide remains unchanged. I believe the proposal should
define the native encoding so that interoperability with group B can be
attempted. This should not involve any comments about deprecation as server
implementations may takes this as a reason not to support a request for
"userCertificate". And there can be text indicating clients SHOULD request
"userCertificate;binary".

Chris.

---

From: Christopher Oliva <[email-masked]>
Date: Fri, 22 Nov 2002 13:38:26 -0500

To address the question of clients who request userCertificate where the
server returns userCertificate;binary ... how about this suggestion: servers
should be updated to be consistent with the native encoding (return
userCertificate). Clients that want userCertificate;binary to be returned
will need to be updated because that is the one scenario that is documented
in RFC 2251 that may not work.
 
Small clarification below:

-----Original Message-----
From: Christopher Oliva [mailto:[email-masked]]
Sent: Friday, November 22, 2002 12:44 PM
To: 'Kurt D. Zeilenga'
Cc: [email-masked]; [email-masked]
Subject: RE: A plan for PKIX, LDAPv3, and ;binary

This sounds like a strong argument that supports updating servers to achieve
interoperability with both groups . That's why I would prefer a solution
that requires updated servers to support the native encoding of certificates
(as would be returned when "userCertificate" is requested). 

The two groups I refer to are clients who request userCertificate;binary and
clients who request userCertificate as I complicated this with the two
groups outlined above. Sorry for the confusion.

Chris.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 23 Nov 2002 07:10:57 -0500

At 12:44 PM 2002-11-22, Christopher Oliva wrote:
>> There are clients which expect: 

Note that I said this in a particular context.  That is,

>>         b) return the certificate using "userCertificate". 

That is, a server which does a) won't interoperate with a client
which expects b) and a server which does b) won't interoperate
with a client which expects a).

>This sounds like a strong argument that supports updating servers to achieve interoperability with both groups.

It's a damn good argument for clients which ask for "userCertificate"
to be upgraded to ask for "userCertificate;binary" as the LDAPv3
specification has told them to do 5 years ago.

We should be careful not to add new requirements as we should
not unnecessarily require changes to deployed LDAPv3-conformant
systems.

>That's why I would prefer a solution that requires updated servers to support the native encoding of certificates (as would be returned when "userCertificate" is requested).

As noted above, a server which does a) or b) will not interoperate
with the group of clients which expect the other.  We should let
server implementors choose wether they want to support a) or b)
or say "no".  That is, we shouldn't detail non-standard behaviors.

>Why is it that a server cannot support both groups ? 

Well, a server could return the attribute twice, once labelled
"userCertificate" and "userCertificate;binary".... but that
might confuse clients which expect an attribute to be returned
only once.

>If it remains the server's choice of whether or not to support group B, the interoperability divide remains unchanged.

If we force servers to support group B, then we disallow servers
from supporting group A.  If we force servers to support group
A, then we disallow servers from supporting group B.

>I believe the proposal should define the native encoding so that interoperability with group B can be attempted. This should not involve any comments about deprecation as server implementations may takes this as a reason not to support a request for "userCertificate". And there can be text indicating clients SHOULD request "userCertificate;binary".

We should require no server which is support a particular odd group
to stop supporting that odd group.  But we certainly should deprecate
both group A and B as both are odd.  That is, we should everyone in
group A and group B to the standards following group, group IETF.