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

["Peter Williams" <peterw@xxxxxxxxxxxx>]

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 <mfsmith@zionsbank.com>
To: ietf-pkix@imc.org <ietf-pkix@imc.org>; peterw@valicert.com
<peterw@valicert.com>
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" <peterw@valicert.com> 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.
>
>.
>
>