[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Looking up keys by email address
At 11:24 PM 2/26/97 -0800, Hal Finney wrote:
>From: Carl Ellison <firstname.lastname@example.org>
>> The NAME: <auth> gives a name binding in the namespace of the issuer -- a
>> SDSI name.
>SDSI has a mechanism to allow DNS names. For example, "email@example.com"
>is a legal SDSI name, being equivalent to "(DNS!! com cybercash cme)"
>(approximately - I don't have the docs in front of me). Would the NAME
>tag allow this kind of SDSI name? If so, could third parties bind such
>DNS names to keys? Or will SPKI require the SDSI name bindings to only
>be local names?
The NAME tag can't allow a compound name. The NAME tag [assigning
a key to a name in my namespace] must use a name in my namespace, therefore
of the form (name).
>> As for delegating NAME permission, SDSI has answered that. The answer is
>> that you don't delegate permission to assign names. Rather, you refer to
>> some other person's namespace by SDSI's (K1 N1 N2 N3 ... Nk) where K1 is the
>> public key of the namespace N1. [This is a departure from the SDSI
>> document, which assumed you knew K1 (the key of the cert issuer). I added
>> K1 to the name sequence here so that I could detach the name from a cert
>> (and therefore knowledge of K1) and still have it mean something.]
>I think there are problems with SDSI's naming model, which I won't go
>into in any detail right now. Briefly, it is not clear that DNSSEC
>is going to be widely deployed in the near future, so I don't think we
>can rely on the existence of a DNS key hierarchy.
Nothing in the logic of SPKI requires an on-line database of certificates.
SDSI provides its own on-line databases, for each namespace, although
that is probably for convenience. What we're borrowing from SDSI (the
name linking semantics) doesn't require such databases.
>And with local names,
>I can't import other people's name spaces en masse, I have to examine each
>one individually and set up my own local alias for it. There is no way
>(as I understand it) for me to say that I want to trust all the bindings
>made by Verisign and just refer to them in the same way that Verisign did.
>Maybe SPKI's delegation fixes this, though:
SPKI's delegation either fixes this or shows that what you were thinking of
is unwise. That depends on what you were thinking of.
When you talk about trusting all the bindings made by Verisign, that's
automatic when you use a verisign name. E.g., if you have Verisign's root
key in your namespace, e.g., under the name (VS), you can refer to any name
Verisign issues via (VS name).
Of course, VeriSign doesn't assign any rights to such keys -- only names. If
you wanted to attribute some right to such a key (e.g., via a local policy
to grant store credit to anyone who shows up with a VeriSign Class II cert),
then you're asking for the PolicyMaker extensions to SPKI. What SPKI does
is force you to make that explicit policy statement -- so that you're forced
to consider whether this is a wise policy. [In this case, I refer you to
ABC News Prime Time Live from last year, the show entitled "True Name
Fraud", in which they showed the folly of such a policy.]
>> The general question you started with -- how to show you accept <auth> from
>> issuer Iss -- is that you generate <You, Iss, D, <auth>, V> where D is 1
>> greater than the max D you want Iss to be able to issue. For a name cert,
>> this gives an interesting effect. It means that you delegate to some other
>> source (your own personal namespace agent?) (your private secretary who
>> keeps your address book) the authority to make name bindings for you. As a
>> result, if you are K1 and your secy is K2, then (K1 N) would equal (K2 N).
>There is a small problem with this, different from the naming issues I
>am really interested in. The problem is that I have to make assertion
><auth> about Iss, which I may not want to make. In one of your documents
>you use a banking relationship as an example. I know my bank's key,
>and I want to use it to find the key of the interbank agency, which then
>signs another bank's key and which I can use to verify that the other
>bank is legit. I want to let the interbank agency make an "Is a bank"
>assertion but I want my bank to make only an "Is the interbank" assertion.
I was about to point out that SPKI doesn't force you to do delegation by
integer. It just provides that for convenience. If you don't do it
by integer, then you define various different <auth> fields which have
explicit (and enumerated) ">" relationships. This is what commonly
happens with old style cert hierarchies -- with some keys labeled as
CA and others as leaves of the tree. See SET for an example of such
explicit <auth> definitions with explicit ">" relationships.
However, the same argument we used with delegation applies here.
With integer delegation, we considered whether to allow someone
to exercise an <auth> if his d>0. It's the same thing you're asking
for. The answer we came up with was that if someone wants to exercise
the power of the <auth> which he is denied because his d>0, he can
generate a key for himself and issue a d=0 cert for that key. The
very same observation applies to <auth> ordering relationships not
using d. To wit, you can't stop your bank from approving other
banks, by setting up their own interbank authority. If you trust
your bank, you probably want to make it easy for the bank to certify
another bank. If you don't trust your bank, you're SOL.
>However with SPKI I have to give my bank the power to make claims
>about what other keys are banks, with the delegate value set to 2.
>It then claims that the interbank is a bank, with delegate set to 1.
>The interbank then makes the actual claims about which keys are banks.
You have a choice. However, this is the simpler (to me) and no less
secure than the my_bank -> interbank -> other_bank explicit <auth>
ordering you prefer.
>My bank has to understand through some out-of-band means that even
>though I am giving it the power to make claims about what other keys
>are banks, it's not supposed to use that power, but rather it is only
>supposed to sign the key of the interbank using that delegated power.
>Maybe this works, but still what the certificates say does not really
>match up with what claims are being made.
If you don't trust your bank, no certificate mechanism
will make it trustworthy, once you certify it locally.