RE: Finding paths, Was:Re: Domains of Trust for PKIX

Nada - these statements re slow, fast, big, small are not generally
supported with platform type, DIT model, comms bandwidth specifications
IMHO.
For instance our DSA automatically indexes everything and because it is
supported with a commercial RDB we can do well specified searches on
most things over 20m distributed entries in a second or two.

Its all in the implementation and without such specification - "slow"
and "fast" terms used to qualify yet more work are a little wasted.

Your questions are very sound. 

regards alan

> -----Original Message-----
> From: Nada Kapidzic Cicovic [SMTP:nada@xxxxxxx]
> Sent: Tuesday, 18 August 1998 19:09
> To:   Dave Horvath; Santosh Chokhani
> Cc:   'Mike Smith'; aberger@xxxxxxxxxxxxxxxx; ietf-pkix@xxxxxxx
> Subject:      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@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
> >
> >-- 
> >               ================================================
> >
> >      _/_/_/                   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@xxxxxxxxxxxxx
> >