Re: RAW public keys and WebID - where the URI goes

On 11/21/14 8:55 PM, Timothy Holborn wrote:
>
>
> Sent from my iPad
>
> On 22 Nov 2014, at 1:16 am, Andrei Sambra <andrei.sambra@gmail.com 
> <mailto:andrei.sambra@gmail.com>> wrote:
>
>> Hi all,
>>
>> On Fri, Nov 21, 2014 at 8:56 AM, Melvin Carvalho 
>> <melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.com>> wrote:
>>
>>
>>
>>     On 21 November 2014 12:29, Yunus Durmuş <yunus@yanis.co
>>     <mailto:yunus@yanis.co>> wrote:
>>
>>         Hi everyone,
>>
>>         These days, RAW public keys (RFC-7250
>>         <http://tools.ietf.org/html/rfc7250>) are being pushed for
>>         tiny constrained devices. As the name suggests, instead of an
>>         X509 certificate, only the public key is transferred nothing
>>         else -even the identity and signature-. The motivation behind
>>         is that there will be less bits on the wire and there won't
>>         be any need for certificate parsing/validation code.
>>
>>         Then the question is how can we transfer the magic URI for
>>         the WebID protocol? We can  embed the uri in the messages of
>>         DTLS (Datagram-TLS) or we can attach it to the end of public
>>         key. However, there won't be a certificate signature that
>>         verifies the integrity of the URI.
>>
>>         Do you consider it as a serious problem? With a man in the
>>         middle attack, the URI can be altered, which results in a DOS
>>         attack. But, to me, it is the same as changing the X509
>>         certificate on the wire with a new one.
>>
>>
>>     Nice find, thank you for sharing!
>>
>>     I'm starting to use public keys themselves as identity, much like
>>     bitcoin does.
>>
>> There is a bit of a trade off here. While in bitcoin's case it works 
>> fine, because people need a persistent public key that matches to 
>> their wallet, for WebID this would not work, and here is why. The 
>> identity mode simply does not rely on public keys because they are 
>> (and should) be replaceable as soon as the user thinks that's the 
>> case (e.g. losing a phone or a laptop, changing browser, etc.). There 
>> is simply too much of a turnover for the keys in WebID-TLS. :-)
>>
> IMHO - webid-tls works very well to identify the agent, being the 
> browser, phone, tv, laptop, etc.
>
> Addressing a particular user to that device agent (and rule set) is 
> then a ldp / rww / credentials, or more broadly - other issue.
>
> Multiple people can, and do, use devices.  This doesn't negate the 
> benefit of the design, just the contents of the applied document, I 
> think...
>

What a WebID identifies, in a verifiable manner, via WebID-TLS is 
ultimately a function of a "proof of work" algorithm. In the case of 
WebID-TLS proof of work is comprised of:

1. local claims -- local x.509 certificate comprised of identity claims 
(including a watermark by way of an HTTP URI value for the SAN attribute)
2. public claims mirror -- a public WebID-Profile document comprised of 
claims that mirror those in #1
3. HTTP URI Lookup -- which resolves to the document referred to in #2 
above.

Note: the subjectAlternativeName (SAN) attribute == 
subjectAlternativeName relation, which in the case of WebID-TLS has an 
HTTP URI as its object (value).

Conclusion:

The Agent in question is an entity that's demonstrably  performs the 
"proof of work" that underlies the protocol. That's it. These rules 
apply in other contexts such as verification of identities associated with:

1. Passports
2. Drivers Licenses
3. Social Security Cards
4. Credit Cards
5. etc..

WebID and WebID-TLS is just a digital realm rendition of the same thing. 
No rocket science involved whatsoever. This is all about the dexterity 
of AWWW (Architecture of the World Wide Web) :)

Remember, the building blocks or AWWW are:

1. URIs
2. HTTP
3. HTTP URIs .

Then add RDF language to the mix, and you have the ability to make 
digital sentences/statements that enable encoding and decoding of 
information based on logic.

-- 
Regards,

Kingsley Idehen 
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this