RE: NEW Data type for certificate selection ?

[Sarbari Gupta <sgupta@xxxxxxxxxxxx>]

David,

	>>Sarbari also asked about matching against the prefix of the
Issuer name.
	>> The short answer appears to be that that is not possible
using the
	>>current definition of certificateMatch Matching Rule, since it
always
	>>uses an equality match of the Issuer name.  A new Matching
Rule (or the
	>>present one modified) would have to be defined to support
matching a
	>>prefix.
I got the same impression (that an equality match is implied) when I
looked at the X.500 matching rules. 

	>>(I don't believe specifying 'prefix of Name' is adequate,
since it may
	>>not be acceptable to match an Issuer at some greater depth
than
	>>intended.  Both SubtreeSpecification and NameConstraintsSyntax
permit
	>>limits to be placed on the depth of the matching, and also
permit the
	>>explicit exclusion of Names which would otherwise match.)
In the context of discussing a mechanism for "selecting" end entity
certificates for use, I do not understand why the 'prefix of name'
criterion is inadequate. On the other hand, if we were discussing
certificate path validation, I would agree with you completely; for CA
certificates in the path to be validated, the NameConstraints extension
with the permitted and excluded subtrees would be absolutely relevant. 

Apparently, what is needed to support "selection of a certificate for
use" by secure applications is the ability to draw upon the richness
that is already present in the X.509 v3 certificate syntax. 

- Sarbari
=============================
Sarbari Gupta
CygnaCom Solutions
(703)848-0883 ext 217
sgupta@cygnacom.com
=============================

> -----Original Message-----
> From:	David Boyce [SMTP:D.Boyce@isode.com]
> Sent:	Tuesday, October 13, 1998 8:08 AM
> To:	Stefan Santesson
> Cc:	Sarbari Gupta; 'Dwight Arthur'; ietf-pkix@imc.org
> Subject:	Re: NEW Data type for certificate selection ? 
> 
> Stefan Santesson writes:
> >To your question. Does the X.500 matching rule cover selection by 
> issuer
> >name according to your scheme?
> >My conclusion is that it does. You can specify any set of Issuer name
> >attributes you want and you get a match as long as your presented
> >attributes matches those of the target certificate.
> >(If any X.500 expert have another opinion, I would like to here it.)
> 
> That appears to be broadly correct.  Bear in mind that in order to
> match
> against a set of Issuer names, you will have to be able to specify
> multiple matching rules (one for each Issuer you wish to match
> against);
> a DAP/LDAP search filter allows you to do this, but in the specific
> context of this discussion (selection mechanisms for certificates)
> this
> may not apply.
> 
> Sarbari also asked about matching against the prefix of the Issuer
> name.
>  The short answer appears to be that that is not possible using the
> current definition of certificateMatch Matching Rule, since it always
> uses an equality match of the Issuer name.  A new Matching Rule (or
> the
> present one modified) would have to be defined to support matching a
> prefix.
> 
> If such a new prefix matching rule were defined, one way forward is to
> adapt either an X.501 SubtreeSpecification or X.509
> NameConstraintsSyntax to define the limits of matching.  The latter,
> being X.509 based anyway, is probably the better choice since it also
> caters for similar matching against subjectAltName and issuerAltName.
> 
> (I don't believe specifying 'prefix of Name' is adequate, since it may
> not be acceptable to match an Issuer at some greater depth than
> intended.  Both SubtreeSpecification and NameConstraintsSyntax permit
> limits to be placed on the depth of the matching, and also permit the
> explicit exclusion of Names which would otherwise match.)
> 
> >And as you see (Dwight), the policy OID is also covered by this 
> structure.
> 
> Correct;  although I have some questions about its definition which I 
> raise separately, they don't appear to affect this.
> 
> David.
> 
> -- 
> David Boyce
> 
> Tel:	+44 181 332 9091		Richmond, Surrey, ENGLAND
> Email:	d.boyce@isode.com	Isode's WWW:
> http://www.isode.com/
>