Subject: Re: PKIX Path determination/construction/processing and AKIpointer hanging

From: "Peter Williams" <[email-masked]>
Date: Tue, 2 Mar 1999 10:47:10 -0600

Mike,

I try not to speak to sound business practice on this list, except
in the context of PKIX-QC, given it has a high-trust-level mission
to achieve, meeting "legally-valid" requirements. PKIX-QC, in
adressing legal validity, is but one of the applications or
environments that PKIX standards can now attack to engender
open-vendor, interoperable deployments. Seperating the technical
conformance standard from the policy-based interoperability rules
was definitely a good step for PKIX to have taken (assuming
the QC effort can steer clear of the naming chasm).

The only actionable aspect of trust addressed by PKIX's 2459
is the selection of trust-points - public-keys (or "roots") accepted by
relying-parties as reliable authentication information bound to
a given entity using procedures not involving (generally) the
use or reliance on certificates.

PKIX conformance does require a set of "non-trust" actions. These
actions "data process" cert paths, according to the technical requirements
of 2459.  Conforming processing is sensibly required, so processing
of a given trust path by vendor P's software produces the same result
as vendor Q's.

Perhaps my point was not made clearly, yesterday. Let me restate
it as an issue and a question:

ISSUE: PKIX gives a relying party discretion to choose trust-points, and
construct the certificate path used to validate a user certificate. That
path
will be made up of cert values issued by one or more certificate
management domains (such as the VeriSign Trust Network). Within
a hierarchical domain, the authority key id backpointers (in those
certificate of the path issued under the policies of that domain) will
normally point to the parent certificate.

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?

Peter.

-----Original Message-----
From: Mike Smith <[email-masked]>
To: [email-masked] <[email-masked]>; [email-masked]
<[email-masked]>
Date: Tuesday, March 02, 1999 10:41 AM
Subject: Re: PKIX Path determination/construction/processing and AKIpointer
hanging

>Whether sound business practice or not, the options allow four options to
the relying party for selection of trust domains:
>1.  Trust all CAs whether local or outside the local domain of trust (i.e.,
don't validate paths)
>2.  Trust your domain (search upwards from relying party's issuer until
finding an issuer at a high enough level to include the foreign certifcate
in the relying party's trust domain)
>3.  Trust the sending party's domain of trust, building a path from the
included cert, its CA, the CA's CA, etc., acquiring all of the associated CA
certs, CRLs, ARLs and CKLs, then parse and process on the client
>4.  Go to a trusted third party to see if they will vouch for the sender's
CA and the relying party's CA to build the bridge between the sender's and
relying party's trust domains.
>
>Options 2 and 4 imply some business relationship between the relying party
and the trust domain source, but 4 could be the same self-assumed risk as
option 1.
>
>Other options that do not rely on path building begin at the local domain
of trust (relying party's CA) and provides that the local CA do all of the
contracts, chaining, bridging or assumption of risk on behalf of the relying
party and returns an official "okey dokey" or other status on the single
cert that the relying party (or their software systems) is verifying
validity.  (this system may even return some "rights" or other attrubutes,
such as "the cert is still valid, but do not rely on it for any purchases
over USD$5"
>
>Have I missed something here?
>
>Michael
>
>
>
>>>> "Peter Williams" <[email-masked]> 03/01 10:23 AM >>>
>Preamble
>
>Consider the following quotation from our RFC, and envisage
>the demo path situation in which one has an signed email quoting
>a user certificate from a VeriSign Class 3 organizational CA.
>Futhermore, envision that the various user and authority
>certificates in the VeriSign hierarchy link backwards
>to identify their parent certificates or self-signed public-
>key registered by the VeriSign Root registration authority.
>
>" (a) Certification paths may start with a public key of a CA in a
>      user's own domain, or with the public key of the top of a
>      hierarchy.  Starting with the public key of a CA in a user's own
>      domain has certain advantages.  In some environments, the local
>      domain is the most trusted. "[RFC2459]
>
>Following the option of 2459, the certification path selected by a
>validating
>user may commence with the users own private CA; which, issues
>a private-usage interdomain certificate for ANY of the various VeriSign
>authority certificates. Let us say it issues the interdomain
>certificate for the lowest VeriSign operated CA (the one
>that manages the enterprise-operated CAs in the VeriSign domain).
>
>Issue:
>
>When our relying party performs conforming path processing,
>authority identifiers,  which are marked critical for the user and say the
>enterprise authority certs, the  authority key id pointer in the enterprise
>cert will be left "hanging".
>
>That is, the parties path validation software would presumably
>not enforce presence or knowlege or well-identifiedness
>of other VerISign authority certificates. Instead it would
>apply processing based on its local trust delegation
>mechanisms. Said software, will ensure that the interdomain certificate
>issued by the relying parties CA to to thge enterpise CA's public
>key validly introduces the user certificate to the local environment.
>
>Apparent Rule:
>
>PKIX-QC might restrict valid path processing to the chain implied
>by authority pointers, so that fixed and CA-managed policy
>controls are enforced.
>
>In general PKIX, and with any non-legalistic policies, relying party
>domain rules governing path processing/validation are free to leave chain
>pointers hanging, providing that they have local-CA mechanisms
>such as that suggested in 2459 to discover/determine/proces
>the locally-required trust path.
>
>Question:
>
>Any major disagreement with what seems to be PKIX-conforming process,
>and suggestions for the PKIX-QC document?
>
>Peter.
>
>
>NB: The same issues goes for CRL(DP) and OCSP certification paths.
>
>.
>
>

---

From: "David P. Kemp" <[email-masked]>
Date: Thu, 4 Mar 1999 10:07:03 -0500 (EST)

> From: "Peter Williams" <[email-masked]>
> 

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: "Peter Williams" <[email-masked]>
Date: Thu, 4 Mar 1999 10:58:11 -0600

-----Original Message-----
From: David P. Kemp <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Thursday, March 04, 1999 11:00 AM
Subject: Re: PKIX Path determination/construction/processing and AKIpointer
hanging

>  otherwise normal processing of that chain as conforming to RFC 2459?

David,

There have been a couple of responses. Let my query your
analysis to find out what is driving you to try to disagree with
a simple technical assertion concerning hanging backpointers
(marked critical, or otherwise):

You seem to have invented a technical term "continuous chain."

What is a "continuous chain"?

"  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?"

Does a cert path which has hanging AKI backpointers constitute
a continuous chain (all things about the chain or the RP's locally trusted
authority
being otherwise acceptable/valid to the relying party
and 2459 descriptive formalisms)?

>are undefined, then there is no meaningful conformance.

Its fine for a relying party to define its own notion of conformance.
Indeed, it is necessary.

Peter.

---

From: "Bob Jueneman" <[email-masked]>
Date: Thu, 04 Mar 1999 10:20:59 -0700

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: "David P. Kemp" <[email-masked]>
Date: Fri, 5 Mar 1999 16:07:05 -0500 (EST)

> and 2459 descriptive formalisms)?

A (properly formed) continuous chain obeys the RFC 2459 Section 6.1
"path processing actions" item (a)(4): the subject and issuer names
chain correctly.

Section 4.2.1.1 says that conforming CAs MUST include the key identifier
field in the AKI extension, which MUST be non-critical.

Section 4.2.1.2 says that the SKI extension MUST appear in conforming
CA certificates, that the SKI value must match the value of AKI in the 
subordinate certificates, and that the SKI extension MUST be non-critical.

Now, what do you mean by a hanging AKI backpointer?  If a cert contains
an AKI extension and its parent cert does not contain an SKI extension
with the same value, then the CA is not in conformance with Section
4.2.1.x.  That is a serious error on the part of the CA, and calls into
question the CA's competence and attention to detail.  But if despite
the bad or missing information in the key identifier extensions, the RP
is able to find (perhaps by trial and error) an issuer cert which can
be used to verify the signature on the issued cert, then I agree that
an otherwise valid path may still be considered valid.

I am sorry, but I had trouble understanding what you meant by the
previous posting.  On the one hand you seemed to be discussing a
separation of "trust" and mechanical processing, and on the other hand
you seemed to be discussing the purely mechanical processing of key
identifier extensions.  In the latter case, my answer to the question
is yes, I agree.

---

From: "David P. Kemp" <[email-masked]>
Date: Mon, 8 Mar 1999 09:13:09 -0500 (EST)

> Abstracting, the general rule is, then, if a relying party system
> detects that a CA is non-conforming with PKIX
> in matters of cert format, extension schema, criticality, etc, this fact
> is not a basis by PKIX-implementors to designate 
> such a certificate as invalid, nor designate
> the chain on which it is a member as similarly invalid, 
> nor affect  the security protocol event which
> is relying on the cert path (such as an SSL connection
> handshake, or S/MIME signature verification).

I would be ecstatic if the minimum path validation procedures
in section 6 were followed by all RP software.  The end goal is
to do more than the minimum, but lets concentrate on the
mandatory requirements first.

> Therefore, noone should code  up their ASN.1 compilers with
> ASN.1 value constraints which impose the value conditions
> of 2459's text (e.g. rejecting a cert with a  critical
> AKI criticality bit, say, during type/value checking).

What does a C compiler do when it encounters non-ANSI-conforming
code?  It may provide a warning, or it may fail to compile, depending
on the wishes of the human operator.  I wouldn't suggest that either
C compilers or RP validation software not have the capability to
lint-check their input.  The user sitting at the User Agent, or
his security administrator, should have the ability to specify
the actions taken when a PKIX CA-conformance failure is detected
during path validation.

> If anyone doing 2459 detects SKI != AKI, they should not reject
> the cert path.
>
> Agreed?

They should detect the condition. They should then silently ignore
it, noisily accept it, or reject it at the option of the RP.

In the specific case of SKI != AKI, it is likely that path development
software will not be able to construct an otherwise valid path in the
first place.  The AKI extension is a hint; it would take more
sophisticated software and more execution time to produce a valid path
where the hint is incorrect or absent than where it is correct.  Given
the current state of the art, it would be prudent to assume that if
CAs issue certs with incorrect AKI extensions, sender and recipient
software will not be able to use them in cases where the issuer
DN is used with more than one signing key.  Problems may first show
up when the CA is first rekeyed and certs with both the old and new
keys are valid during the rollover period.

---

From: "Peter Williams" <[email-masked]>
Date: Mon, 8 Mar 1999 10:53:43 -0600

I have got a clear opinion from the list. Unless there

>the actions taken when a PKIX CA-conformance failure is detected

ASN.1 value constraints control "processing-time" type/value
checking, not compile-time checking. It can be used
to help implement ITSEC-style high-assurance requirements: that
an implementation does what the spec says, and nothing more,
as latitude represents potential insecurity.

In some Internet-ready certification profiles (ie. SET), the ASN.1
processing eliminates the non-conforming transactions, designating
them invalid for syntax, profile conformance and other similar reasons;
the security  procedure fails consequently; payment is not performed; goods
are not ordered.

PKIX is just more liberal. Validity is in the eye of the beholder, by
design.
Courts can choose to trust the opinion of certain beholders more than
others, presumably, where they can rationalize their procedures
for validation.

This thread  suggests we need to move ahead on the Entrust-led
notary work ASAP, so PKIX becomes useful to higher-value
commercial apps where standardized validity(s) is/are required.
 http://www.ietf.org/internet-drafts/draft-ietf-pkix-dcs-00.txt

Peter.