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

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

David,

RE: Bruce's suggestion.

This requires using his version of the family of entries. If you do, and you
accept the maintenance issue of keeping all attribute values in sync, there
is no reason why it can't work.

However, I seem to sense some opposition to the concept and this is where we
have a real problem. If an entry holds two certificates, there is no way of
setting other attributes in the entry so that each of their values are
associated with the appropriate certificate. I think the matching rule
approach is the only solution. You may be able to have 'magic' attributes
that have order-dependent values, but this is in conflict with the X.500
standard. One may always, of course, pregenerate the values of magic and
invisible attributes that are only accessed with the application of specific
matching rules.

Ron.

-----Original Message-----
From: David Chadwick [mailto:d.w.chadwick@salford.ac.uk]
Sent: Friday, 14 July 2000 0:03
To: Sean Mullan; ietf-pkix@imc.org; ietf-ldapext@netscape.com
Cc: Boeyen@entrust.com
Subject: Re: I-D ACTION:draft-ietf-pkix-ldap-schema-00.txt


Date sent:      	Wed, 12 Jul 2000 19:31:31 +0100
From:           	Sean Mullan <sean.mullan@sun.com>
To:             	d.w.chadwick@salford.ac.uk
Copies to:      	ietf-pkix@imc.org, ietf-ldapext@netscape.com
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)

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.


>   * 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.

> 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.

>   * 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)

>   * 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.

> 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

David

> 


***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email D.W.Chadwick@salford.ac.uk
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************