From owner-spki@c2.net Fri May 28 16:59:35 1999 Received: from blacklodge.c2.net (blacklodge.c2.net [140.174.185.245]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id QAA08134; Fri, 28 May 1999 16:59:31 -0400 (EDT) Received: (from majordom@localhost) by blacklodge.c2.net (8.8.8/8.7.3) id NAA00434 for spki-outgoing; Fri, 28 May 1999 13:21:04 -0700 (PDT) Message-Id: <3.0.3.32.19990528132024.00b5d2a0@poptop.llnl.gov> X-Sender: e048786@poptop.llnl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 28 May 1999 13:20:24 -0700 To: Stephen Kent , "Aram Perez" From: Tony Bartoletti Subject: Re: X.509 ACs vs. SPKI? Cc: ietf-pkix@imc.org, spki@c2.net In-Reply-To: References: <199905281831.LAA15698@scv1.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-spki@c2.net Precedence: bulk At 03:24 PM 5/28/99 -0400, Stephen Kent wrote: > >No, the seacrching problem I refer to is due to the use of ANY hash as an ID. > >Steve Slight digress from single/multiple hash algorithm support (I tend to agree with Steve - a fixed algorithm seems destined for trouble...) I have always been a bit puzzled by the position that indexing by hash value is a "problem". Technically, it seems simple to structure/index an efficient tree (order log n) search by hash value. Previous discussions reveal perhaps that the culprit is distributed DB/Directory management: Its easy to say that a given party controls the "OU=xxx" branch of the space, whereas division of the tree by arbitrary numeric values does not lend itself to this kind of delegated management. However, the DN-based tree structure seems (unfortunately) to lend itself all to easily to "trolling". (Let's see what lies in the C=X, OU=Y,... area.) Comments? ___tony___ Tony Bartoletti LL Center for Information Operations and Assurance LL LL Lawrence Livermore National Laboratory LL LL LL PO Box 808, L - 303 LL LL LL Livermore, CA 94551-9900 LL LL LLLLLLLL phone: 925-422-3881 fax: 925-423-8002 LL LLLLLLLL email: azb@llnl.gov LLLLLLLL