[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Domains of Trust for PKIX
The important point is that no matter what trust model you deploy, I
believe Santosh's proposal will never hinder path development. IMHO it
should help those who attempt to identify the trust model, but it will
not hinder those who don't care. Both the ones who don't care and the
ones who care (during path construction) will probably validate which
domain they are in during path validation.
Dave Horvath
Santosh Chokhani wrote:
>
> 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@zionsbank.com]
> Sent: Monday, August 17, 1998 12:32 PM
> To: chokhani@cygnacom.com; aberger@darmstadt.gmd.de
> Cc: ietf-pkix@imc.org
> 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@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
--
================================================
_/_/_/ David J. Horvath
_/ _/
_/ _/ Chromatix, Inc.
_/ _/ _/ 10451 Twin Rivers Road, Suite 265
_/ _/_/ Columbia, MD 21044
_/ _/ _/_/ Phone: (301) 596-8466 | http://www.chromatix.com
_/_/_/ _/ _/ Fax: (410) 997-4306 | dave@chromatix.com