Naming via SDSI

Mark S. Miller markm@caplet.com
Tue, 06 Mar 2001 22:43:46 -0800


At 07:09 PM Tuesday 3/6/01, Brandon wrote:
>My main issue with total subjectivity is that it requires that you pass
>around fat references (keys) all the time. So I can't tell someone "Check
>out megatokyo.com." I have to say "check out
>asjldkq9u4q8412093ajla0912l". It helps if you have a computer-mediated
>communication environment to do translation for you, but it sucks for
>voice and written. I know the last time I wrote down my PGP fingerprint I
>made to copying errors. If it was a different kind of key, such errors
>woul have made it useless.
>
>Having naming paths helps because then, for instance, I can run a name
>mapping service and if you already have my key then I can tell you "check
>out brandon/megatokyo" and that path will resolve. It still has the same
>theoretical problems, but in practice will suck less because you tend to
>communicate with the same people a lot.

I think this summarizes well both the good and bad news with total 
subjectivity, as in SPKI/SDSI/Pet-Names.  I also think this is as good 
as it gets.  See http://www.cap-lore.com/MathPhys/GRref.html .  And I think 
the bad news isn't this bad, as explained below.


The other choices are mostly illusory.  "Central authority" actually becomes 
"choosing sides" since (hopefully) we'll never have unanimity about who 
should be world dictator.  Witness the upcoming war between ICANN and the 
government of Tonga of the TLD ".to".  (Tonga refuses to pay their dues to 
ICANN, saying, rightly, "Who put you in charge?".)  Global name spaces 
create unsolvable political problems.  To attempt to live within a global 
name space is to choose to subjugate yourself and your customers to 
unnecessarily centralized authorities.

"Choosing sides" is really just a broken way to look at subjectivity + 
naming paths anyway, as the creators of SDSI correctly explained.  For 
example, in my use of PNML,

    <pn>Brandon<s/>tldServer<s/>to<s/>cypherpunks</pn>

starts with the name server I take to serve Brandon's exported names, asks it 
what TLD server it takes as authoritative, and then decodes cypherpunks.to 
within that TLD system.  This might be a different entity than the one 
designated by my use of "<pn>tldServer<s/>to<s/>cypherpunks</pn>".  So even 
the domain name system is best seen through the eyes of subjectivity + 
naming paths.


For direct communication with people you already know, I think you 
underestimate:

>I can run a name
>mapping service and if you already have my key then I can tell you "check
>out brandon/megatokyo" and that path will resolve. It still has the same
>theoretical problems, 

I don't think it does.  If I have a communications directly from Brandon, 
let's say I meed Brandon at a party, and let's say I have a basis for 
believing a correspondence between my face-recognition of Brandon and his 
fingerprint; then, if he either tells me "brandon/megatokyo" or scribbles it 
on a piece of paper, I know that the "brandon" is my already established 
naming root for him, not a name to be looked up in a global or almost global 
name space.  Of course, in a Mission Impossible plot my face and voice 
recognition of Brandon at the party might be spoofed.  But that's the only 
remaining theoretical problem I see with this use.

The only real bad news with subjectivity above is "voice and written" with 
people you don't already know.  

For written:  I've got my PGP fingerprint on my business card, as do many 
other people.  People already often clip their cards to documents they hand 
out.  This fingerprint is a fine naming root for the naming paths in the 
document.  Xerox has some fine technology for embedding machine readable 
info unobtrusively in the normal ink printing patterns on paper, and one 
can imagine a convention for embedding a name-root fingerprint in a company 
letterhead.

For voice:  If it's in person, it can still be supplemented by a business 
card, and often is.  If it's not in person, then it's over an electronic 
medium, which can carry other information as well.



        Cheers,
        --MarkM