Re: "tag:" Identification Idea [was: Re: Proposal: 'tag' URIs]

At 01:47 PM 4/29/01 -0500, Aaron Swartz wrote:
>Yes, Sean's plan was noticeably lax in the security department. However,
>your proposal is also flawed in that the only way to prove you own the term
>is by providing the random number. As soon as you do that, I can steal it
>and claim that I was the one who registered the tag.

That's so of any capability-based system. I didn't say you'd send it in the 
clear, I assumed the standard way to show possession of a capability: send 
it on a private channel to the principal that has to be convinced of your 
possession  -- in this case, the www-uri-tag@w3.org 'trusted third party'. 
Of course, that can be achieved (as in SSL) using the trusted third party's 
public key. They would then be able to issue a statement as to which of the 
disputing parties was assigned the email address.

Also, as I said in my description, the value v would come back to me 
encrypted -- obviously in a public key that I chose for the purpose and 
sent to www-uri-tag@w3.org  in the first message. Your protocol describes 
that encryption as being optional. It's not: otherwise, an attacker could 
seize the value, sign it with their key, and thus later be able to 'prove' 
it went to them.

So you demonstrate assignment by possession of a key, I prove it by 
possession of the value. My approach has the advantage that it isn't broken 
if Alice's key is compromised. Your approach has the possible advantage 
that Alice can directly prove 'she's the one' to principals other than the 
trusted third party. Can you think of any other advantages/disadvantages, 
either way?

Cheers,

Tim.

>An improved proposal is
>below:
>
>It seems there's a basic operation that you want to do with an email
>address: send a random number to the address and have the user reply with
>that random number and whatever authorization (digital signature,
>description of command, etc.) is necessary. Then make the reply publicly
>available if the random number matches. This solves many use cases.
>
>Note that system is still vulnerable to malicious eavesdroppers. To solve
>this, use public key encryption (and be sure that encrypt(msg,alice,bob) !=
>encrypt(msg,bob,alice)). Of course now you're open to a man-in-the-middle
>attack, but what're you going to do?
>
>If you wanted to do this for historical purposes the :
>
>User = Alice
>W3C = Trent
>
>     - Alice sends a registration request to Trent.
>     - Trent sends back an (optionally encrypted) random number.
>     - Alice (decrypts and) signs the number and sends it back.
>     - Trent posts the signed message, date and mailbox on his website.
>
>Now anyone can verify the signature on the message and know that the person
>with that key had access to that mailbox at that time.
>
>Anyone want to set this up? Has anyone done this?
>
>Idea archived at: http://logicerror.com/verifyEmail
>
>--
>[ Aaron Swartz | me@aaronsw.com | http://www.aaronsw.com ]


Tim Kindberg

internet & mobile systems lab  hewlett-packard laboratories
1501 page mill road, ms 1u-17
palo alto
ca 94304-1126
usa

www.champignon.net/TimKindberg/
timothy@hpl.hp.com
voice +1 650 857 5609
fax +1 650 857 2358

Received on Sunday, 29 April 2001 15:54:29 UTC