Domains of Trust for PKIX

[Mike Smith <mfsmith@xxxxxxxxxxxxx>]

Andreas:

Path validation, revocation path traversing, policy contraints, policy mapping, "trusted CAs" "trusted roots", etc. all assume a trust model exists for the PKIX work.  I do not think that trust models have been explicit enough.

I think that the "trust" in a personal PKI (the individual accepts whom they trust) is greatly different from a more formal or corporate PKI (the individual is only allowed to trust those trusted by the corporation).

I think the personal trust model is exemplified in the PGP model and other self-authenticating systems.

So, what trust model are we using in PKIX?  Is it all?  Is it a one trust source (a la some government Trusted Third Party systems?  Is it: I trust only my issuer, I need to rely on it to accept responsibility for the certificates they issue or tell me it is OK to accept (there is probably some sort of bilateral agreement between the issuer and the certificate subscriber)?

Once a single trust model (or all trust models) are defined, then the PKI technical work can continue to design a working model within the specific trust model.

I think that the PKIX group is working on a public CA trust model wherein the relying party gets to accept his or her own individual trust model.  If this is so, then maybe I and others should refrain from interjecting all the corporate-processing issues based on different trust models.

In PKIX, we have specified and recommended practices for CAs, maybe we need to define the PKIX trust model separately, as well.  Maybe we need to define all of the trust models and then let devlopers choose which they are designing for and then subset the PKIX documents based on the different trust models.

I do not think that we can develop any technology solution unless we define the business problem that we are trying to solve.  I do think that the business problem that we are trying to solve is the business of "who to trust", so we need to have a trust framework defined before we can build the technical framework to support it.  We have, often, a lot of debate on the list from folks assuming PKIX is working to support one or more trust models.  Maybe we can focus the debate if we define the various trust models and their implications for PKI under PKIX?

Michael

>>> Andreas Berger <aberger@darmstadt.gmd.de> 08/17 9:04 AM >>>
Santosh Chokhani wrote:
> 
> Sharon:
> 
> I have studied the path development a lot.  I am not claiming that I am
> correct.  But, here are some of the conclusions I have come to:
> 
> 1.      Path development is efficient when done backward from the
> direction of trust, i.e.,  from subject end entity to relying party
> trust anchor(s).
And the end entity certificate is probably all you have, e.g. take an
S/MIME Message with the end entity certificate attached or identified by
issuer and serial.

> 2.      Path processing has to be done in the forward direction of
> trust, i.e., from the relying party trust anchor(s) to subject.
What do you do if you have several trust anchors, i.e. a set of
keys/certificates you decided to trust. The selection of anchors may
even be restricted depending on the nature of the document.

But all that leads me to the question whether the current description of
path validation is sufficient. Do we need an advice (best practice) how
applications should find certificates and how they build paths? All I
know of is a description of how to verify that a path is correct, not
how to (efficiently) find probable paths to put into the verification.
And avoid loops and unpromising paths.

Andreas
-- 
Fifty-three percent of Fortune 1000 executives think the
Arch Deluxe is something that helps to run a computer.
-- Jericho Communications