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: wpolk@nist.gov [mailto:wpolk@nist.gov]
Sent: Thursday, November 21, 2002 3:03 PM
To: itef-pkix@imc.org; ietf-ldapbis@OpenLDAP.org
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,
Tim Polk, RL "Bob" Morgan, Kurt Zeilenga, and Steven Legg