Subject: Cross-certificate path processing

From: "Bob Jueneman" <[email-masked]>
Date: Fri, 13 Aug 1999 13:06:20 -0600

Marc,

I think you have confused locality of trust with the path construction.

True, I may trust CA C, in your example, more than the more remote CAs,
but B signed C's certificate, not the other way around.  So C can't impose
constraints on B, B has to impose them on C.

In the paradigm I have described several times, user 1 is operating in 
a domain of trust established by A, and A gets to specify whatever constraints
it wishes to.  

Likewise B can specify constraints on E, and E on F, and F on 2.

The path processing has to be bottom up, in order to establish what 
CAs are involved, and then top down to establish the constraints.

So bottom up, the relying party (1) looks at 2's certificate and asks if
he recognizes that key.  If not, he proceeds up the chain.

When he comes to E's public key and he asks if he has seen it 
before, the answer is Ah ha!  I have seen it, because I processed 
the cross-certificate. So now the RP completely abandons the
D hierarchy as being of no consequence, and tracks back to A.

Then in order to properly validate the various extensions, he starts at A
and works his way back down the chain.

This is particularly important, because there may in effect be multiple
"A's", with different policies that apply to different kinds of transactions,
in other words a choice of Platinum, Gold, and Silver certificate.

If A-Platinum is selected, then assuming B and C conform, E and F will be
tested to make sure that they conform to the A-Platinum requirements.

What constraints might have been imposed by D don't matter to the
relying party, who doesn't necessarily trust D in any case.

However, observe that this makes it almost impossible for D to enforce 
a negative policy that would restrict usage of lower level certificates.

A unidirectional cross-certificate can be issued that includes the public
key of some intermediate CA, without that CA necessarily even being
aware of that fact, and without that CA's concurrence. Of course
D would deny any liability in that case, but it can't prevent the
certificate chain from being used.

Bob

>>> Marc Branchaud <[email-masked]> 08/13/99 12:18PM >>>
Robert Moskowitz wrote:
> 
> OK.  The path construction starts with the EE's trusted cert, typically a
> root cert.  But any other CA in the path root cert is not needed if the
> linkcage is cross-cert.
> 

I think I was slightly confusing the CA at the top of a hierarchy with
the root ca that is the trust source in a path (using the definitions
from the Roadmap now).

I still feel the need to niggle with your statement, though.  Consider
this:

   A    D
   |    |
   B----E
   |    |
   C    F
   |    |
   1    2

where A-F are CAs and 1 & 2 are users.  A is at the top of the A-B-C
hierarchy and D is at the top of the D-E-F hierarchy.  Also, B and E
have cross-certified.

The path that 1 uses to verify a cert for 2 is sourced either at A or
C.  That is, 1 either implictly trusts A or C.  If 1 trusts C, then I
agree with your statement that other CAs in the path to A (say, if there
were CAs between B and A) would not be considered in the path that is
validated.  That path would be C-B-E-F-2.

But if A is the trusted CA (as is common is hierarchical PKIs), then the
path that is validated is A-B-E-F-2, and so extensions in A's cert (and
any certs between A and B) are included in the validation.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL
INC.
 [email-masked]        PKI References page:             
www.xcert.com 
 604-640-6227          www.xcert.com/~marcnarc/PKI/ 
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

---

From: Marc Branchaud <[email-masked]>
Date: Fri, 13 Aug 1999 12:43:16 -0700

Bob,

I agree with your analysis, though I think the confusion you saw in my
message is due more to its vagueness than my misreading of the
situation.

I feel we're all sortof reading from the same page here, so I don't want
to extend this any further.  Just to clarify my previous message,
though, I was thinking of a more general hierarchy, in which each CA
certifies its parent as well as its children.  In that case, 1 may very
well not be in a trust domain defined by A (in building the chain, 1 can
go from B to C instead of to A).

I admit that I was really unclear about this in my message.

The desirability and practicality of such an arrangement is pretty
debatable though.  Is such a general hierarchy truly a hierarchy
anyway?  How many certificates can dance on the head of a pin?

		Marc