RE: NEW Data type for certificate selection ?

[Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>]

Yes the problem is a path issue. where CAs may have multiple paths to
their roots or other CAs, multiple approaches to revokation, Users have
multiple certficates, clients might be root and domain agile, etc.

I have views on this which says we should not complicate the certificate
any more-  so the client gets even more complex and untrusted, we should
use some simpler methods of validation with the assistance of the
directory service.

Phone systems are good - my telephone does not have software in it to
prove the telephone company can provide it with its phone number ! :-)

see lloyd-dir-cert-stat-00.txt - I thought it was a good start in the
right direction - but I am biased of course :-)
regards alan 

----------
From: David Boyce
To: Sarbari Gupta
Cc: 'David Boyce'; ietf-pkix@imc.org
Sent: 10/14/98 12:48:24 AM
Subject: Re: NEW Data type for certificate selection ? 

Sarbari Gupta writes (quoting David Boyce):
>>(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.

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

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.

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

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:	d.boyce@isode.com	Isode's WWW: http://www.isode.com/