Re: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt

[Sean Mullan <sean.mullan@Sun.COM>]

Hi David,

Some comments on the draft below.

Internet-Drafts@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.
> 
>         Title           : Internet X.509 Public Key Infrastructure Additional
>                           LDAP Schema for PKIs and PMIs
>         Author(s)       : D. Chadwick
>         Filename        : draft-ietf-pkix-ldap-schema-00.txt
>         Pages           : 11
>         Date            : 11-Jul-00

Section 3.2 Certificate Match

I think the X.509 certificate matching rules are missing some essential and
important fields in the certificateAssertion structure for filtering on
certificates. We may want to consider defining a superset. I submitted these
comments to the X.509 editors but apparently it was too late to integrate them
into the 2000 update.

  * you should be able to match on more than one pathToName and on non-X500
    name types. This is inconsistent with name constraints which allow you 
    to constrain to more than one name and different name types. 

  * you should be able to match on more than the subject alt name type. You
    should also be able to match on the subject alt name itself, and specify more than
    one subject alt name as certificates can contain more than one.

  * you should be able to match on the subject public key as well as the subject public
    key algorithm OID.

  * you should be able to match on the basic constraints extension, especially the
    maxPathLen value. This is useful for finding potential certificates when
    building certification paths from the target to the most-trusted CA. For ex,
    if a partial path has been built, any candidate certificate must have a 
    maxPathLen value greater than or equal to the number of certificates in the 
    partial path.

I think it is very important to include the Certificate pair matching rules, as
these are very useful when building certification paths and trying to discover 
which of many cross certificates satisfy various validation constraints, and eliminating
those that do not.

Other comments:

  * What RFC format are you using for the encoding of DNs - 1779? This should be referenced.

Section 4.2 Certificate List Match

There is an error in the CertificateListAssertion definition in X.509 2000. The
authorityKeyIdentifier component should be marked OPTIONAL. This probably doesn't
affect your definition, but I just wanted to make you aware of it.

--Sean