[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Indexing and retrieving keys
Bill Frantz wrote:
> unique names. If we treat the unique name as a non-unique attribute, then
> we have the situation where each entity can have many certificates in "the
> database", and lookups can proceed by asking for all certificates where the
> name_attribute == X and some_other_attribute == Y.
This is reasonable, but it's also possible that the piece of
information you called "Y" above -- the final couple of bits that
chooses the exact key can come interactively from a user. This already
happens today, when you go about trying to get someone's PGP key. You
might do a search for "Jeff and Allen" on the key repository and then
only add to your keyring the key that you were looking for (even
though you got back several different keys for the Jeff Allen you
meant, and a key for a completely different Jeff Allen).
As we design and implement Whois++-powered applications, we constantly
come across the question "Should the result-narrowing decisions happen
in the client or the server". Since the client (or the user operating
it) will know better than the server what they were _really_ searching
for, we try to push those things into the client as much as possible,
when it can be done without degrading performance too much.
BTW: Just to make it clear, I'm still talking about generic issues that
we need to face when thinking about search and retrieval of keys. My
experience lies in Whois++, so I feel most conforatble using it to
illustrate the concepts I'm talking about. Though I think the Whois++
template format is a quick, cheap solution to SPKI's "key packaging"
needs, I don't think keys will be managed with Whois++ alone. (Was
that a disclaimer? Oh lord, I promised myself never to stoop that
low. :P)
--
Jeff Allen <jeff@bunyip.com> | For information about Bunyip
Bunyip Information Systems, Inc. | send e-mail to <info@bunyip.com>
References: