Subject: Re: LDAP PKI Schema (was Re: No-op LDAP ;binary option)

From: Russ Housley <[email-masked]>
Date: Fri, 03 Jan 2003 17:18:54 -0500

Kurt:

I must voice my disagreement with this approach, again.

This approach adds complexity to the PKI client.  In the long run, a PKI 
client must look in two places to locate a certificate.  The client cannot 
know if the PKI "child entry" approach or the component matching approach 
was used by the administrator posting the information.  As a result, the 
PKI client must first look in the userCertificate attribute of the subject 
entry.  If the PKI client does not find the expected certificate, then it 
must search for child entries.

I want to pick one or the other, not live with checking both for the 
foreseeable future.  If we pick the PKI "child entry" approach, then this 
should be the only way that certificates are stored.  This means a 
standards track document, not an informational or experimental one.  If we 
pick the component matching approach, then we can write the standards track 
document now, but we will have to wait for development and deployment of 
updated software.

WE MUST PICK ONE APPROACH, NOT TWO!

Russ

At 11:37 PM 12/30/2002 -0800, Kurt D. Zeilenga wrote:
>My recommendation is that the PKI "child entry" approach be
>pursued individually as an Experimental (or possibly Informational)
>solution to the PKI component matching problem with a note that
>a more general solution, component matching, is being standardized.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 03 Jan 2003 17:59:51 -0800

Here are my recommendations to the PKIX WG:

   The PKIX WG should not take on engineering of a PKI-specific
   solution to the certificate matching / returning problems
   which draft-klasen-ldap-x509certificate-schema.  General
   solutions suitable for standardization exist to resolve these
   problems.

   The PKIX WG should, as part of its PKI LDAPv3 applicability
   statement work, detail requirements of PKI implementations
   to support:
        a) existing LDAP PKI schema (as revised by PKIX WG)
        b) component matching rule extension
        c) matched values control extension

   The PKIX WG should revise the LDAPv3 PKI Schema in a manner
   which preserves existing interoperability (e.g., add
   missing matching rules to userCertificate and friends,
   fix up reference to X.509, etc.).

>I must voice my disagreement with this approach, again.

Let me rephrase the part I think you object to:

  I have no objection to the proponents of
  draft-klasen-ldap-x509certificate-schema continuing
  to pursuing their work on an individual basis.  In
  its current form, I would oppose publication as a
  non-Experimental RFC.  As an Experimental RFC, I would
  ask that an IESG Note be added to the document clarifying
  that the document details an alternative to existing
  and future IETF standards which implementors should favor.

Kurt

---

From: Russ Housley <[email-masked]>
Date: Sat, 04 Jan 2003 14:42:25 -0500

Kurt:

I can support this position, as it sicks one solution for use in the PKIX 
schema.  It picks the certificate matching approach, which is fine with me.

It does mean that deployment will require servers and clients to be 
upgraded.  This is also fine with me.  The alternative requires client to 
be upgraded, but not servers.

Russ