Subject: RE: NEW Data type for certificate selection ?

From: Sarbari Gupta <[email-masked]>
Date: Tue, 13 Oct 1998 09:06:58 -0400

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
[email-masked]
=============================

> -----Original Message-----
> From:	David Boyce [SMTP:[email-masked]]
> Sent:	Tuesday, October 13, 1998 8:08 AM
> To:	Stefan Santesson
> Cc:	Sarbari Gupta; 'Dwight Arthur'; [email-masked]
> 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:	[email-masked]	Isode's WWW:
> http://www.isode.com/
>

---

From: David Boyce <[email-masked]>
Date: Tue, 13 Oct 1998 15:48:24 +0100

Sarbari Gupta writes (quoting David Boyce):
>criterion is inadequate.

Let me see if I can clarify what I mean.  As I understand it, a
matching rule which supported 'prefix of Issuer' (without further
qualification) would be adequate for the specific purpose you
described ONLY if ANY Issuer whose name contained the prefix specified
would satisfy the intended purpose of the selection.  I think there
might be other scenarios for which this would not be sufficient.

For example, consider an environment in which an organization has a
mixture of 'high-trust' CAs at one level, subordinate to the
organization, and other 'Low-trust' CAs subordinate to them.  All
these CAs would satisfy a selection criterion of 'prefix of Issuer'
with a value corresponding to the organization's name; clearly if the
intention was to select only 'high-trust' CAs, "prefix of Issuer" is
inadequate; some other discriminator would have to be used,
e.g. policyIds.

A Certificate Matching rule which used NameConstraintsSyntax against
the Issuer name would permit successful discrimination in this case on
the basis of Issuer name alone, as specifying a permittedSubtrees.base
of the organisation name, with a permittedSubtrees.minimum of 1 and
permittedSubtrees.maximum of 1, the 'low-trust' CAs would not be
considered.

In general, once a shortcoming in the present mechanism has been
identified, it's worth trying to think about what other constraints a
certificate selector might wish to specify with regard to the Issuer
name.  (Of course, this whole discussion also has application to
Subject name and their respective altName extenstions.)

You have indicated a need for 'prefix of Issuer'; by suggesting
e.g. NameConstraintsSyntax, I'm trying to address that need, and at
the same time think about what other aspects of the same problem might
need to be addressed.  "prefix of Issuer" matching may well be
adequate for your own environment; but it may not be for other
environments.

> On the other hand, if we were discussing

We're not discussing certificate path validation (although clearly
certificate selection has a bearing on subsequent certificate path
validation).

In the above discussion, I'm suggesting extending/adapting the current
NameConstraintsSyntax definition so that it becomes a basis for a
matching rule for Issuer name.

>that is already present in the X.509 v3 certificate syntax. 

I am beginning to realise there is a more general problem here: how to
select a Certificate Path (end user certificate plus zero or more CA
certs) which will permit authentication.  So far we have just been
discussing the selection of an end-user certificate while assuming
that the Cert path follows automatically ... it might make sense to
use X.509 certificatePairMatch for this.

David.

-- 
David Boyce

Tel:	+44 181 332 9091		Richmond, Surrey, ENGLAND
Email:	[email-masked]	Isode's WWW: http://www.isode.com/