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

[Sean Mullan <[e-mail]>]

David,

David Chadwick wrote:
> 
> Date sent:              Wed, 12 Jul 2000 19:31:31 +0100
> From:                   Sean Mullan <[e-mail]>
> To:                     [e-mail]
> Copies to:              [e-mail], [e-mail]
> Subject:                Re: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt
> 
> > Hi David,
> >
> > Some comments on the draft below.
> 
> Sean, replies intersperced below
> 
> > 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.
> >
> 
> I agree that alternative name types should be allowed. But maybe it
> is not necessary to have multiple names, since you can do several
> Searches providing one name for each search (remember that the
> name presented should be allowed to have a cert path created to it)

Yes, but I think this is a bit more complex. I think ideally you should
be able to define in one matching rule all the selection criteria for
a certificate. So if a certificate contains more than one alt name, the matching rule
should allow you to match on more than one alt name. For ex, in one search I
would like to get all the certs issued by some DN that allow a path to be 
built to the subject altnames of "cn=mullan,o=sun,c=us" and "[e-mail]".
If I break this into 2 searches, I am likely to get duplicate certs or
certs that allows paths to be built to one of the names but not both.
Specifying 2 matching rules in one search would have similar problems.

> How do we want to handle this:
> i) issue a defect on X.509 (Sharon can you comment on this)
> ii) let the LDAP matching rule be a superset of the X.509 one?
> 
> I would favour the former route myself.

I agree - if it doesn't take too long.

> >   * you should be able to match on more than the subject alt name
> >   type.
> 
> Agreed. This is a lack of clarity in the ID. It is intended that the
> whole name can be presented along with the type. The text is
> ambiguous in this respect and I will fix it. It will also be clearer when
> version 1 is published that contains BNF for each of the fields.
> Steven Legg has been doing this for me.

The X.509 certificateAssertion only allows you to match on the alt name type -
that's the problem I was referring to - that should be fixed.

> > 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.
> >
> 
> Concerning multiple names, I think this can be solved by performing
> multiple searches with a single name in each search.

See comment above why I think this is more complex.

> >   * you should be able to match on the subject public key as well as
> >   the subject public
> >     key algorithm OID.
> >
> 
> you can match on the subject key identifier (3rd component)

but not the subject public key itself.

> >   * 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.
> >
> 
> Interestingly  this has been defined for attribute certificates and not
> pk certs. I actually think that the way matching for ACs has been
> handled is far superior than for PKcerts. ie. a separate matching
> rule for each extension, rather than one long complex rule for pk
> certs. However, there would be nothing to stop an implementation
> dynamically attaching the basicAttConstraintsMatch to public key certs. In
> fact this matching rule could be renamed the basicConstraintsMatch
> anyway as the syntax is the same for both ACs and PKCs. This is
> my preferred approach.

Sounds good but I think there might be an issue.

What happens if you want to define a matching rule to only retrieve certs
that contain a specific basic constraints value AND a certain issuer name? In
this case, you would define 2 matching rules and specify both of them in
the valuesReturnFilter control. But then you would get all certs with the
requested issuer name and any basic constraints value and all certs with
any issuer name and the requested basic constraints value. That's not
what you wanted. I think we may want to enhance the valuesReturnFilter
control (through a flag, perhaps) to allow the user to apply all of the 
elements of the filter to each attribute value. Let's discuss this more 
offline, if you like.
 
> > 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.
> >
> 
> OK, this can be done. It is just time consuming and I wanted to
> know if there was a demand first.
> 
> > Other comments:
> >
> >   * What RFC format are you using for the encoding of DNs - 1779? This
> >   should be referenced.
> 
> It should be 2253 for LDAPv3.
> 
> >
> > 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.
> 
> Agreed, Sharon, can you make a  note of this defect
> 
> David
> p.s. what do you think about Bruce's assertion that none of this is
> needed and instead we should have a bunch of simple attributes in
> the LDAP entry

I'll have to go back and read Bruce's draft but I agree with your responses
to Bruce in an earlier message. Comments later ...

Thanks,
Sean