Subject: RE: Correct approach to certificate validation?

From: "Trevor Freeman" <[email-masked]>
Date: Fri, 9 Jun 2000 11:36:12 -0700

Steve,
With the Internet today, if you are relying on directory lookup based on
a DN as you only solution to certificate discovery - I think you will be
disappointed. There will be "communities" who will be able to get this
to work, but there is no sign of a universal solution equivalent to DNS
where I can take any DN and find an object in a directory with that
name. Therefore failure to find a certificate based on a issuer DN in a
certificate is a reality that will have to be dealt with - for much more
fundamental reasons.

There are a couple of instances of by design behavior that have been
presented to me. There are mergers and acquisitions where names and
affiliation are changing. There are also instances where one CA does not
want to endorse the name of another when it cross certifies.

The search path mechanism is very similar to AIA, in that given a set of
URLs, you can access the URL looking for certificates. With LDAP URLs,
it's not difficult to construct a generic query. With other, the
underlying assumption is that you find a pkcs#7.

Trevor

 -----Original Message-----
From: 	Stephen Kent [mailto:[email-masked]] 
Sent:	Thursday, June 08, 2000 12:21 PM
To:	Trevor Freeman
Cc:	[email-masked]
Subject:	RE: Correct approach to certificate validation?

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

---

From: Stephen Kent <[email-masked]>
Date: Mon, 12 Jun 2000 17:36:35 -0400

Trevor,

>Steve,
>With the Internet today, if you are relying on directory lookup 
>based on a DN as you only solution to certificate discovery - I 
>think you will be disappointed. There will be "communities" who will 
>be able to get this to work, but there is no sign of a universal 
>solution equivalent to DNS where I can take any DN and find an 
>object in a directory with that name. Therefore failure to find a 
>certificate based on a issuer DN in a certificate is a reality that 
>will have to be dealt with - for much more fundamental reasons.

In general I agree if we're talking about most DNs, and that's why I 
alluded to use of AIA.  But, if one used DC-based DNs, we could 
leverage the DNS and that would be very powerful. So, for those who 
might choose to rely on this or analogous discovery approaches, 
mismatches between CA names in subject and issuer fields would pose a 
problem. Facilitating an environment in which such mismatches are 
tolerated by client software undermines the efforts of those who 
might be trying to use CA DNs for repository discovery.

>affiliation are changing. There are also instances where one CA does 
>not want to endorse the name of another when it cross certifies.

The first example does not seem very good; as someone else noted, I 
would want to reissue the EE certs as much as I want to change the CA 
cert.  I've gone through a bunch of business cards over the last few 
years as we wer bought, reorganized, bought again, etc.

>
>The search path mechanism is very similar to AIA, in that given a 
>set of URLs, you can access the URL looking for certificates. With 
>LDAP URLs, it's not difficult to construct a generic query. With 
>other, the underlying assumption is that you find a pkcs#7.

The "algorithm" you allude to seems a bit squishy :-), and its 
scaling features are not at all clear.

Steve