Re: TLS-CCA. Was: Browser UI & privacy - a discussion with Ben Laurie

On 10/8/12 1:07 PM, Nathan wrote:
> Ron Garret wrote:
>> On Oct 5, 2012, at 11:49 PM, Melvin Carvalho wrote:
>>
>>>
>>> On 6 October 2012 08:16, Anders Rundgren <anders.rundgren@telia.com> 
>>> wrote:
>>> On 2012-10-05 20:47, Henry Story wrote:
>>>
>>>>> WebCrypto could very well become a better mousetrap than TLS CCA.
>>>> By WebCrypto you mean using javascript. That does not really change 
>>>> anything.
>>> It does because it liberates WebID from a scheme (TLS CCA) that in 
>>> its current
>>> form is doomed as a consumer solution.
>>>
>>> TLS CCA is actually quite popular and useful for creating secure 
>>> tunnels between
>>> servers.  However, as a web solution for end-users TLS CCA has 
>>> essentially not
>>> taken a single step forward since 1996!  Well, the "underpinnings" 
>>> have changed
>>> considerably but that doesn't help much since its "behavior" remains 
>>> neanderthalish.
>>> The latter is presumably "by design".
>>>
>>> I'm surprised that you find the current key generation mechanisms 
>>> useful.  No major
>>> user of consumer-PKI I have heard of actually use them. "<keygen>" 
>>> as featured in
>>> Chrome was also designed in the 90'ties.  This is a very touchy 
>>> issue since
>>>
>>> http://www.ietf.org/mail-archive/web/pkix/current/msg31241.html
>>>
>>> caused the PKIX chairs to remove me from the list!
>>>
>>> Anders, did you ever look at this?
>>>
>>> http://lists.w3.org/Archives/Public/public-xg-webid/2011May/0047.html
>>>
>>> A full javascript solution to WebID including crypto libraries.
>>>
>>> May be interesting to this group.
>>
>> As long as Forge has entered the conversation I would also like to 
>> point to my own identity project:
>>
>> http://dswi.net/
>>
>> DSSID uses Forge for its crypto, but it uses a different protocol 
>> specifically designed to be simple for clients to integrate with.  
>> Note: this code is not ready for production use.  Feedback and 
>> comments are welcome.
>
> You could decentralize it and make it stateless by:
> a) using a URI for a UID (which could point to the clients public key)
> b) removing sessions (makes it stateless)
> c) swapping nonce for the URI of the resource being requested (ensures 
> user holds private key)
> d) adding an additional, optional, nonce (protect against replays, 
> additional protection, spot checks etc)
>
> you could also:
> e) have optional origin bound keys
> f) factor out URI/UID identification, and have them as optional 
> extras, this would allow specific origins to provide keys for clients 
> which are associated with specific identifiers behind the interface.
>
> IMHO all of these protocols are pretty much the same at an abstract 
> level, they're just mapped to different technology choices, and 
> occasionally have some nice extras, and occasionally have a load of 
> extras which aren't needed.
>
> Would be nice to define and standardize the intersection, instead of 
> forcing a plethora of specs on the net/web which are fundamentally the 
> same, only differing by forcing a particular technology choice, or 
> optional extra, as mandatory.
>
> Best,
>
> Nathan
>
>
>
>
+1

-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen