Subject: RE: Correct approach to certificate validation?

From: "Trevor Freeman" <[email-masked]>
Date: Wed, 7 Jun 2000 16:54:53 -0700

Certificate discovery is not the issue here. 

The question is that if you have a certificate who's signature integrity
can be traced up to a trusted root, containing acceptable policy as
defined by that root, and  who's names lie within the allowed namespaces
as defined by the name constraints in parent certificates to the
certificate in question, what is the value in checking that the
issuer-subject names chain?
We have encountered such situations, by design, and by accident. In all
cases, the cost\benefit analysis in our view is stacked in favor of not
performing the name chaining check, and tolerating this situation.

I agree that name constraints are important as the certificate is making
those names available to the applications, so it is important that we
can filter acceptable from not-acceptable names. We actually follow a
methodology similar to one you mentioned in a previous thread which is
to build all possible paths, then apply the name constraints to
determine the quality of the path.

For certificate discovery,  we have a domain push mechanism as well as
AIA. We are also adding a lookup by name, and a configurable URL search
path i.e. a set of URLs to search (LDAP, HTTP, FTP)

Trevor
 -----Original Message-----
From: 	Stephen Kent [mailto:[email-masked]] 
Sent:	Wednesday, June 07, 2000 3:42 PM
To:	Trevor Freeman
Cc:	[email-masked]
Subject:	RE: Correct approach to certificate validation?

Trevor,

Two observations:

	- path construction (going up toward a root) is nominally 
based on the use of the issuer name to find the right CA certificate, 
with the AKI/SKI used to disambiguate among multiple valid CA certs. 
I recall that the list discussed the potential problems of using just 
the AKI to locate a CA certificate.  I expressed concern then that 
the AKI didn't provide a means of locating a CA certificate when it 
was not local, i.e., one would need to have a database that was a 
flat file for all possible CA certificates to do the lookup.  My 
concern was that we were creating a situation where people might 
build systems that had all the shortcomings of LAN e-mail systems, 
e.g., they worked well locally, but did not scale across the 
Internet. Of course, if one uses the AIA extension this problem might 
be ameliorated.  So, my question is how do MS products locate a CA 
cert that is not available in a local cache or local LDAP directory, 
using just the AKI?

	- name constraints are critical to secure use of certs, so I 
do hope that you are correctly enforcing this extension, when it is 
present.  Contrary to what  Amir said, this is PKIX, not SPKI.  We 
don't buy into the notion that keys are principals here :-).  If one 
always uses name constraints in cross certs that link to other 
administrative domains, something that a local CA or  can enforce 
unilaterally, then names are reasonably safe to employ for access 
control purposes. (Of course, one can't do this with TTP, but maybe 
that's another good reason for not using them when identification for 
access control is important.)  But, if you're violating the standards 
to accommodate administrative sloppiness in managing CA names for 
chaining, then maybe you're assuming an environment where one can 
never rely on names for ACLs anyway. That's a scary environment.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 8 Jun 2000 15:20:47 -0400

Trevor,

>Certificate discovery is not the issue here.

I know that the focus of the discussion has been matching up subject 
and issuer names when validating a cert path.  However, since cert 
path discovery logically precedes validation, and since the nominal 
model for discovery is based on looking for a CA cert that contains a 
subject name that was the issuer name on the "lower" level cert, I 
think it appropriate to ask the discovery question.

>The question is that if you have a certificate who's signature 
>integrity can be traced up to a trusted root, containing acceptable 
>policy as defined by that root, and  who's names lie within the 
>allowed namespaces as defined by the name constraints in parent 
>certificates to the certificate in question, what is the value in 
>checking that the issuer-subject names chain?
>We have encountered such situations, by design, and by accident. In 
>all cases, the cost\benefit analysis in our view is stacked in favor 
>of not performing the name chaining check, and tolerating this 
>situation.

Could you provide some examples of the "by design" situations you 
have encountered?

>I agree that name constraints are important as the certificate is 
>making those names available to the applications, so it is important 
>that we can filter acceptable from not-acceptable names. We actually 
>follow a methodology similar to one you mentioned in a previous 
>thread which is to build all possible paths, then apply the name 
>constraints to determine the quality of the path.

I don't recall suggesting the approach you mention here.  I would 
guess that path discovery performed using subject/issuer name 
matching and AIK/SIK discrimination would rarely yield multiple 
paths. But, if it did, then I agree that application of the name 
constraints extension as part of path validation would discard paths 
that violated the constraints.

>For certificate discovery,  we have a domain push mechanism as well 
>as AIA. We are also adding a lookup by name, and a configurable URL 
>search path i.e. a set of URLs to search (LDAP, HTTP, FTP)

The domain push mechanism sounds local, perhaps MS specific?  AIA 
would be definitive.  Does one look at the issuer name to select a 
subset of the search search paths you allude to, or do you just try 
to do lookups via ll of them?

Steve