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

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

One other comment - I have mentioned this previously when
commenting on RFC 2587, but as of yet no changes have
been made. 

Building certification paths in a 'reverse'
direction (from trust anchor to EE) is a valid way to build
certification paths. However, RFC 2587 (PKIX LDAPv2 schema) specifies
that the storage of cross certificates in the reverse component of
the crossCertificatePair is optional. It is not possible to efficiently
build a certification path in a 'reverse' direction unless the 
certificates are populated in the reverse component of the crossCertificatePair
attribute. Specifying that this feature is optional makes it
difficult to build paths in a reverse direction in a trust model
where lots of cross certificates and multiple directories
are involved and you don't know if the CAs support
the optional storage.

I would like to suggest that RFC 2587 be amended/updated
to make storage of cross certificates in the reverse component of the
crossCertificatePair attribute mandatory.

Thanks,
Sean


Sean Mullan wrote:
> 
> 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