Subject: [Ldap-dir] Comments on draft-ietf-pkix-ldap-*-schema

From: Steve Hanna <[email-masked]>
Date: Thu, 18 Nov 2004 14:31:48 -0500

I understand that you (the LDAP directorate) are
currently reviewing draft-ietf-pkix-ldap-*-schema,
the PKI schemas from Gietz and Klasen. I just sent
the attached email to the PKIX list and want to
make sure you have this input for your consideration.

Please let me know if I'm wrong in my understanding
of the situation. I'm not an LDAP expert but I do
know something about PKI, having implemented a few
certification path validation and building libraries
that used the current LDAP PKI schemas.

Thanks,

Steve

-------- Original Message --------
Subject: Re: WG Last Call: Certificate Schema
Date: Thu, 18 Nov 2004 14:26:02 -0500
From: Steve Hanna <[email-masked]>
To: Tim Polk <[email-masked]>
CC: [email-masked],  [email-masked],  [email-masked], 
[email-masked]
References: <[email-masked]>

Here are my comments on draft-ietf-pkix-ldap-*schema.

These schemas are too complex and incompatible with
existing clients. The costs exceed the benefits.

The main supposed benefits of your solution are:

1) Easier to search for certs

    Since certificate fields are stored as attributes
    of LDAP entries, clients can easily search for
    certificates by certificate field values. However,
    there are already two good ways to do this: the
    CertificateAssertion (defined in X.509 and
    draft-zeilenga-ldap-x509-00.txt) and Component
    Matching (RFC 3687). You argue that these will
    take a while to be deployed, but so would your
    solution. We don't need a third option.

2) Easier to download just matching certs

    Some users (or CAs) have many certificates.
    Your solution stores each cert as a separate
    directory entry which makes it easy to download
    just the ones you want. But there is already a
    way to do this with the existing schema: the
    Matched Values Return Filter control (RFC 3876).
    Again you argue that these will take a while to
    be deployed, but so would your solution. Also,
    it's quite rare to have many certificates. Why
    optimize for this rare case?

The main costs of your solution are:

1) Many more directory entries (>2x)

    Your solution requires a separate directory entry
    for every certificate. If each user has an average
    of one cert, this will double the number of entries
    in the directory. That's bad enough, but your solution
    has no value unless each user has many certificates.
    In that case, the number of entries will more than
    double.

2) Client changes needed

    You complain that the Matched Values Return Filter
    control will require servers to be upgraded. But
    your solution will require all clients to be upgraded
    to look for certificates and CRLs in a new place.
    Upgrading all clients is much harder than upgrading
    a few servers.

The schema described in RFC 2587 and updated by
draft-zeilenga-ldap-x509-00.txt seems much more
reasonable than yours. I understand that the
zeilenga I-D is actually a product of the ldapbis
efforts and will probably advance with them.
Therefore, I suggest that document be advanced in
lieu of yours.

I have heard that your drafts are only intended to
report on some experiments you conducted. That's why
the documents are going Informational and not Standards
Track. If that's true, the documents should say so
clearly and they should go Experimental not Informational.

In conclusion, it's my view that these documents are
not useful. In fact, they may cause harm to people
who implement them without understanding that they
are purely experimental. I recommend that they not
be published at all by the IETF. If they are published,
they should only be published with Experimental status
with an Applicability Notice describing the problems
noted above and suggesting that the standard schemas
be used instead.

Thanks,

Steve

Tim Polk wrote:

> 
> 
> This message initiates working group Last Call for the "LDAP Schema for 
> X.509 Certificates"
> specification. The editors have confirmed that all working group issues 
> have been resolved.
> 
> The URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-pkc-schema-01.txt
> 
> This specification has also been forwarded to the LDAP Directorate for a 
> parallel review.  Assuming successful Last Call and concurrence from the 
> LDAP Directorate, this document will be forwarded to the ADs for 
> consideration as an Informational track RFC.
> 
> Last Call will run for (at least) two weeks. That is, Last Call will not 
> close before November 29.
> 
> Thanks,
> 
> Tim Polk

_______________________________________________
Ldap-dir mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldap-dir

---

From: Steve Kille <[email-masked]>
Date: Fri, 26 Nov 2004 16:07:51 -0000

I am inclined to agree with Steve Hanna's view, that these should be
experimental.   

Steve

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Steve Hanna
> Sent: Thursday, November 18, 2004 7:32 PM
> To: [email-masked]
> Subject: [Ldap-dir] Comments on draft-ietf-pkix-ldap-*-schema
>