Re: PKIX Path determination/construction/processing andAKIpointer hanging

["Peter Williams" <peterw@xxxxxxxxxxxx>]

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 <BJUENEMAN@novell.com>
To: ietf-pkix@imc.org <ietf-pkix@imc.org>; dpkemp@missi.ncsc.mil
<dpkemp@missi.ncsc.mil>
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" <dpkemp@missi.ncsc.mil> 03/04/99 08:07AM >>>
>
>> From: "Peter Williams" <peterw@valicert.com>
>>
>> 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.