Re: Domains of Trust for PKIX

I am not sure if it is good for PKIX to "suggest" one or the other trust
model.  It should be up to the developers and users establishing the PKI to
choose the model that fits their needs. 

PKIX should define PKI protocols and procedures that fit all of the
different trust models, and that's exactly what has been done up to now. I
do not agree with you that trying to support all of the trust models was a
hinder in building PKIX standards.

Perhaps it might be a good idea to have a separate document describing all
of the different trust models that might be used for implementing a PKI,
but we should not try to define "the most suitable" or "the best one".

That is a bad idea for two reasons:
1. We will never get an agreement as to what is the best. This is probably
the topic where our opinions differ the most.
2. It might kill all of the PKIX efforts since part of the user community
might not be happy with the choice (like what happened with PEM RFCs 1421 -
1424 that required strict hierarchy model).

I believe this was discussed earlier and agreed in this way.

Regards,

Nada


At 10:31 8/17/98 -0600, Mike Smith wrote:
>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 developers 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
>












    !
>!
>












    !
>!
>


                                                        
>