Re: Publishing updated spec documents.

On 2/25/14 2:17 PM, henry.story@bblfish.net wrote:
> On 25 Feb 2014, at 19:43, Kingsley Idehen<kidehen@openlinksw.com>  wrote:
>
>> >On 2/25/14 1:14 PM,henry.story@bblfish.net  wrote:
>>> >>On 25 Feb 2014, at 18:15, Kingsley Idehen<kidehen@openlinksw.com>  wrote:
>>> >>
>>>> >>>On 2/25/14 11:17 AM, Andrei Sambra wrote:
>>>>> >>>>Hi all,
>>>>> >>>>
>>>>> >>>>I would like to formally invite everyone to review the current version of the specs for WebID [1] and WebID-TLS [2] so that we can have a formal call this Friday (Feb 28th), at the usual time [3]. The purpose of this call will be to agree on the contents of the new documents so that the editors can finally publish them.
>>>>> >>>>
>>>>> >>>>Best,
>>>>> >>>>Andrei
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>[1]https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html
>>>>> >>>>[2]https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/tls-respec.html
>>>>> >>>>[3]http://www.w3.org/2005/Incubator/webid/wiki/Main_Page#Meetings
>>>> >>>Andrei,
>>>> >>>
>>>> >>>
>>>> >>>Wouldn't it be prudent to separate these items in regards to voting? By that I mean, #1 shouldn't be delayed if voting for #2 is inconclusive, for instance.
>>>> >>>
>>>> >>>We really need to get #1 out, as soon as possible.
>>> >>I think both documents are a huge improvement over the previous ones. These
>>> >>are not last call documents, but they do deserve to replace what we have now.
>>> >>Are there any issues you see with #2?
>> >
>> >I don't have issues with either, my fundamental concern is that they shouldn't be conflated in any way i.e.., #1 can be released before #2, if need be.
>> >
>> >I just want the docs out there.
>> >
>> >Our biggest challenge right now is the decoupling of WebID (the HTTP URI that denotes an Agent) from the WebID+TLS authentication protocol, which is ultimately one of many protocols that will be used to verify WebIDs.
> yes, they are nicely decoupled now. WebID TLS relies on WebID definition, and not the other way around.
>
> The next big things are really Web Access Control ( apart from a few improvements one can perhaps make to WebID TLS )
>

If we can get this out on time, we have prime attention real estate 
(increasingly scarce these days) for things like:

[1] Authentication Protocol(s)
[2] ACLs.

Here's is a very quick and dirty dump of the kind of narrative we can 
ride, on the back of the MITM issues that Apple has brought to the fore:

Actors identified by the combination of Literal Identifiers, CAs, and 
Hostnames:

1. Alice sends a message to Bob, which is intercepted by Mallory:
Alice "Hi Bob, it's Alice. Give me your key"-->  Mallory      Bob
2. Mallory relays this message to Bob; Bob cannot tell it is not really 
from Alice:
Alice      Mallory "Hi Bob, it's Alice. Give me your key"--> Bob
3. Bob responds with his encryption key:
Alice      Mallory   <--[Bob's_key] Bob
4. Mallory replaces Bob's key with her own, and relays this to Alice, 
claiming that it is Bob's key:
Alice   <--[Mallory's_key] Mallory      Bob
5. Alice encrypts a message with what she believes to be Bob's key, 
thinking that only Bob can read it:
Alice "Meet me at the bus stop!"[encrypted with Mallory's key]-->   
Mallory      Bob
6. However, because it was actually encrypted with Mallory's key, 
Mallory can decrypt it, read it, modify it (if desired), re-encrypt with 
Bob's key, and forward it to Bob:
Alice      Mallory "Meet me at 22nd Ave!"[encrypted with Bob's key]-->   Bob
7. Bob thinks that this message is a secure communication from Alice.

Actors identified by the combination of Reference based Identifiers 
(e.g., HTTP URI) based Identifiers and a Web of Trust logic:

1. <#Alice> sends a message to <#Bob>, which <#Mallory> would like to 
intercept:
<#Alice> "Hi Bob, it's Alice. Give me your key" --> <#Mallory>  attempts 
to intercept and impersonate <#Bob>
2. <#Mallory> relays this message to <#Bob>; but (thanks to WebID tweak 
of TLS handshake) <#Bob> *can* tell it is not really from <#Alice> 
because his user agent looks up (by way of HTTP URI de-reference) 
<#Alice> in the SAN of the certificate used in the TLS handshake only to 
find that the public key presented by <#Mallory> can't be found in the 
profile document that describes <#Alice> so this fails, and <#Bob> knows 
it isn't <#Alice>
3. Then end -- Mallory has to find a way to place her public key in a 
profile document situated (located) in a point of network presence 
controlled by <#Alice> (not impossible in the NSA era, but eternally 
brittle since the burden is not long skewed against <#Alice> i.e., she 
can make certs and SAN combos with ease).

We just need to flesh this narrative out, and compliment with a nice 
illustration etc..

Let's strike while the iron is red hot!


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: 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