certificate path services [ was RE: NEW Data type for certificate selection ? ]

[Sarbari Gupta <sgupta@xxxxxxxxxxxx>]

I seem to agree with Alan that there are certain situations where it
would be very beneficial to have third-party services available to
assist with certificate path development and/or validation. 

If (and when) large scale PKIs become widely deployed, it could become a
real problem for each end entity to look up and then validate the
certificate path to its peer's certificate. It requires a large amount
of processing power as well as complicated path processing software to
do this task. Additionally, it requires repeated interactions with a
remote Directory Server to build the certificate path.

There are (at least) two ways to resolve this issue:

1) We introduce the concept of a trusted service, let's call it
"Certificate Path Validation Service (CPVS)" which could take in
requests for validation (comprising the end entity certificate and
possibly a trusted root, policy IDs, etc.) and return an YES/NO answer.
The  CPVS could be hosted on a high-end server that caches recent
requests and has the capability to interface with
Directories/Repositories over the internet to quickly obtain an answer
for the subscriber, thus relieving the end entity system from the
overhead of certificate path processing. The CPVS would also support
revocation models. The CPVS would be particularly useful in an
organizational environment, where a single dedicated system runs the
CPVS for that organization and services path validation requests for
other users within the organization. To support the notion of a CPVS
service, a new service interface needs to be defined and standardized. 

2) We extend the services offered by a Directory Server to allow the
retrieval of an entire certificate path is one call. Thus, the end
system would issue a single LDAP call to the Directory Server (providing
as inputs, the end entity certificate, trust anchors, etc.)  to retrieve
an entire certificate path. The actual path validation would be done on
the end system itself. In this case, there is no need to trust the
Directory since the actual path validation is done locally. The
Directory Service is extended to support path development - also
implying an extension to the LDAP interfaces. 

I think it would be beneficial to offer viable alternatives to
developers of PKI-based systems/products to unburden them from
complicated path processing functions. I am curious to hear others'
opinions on these ideas.

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

> -----Original Message-----
> From:	Alan Lloyd [SMTP:Alan.Lloyd@OpenDirectory.com.au]
> Sent:	Wednesday, October 14, 1998 6:06 PM
> To:	'Sarbari Gupta '
> Cc:	''David Boyce' '; 'ietf-pkix@imc.org '
> Subject:	RE: NEW Data type for certificate selection ? 
> 
> 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/
>