Subject: Re: PKIX Path determination/construction/processing andAKIpointer hanging

From: "Peter Williams" <[email-masked]>
Date: Fri, 5 Mar 1999 12:38:40 -0600

Bob,

I like much of your thinking. It seems suited to the general Internet
culture.

If a cert path has two certs (A & B) , and the second (B) has an authority
key identifier pointer to its parent, can the chain be valid
it the identified parent is specifically NOT A, according to PKIX?

This situation happens when, as per your example, unidirectional, unilateral
cross-certification (without policy mapping, say) occurs into a
hierarchical,
policy-oriented PKI domain which has pre-established AKI backpointers.

My thoughts are, assuming what I thought was a simple question is answered
positively for the 2459 case, that PKIX-QC might establish that a
critical flag on the AKI would make this situation INVALID, in contrast.
And, therefore, enable the well-controlled PKI domain to signal that
inward, unilateral  cross-certification is not supported - as
enforced by 2459-conforming relying parties who require the
assurances of the PKIX-QC interoperability policy.

Peter.

-----Original Message-----
From: Bob Jueneman <[email-masked]>
To: [email-masked] <[email-masked]>; [email-masked]
<[email-masked]>
Date: Thursday, March 04, 1999 3:04 PM
Subject: Re: PKIX Path determination/construction/processing andAKIpointer
hanging

>Peter and
>Peter and David,
>
>I'm not sure that I understand the argument -- maybe I wasn't paying
attention earlier.
>
>maybe peter can clarify what he means.
>
>I have in mind a model where I as the relying party have a certificate
chain that starts at some CA that I trust, and may descend top down from
Issuer to Subject, probably ending with my own certificate.
>
>In addition, there is a chain of certificates sent to me (or otherwise made
available) by the originator or signer of some document, which I process
bottom up, chaining from Subject to Issuer.  Unfortunately, if I follow that
certificate chain all the way to the originators "top" I may never encounter
a certificate that I trust.
>
>So in addition to the normal, bidirectionally link chain of certificates in
my own hierarchical tree, I have some cross-certification certificates that
may very well by unidirectional.  In other words, at any particular node in
my own hierarchy, that CA may have issued a cross-certificate which includes
the public key of some node in the originator's chain of certificates.
>
>So the path processing algorithm proceeds as follows:
>
>1.  Start at the root of my (the RP) hierarchy, and process all of the CA
certificates top down, keeping a cache of all of the public keys (key IDs).
>
>(1a.  Repeat for any additional trusted hierarchies, including any
certificates added by the relying party on his own authority, e.g., his
sister's end user certificate, or a CA or subordinate CA issued by a company
that they are partnered with, regardless of the fact that they don't
necessarily trust that company's top-level CA.)
>
>2.  Start at the bottom of the signer's certificate chain and process
bottom up.
>
>3.  At each step of the way, query the cache of public keys to determine
whether that key has been seen before, and hence is considered trusted. If
so, then the path extends from the RP's own trusted root down his chain to
the cross certificate, and then continues down the originators chain from
that point on to the end.
>
>4.  If the public key in question has not been processed previously and
therefore know to be trusted, then continue climbing the signer's tree
bottom-up, following the Issuer chain.  (How you find these certificates is
of course a different issue -- I'm only addressing the chain of trust.
>
>5.  If you reach a self-signed certificate (indicating the top of a chain)
without having encountered a key that is trusted, then the path is not
trusted and you have to decide to do with it -- reject the whole chain, ask
the user whether to add the certificate on a one-time basis, or whatever.
>
>6.  Once you have blazed a trail through the woods, chopping a notch on
every tree (key) that you trust until you get back to your own top, then
(and only then, I believe) have you identified the path, and are prepared to
process the entire chain from top down, this time omitting the signature
validation but doing
>all of the validity checking, CRL checking, constraint checking, etc.  It
could be argued that you could validate the date range on the first pass
through the  certificates. maybe you could argue that you should check the
CRLs at that time also, but that may be a more expensive process, and
perhaps you ought to validate the chain as it stands before going elsewhere
to check the status.
>
>Now, Peter, does what I have suggested fit the path establishment model you
were proposing?  If not, could you describe yours more completely, because
the above is the only one I've been able to convince myself really works.
>
>Bob
>
>
>
>>>> "David P. Kemp" <[email-masked]> 03/04/99 08:07AM >>>
>
>> From: "Peter Williams" <[email-masked]>
>>
>> QUESTION: If a certificate path chosen by a relying party contains at
>> least one certificate whose authority key id backpointer does
>> NOT resolve to a certificate in that path or any certificate
>> known to the relying party, can one designate otherwise normal
>> processing of  that chain as conforming to PKIX 2459?
>>
>> My answer to the question is yes. Does anyone disagree?
>
>
>If I understand the question correctly, I disagree.  Restating
>the question as I understand it:
>
>  If a certificate path chosen by a relying party is not
>  a continuous chain between the certificate being validated
>  and a certificate trusted by the relying party, can one designate
>  otherwise normal processing of that chain as conforming to RFC 2459?
>
>If the relying party has no notion of a trusted public key, or has
>an implementation which returns a "success" answer when given a path
>not terminating in a trusted public key, then RFC2459 is irrelevant.
>Frobbing the bits in accordance with section 6 may increase the entropy
>of the relying party's immediate environment (generate some heat and
>waste some time), but it has no other useful effect.
>
>RFC2459 says "This text assumes that all valid paths begin with
>certificates issued by a single 'most trusted CA'." (and then goes
>on to discuss extended path validation where paths may begin with
>one of several trusted CAs).
>
>I interpret "This text assumes ..." to mean that if the assumption
>is not met, then the results are undefined, and that if the results
>are undefined, then there is no meaningful conformance.

---

From: "David P. Kemp" <[email-masked]>
Date: Fri, 5 Mar 1999 17:02:46 -0500 (EST)

> policy-oriented PKI domain which has pre-established AKI backpointers.

Aha, now I understand the question.  But I still don't understand the
issue.

The second cert (B) contains a signature value which was generated
by its parent, call it C.  B contains an AKI pointing to C.

If the cert path A->B passes the signature verification, then A's
public key must be able to verify a signature created by C's private
key.  AFAIK, that can happen only if A knows C's private key.

Are you asking if RFC 2459 allows unilateral unidirectional
cross-certification by means of private key sharing?  Perhaps it
does, but the very idea seems imprudent, to say the least.

---

From: "Bob Jueneman" <[email-masked]>
Date: Fri, 05 Mar 1999 15:08:57 -0700

Peter,

The thought of making the AKI CRITICAL hadn't occurred to me,
but I can see one particular application where it might be put
to good use.

Generally speaking, a Relying Party should only have to answer 
to itself regarding the criteria it uses for path validation. After all,
the RP is perfectly free to take the risk of no signature and 
no certificate chain being present at all, depending on the value 
of the transaction and the risk the RP wishes to take.

However, there are some cases where the terms and conditions
of a particular Closed PKI group are such that the sponsor 
of the closed PKI is distinctly unwilling to act as a root of an open PKI,
or even to assert any compliance with its terms and conditions 
regarding lower-level CAs and end-users, perhaps because of liability 
concerns.

In that case, making the AKI critical would accomplish that goal, at
least as far as standards compliant processing is concerned.

It still doesn't PREVENT the relying party from relying on whatever
it chooses to, but it would presumably be a strong indicator in case 
of a dispute that reliance on the certificate chain outside of the 
chosen trusted root/path should not be considered commercially 
reasonable.

Bob

>>> "Peter Williams" <[email-masked]> 03/05/99 11:38AM >>>
Bob,

Peter.

-----Original Message-----
From: Bob Jueneman <[email-masked]>
To: [email-masked] <[email-masked]>; [email-masked] 
<[email-masked]>

attention earlier.
bottom up.

---

From: "Bob Jueneman" <[email-masked]>
Date: Fri, 05 Mar 1999 15:42:30 -0700

David,

The scenario I was describing was one where the signer's self-signed root is A, A signs B, and B signs C's certificate. C, the end user, then signs a document.

The relying party's root is X, which signs Y, which signs Z, which is the RP's own certificate if anyone cares.

Now  X, or Y, or Z, can unilaterally create a unidirectional cross-certificate by signing A, or B, or C's public key and filling in the other information as desired.  

All they have to know is the public key of A, B, or C.

How they know to trust A, B, or C is their business, and is handled out of band, as is the trustworthy conveyance of the various public keys.

Bob

>>> "David P. Kemp" <[email-masked]> 03/05/99 03:02PM >>>