[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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/