RE: Domains of Trust for PKIX

Mike:

I agree with what you said.

The views I have shared in this forum on certificate path development
efficiency are applicable to the most trust models I conceive.
Furthermore, having two attributes for two types of certificates seems
to help conceivable efficiency mechanisms.

        -----Original Message-----
        From:   Mike Smith [SMTP:mfsmith@xxxxxxxxxxxxx]
        Sent:   Monday, August 17, 1998 12:32 PM
        To:     chokhani@xxxxxxxxxxxx; aberger@xxxxxxxxxxxxxxxx
        Cc:     ietf-pkix@xxxxxxx
        Subject:        Domains of Trust for PKIX

        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@xxxxxxxxxxxxxxxx> 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