[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Finding paths, Was:Re: Domains of Trust for PKIX
At 18:31 8/17/98 -0400, Dave Horvath wrote:
>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.
I still do not understand how am I as a client of a PKI able to guess what
trust model is used in a PKI whose certificate I am verifying? If I can
guess that, than you claim that finding a path is easier if two different
attributes are used for storing the certificates. But my questions remains
- how can I guess that correctly? I do not see any way to do it. If I can
not guess the right trust model in the PKI I am verifying, than I must
assume the worst case in my certificate verification procedure, and that is
to look for all certificates in all attributes and search through them.
This operation is at least equally expensive as searching through all
certificates in one attribute, if not more expensive (I am not an expert in
LDAP search, but searching based on two attributes seems more expensive
than searching on one attribute).
On the other hand I am still failing to understand why is the search based
on two attributes so much more efficient than the search based on one
attribute, under the assumption that I can guess the trust model used. Is
the former case faster due to the total number of the certificates being
split into two attributes? Is it faster to look first for hierarchy
certificates since they are fewer than cross-certificates? However, in the
hierarchy case isn't the number of hierarchy certificates much higher than
the number of cross-certificates? If so, than it can't be much faster to
look fist for hierarchy certificates and then to look for
cross-certificates. Are there any test cases showing how much slower is the
case with only one attribute being used?
Am I missing something here?
Nada
>
>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
>