[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Looking up keys by email address



From: Carl Ellison <cme@cybercash.com>
> 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, "cme@cybercash.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?

> 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.  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:

> 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.

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.

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.

Hal

Follow-Ups: