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

From: [email-masked] (Mark C Smith)
Date: Thu, 21 Nov 2002 18:03:48 -0500

I think this is an excellent plan and the best choice given the 
situation. The installed base of LDAPv3 users will be very grateful 
(which is to say they won't kick and scream, because they will feel 
minimal pain).

-- 
Mark Smith
Netscape Directory Product Development
My words are my own, not my employer's.

[email-masked] wrote:
> 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: Christopher Oliva <[email-masked]>
Date: Thu, 21 Nov 2002 18:48:43 -0500

I have a question about point 4. Specifically the sentence:

" 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. "

What will be the impact of "but deprecate its use" to server
implementations?  I would prefer to remove the last 4 words of that
sentence.

I would like to see a more clear statement that servers will have to support
requests for userCertificate as well as userCertificate;binary.

Chris.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, November 21, 2002 3:03 PM
To: [email-masked]; [email-masked]
Subject: A plan for PKIX, LDAPv3, and ;binary

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,

---

From: "Tom Gindin" <[email-masked]>
Date: Thu, 21 Nov 2002 19:26:54 -0500

Why not something which favors support for both DERattribute;binary
and DERAttribute by servers but deprecates one of them (apparently the one
without ;binary) for clients?  This would include a MUST that any server
which supports both of these return the same format.
      We do want to get out of supporting two strings for the same request,
eventually.

            Tom Gindin

Christopher Oliva <[email-masked]>@mail.imc.org on 11/21/2002
06:48:43 PM

Sent by:    [email-masked]

To:    [email-masked]
cc:
Subject:    RE: A plan for PKIX, LDAPv3, and ;binary

" 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. "

I would like to see a more clear statement that servers will have to
support requests for userCertificate as well as userCertificate;binary.

Chris.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, November 21, 2002 3:03 PM
To: [email-masked]; [email-masked]
Subject: A plan for PKIX, LDAPv3, and ;binary

Folks,

(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

returned to the requester in the same form as received.  The PKIX syntax

Models" draft.

representation as when the attribute is transferred with the ;binary
option.

Thank you,