Re: TLS-Light

On 11/30/11 10:08 AM, Peter Williams wrote:
>
> given copies of the public key exist in a billion http caches, HOW in semantic web and linked data *culture* does "disablement" occur? It needs to say. I doubt this sepc will be read by mom and pop users. It's far too technical. Im not sure a vendor would know what to do or to measure, either.
>
>
>
> Theft of a .p12 file export of a browser (*or platform) credential store typically copies the private key within (since most PC security systems use software crypto). Once its stolen, like most IP its hard to get all the copies back.

In the Linked Data realm, you drop the relation in your data space that 
associates your WebID with the public key in the missing .p12. Same 
applies to Certs in keychain/keystores of your host OS. Ditto cryto keys.

The real beauty of WebID is that I can delete relations with alacrity 
across my IdP data spaces. I don't have to go to hell an back just 
because I've lost my private key.


>   Getting assurance you have all the copies is essentially impossible, for the costs folks will typically bear.

See comment above. Its a simple delete. Basically, another example of 
why I felt Twitter was an important IdP, just delete our tweet. The same 
applies to Blog spaces, delete the blog post.

>   Its irrelevant whether its password protected (and that the password is a secret from which a data encryption key is drived, used in an AES encipherment mechianism within .p12).Compromise means "loss of control" and inability to assign risk metrics.

See comments above.

>
>
>
> Compromise recovery (vs revocation of crredentials for access controls" in key management is basically what distinguish a Lexus from a Ford. Key distribution is what a webid profile does, sitting on some blog site firing packets out
>
>   
Yes, and with a RWW aspect taking shape thanks to many Web 2.0 apps, 
deletion of the "mirrored claims" is trivial.

>
>
>
> be careful when saying vacous things such as :"citizens of the world are responsible for the future of the human race, and when noticing that others are not eating well, users need to take action to make distribution of the the food supply more fair." Its tempting to be use idealisms, to cover up lack of professional engineering.
> In many corporate use cases, Bob will not be responsible in the manner suggested, and BOB will NOT be the party doing the compromise recovery (Bob will run away, or be fired, typically).

Bob needs to understand WebID conceptually. I had a chat with Henry 
yesterday about this aspect of the WebID spec. Specs should always have 
Conceptual and Technical sections. We are going to fix the missing 
conceptual stuff. Once done, we also have foundation for the concerns to 
outline re. what Bob should be digest en route to WebID exploration and 
eventual exploitation etc..

> Decide  if corporate culture IS or IS NOT a part of the community of users anticipated by webid in the next 3 years. Be clear in terminology, and tone. Appeal to an audience (other than 10 developers of code).

In my eyes, this is a major solution for enterprises. Simply major!

>
>
> "+<dd>Bob is an agent who uses a<tref>Client</tref>  to connect to<tref>Alice</tref>'s Service, and who is responsible for the private key the<tref>Client</tref>  uses to authenticate to<tref>Service</tref>s.
>      3.23 +If he notices the private key was compromised he needs to take action to disable the public key."
>
>
>
> I notice that the spec draft can no longer be tagged as being anti-CA, since it defines a CA for the first time.
>
>
>
> Its focus on TLS rather than https (the protocol identified by the scheme) is unfortunate. https is not the same as TLS, as https uses SSL sessions in a particular way for hypermedia. Web services over HTTP typically use TLS without conforming to the https scheme used in mozilla-class clients.

I think we can work on the conceptual spec and set appropriate tone for 
target audiences.

Great points you've raised!

Kingsley
>
>
>
> ----------------------------------------
>> From: henry.story@bblfish.net
>> Date: Wed, 30 Nov 2011 14:58:02 +0100
>> To: public-xg-webid@w3.org
>> Subject: TLS-Light
>>
>> I have updated the spec with the notion of TLS-Light . See the new spec in mercurial and the following diff
>>
>> https://dvcs.w3.org/hg/WebID/rev/3012b63e69f3
>>
>> The idea is to clarify that the TLS service we use is a simplified TLS service: therefore than any existing TLS service should be useable: i.e. no big backend infrastructure changes needed.
>>
>> Henry
>>
>> Social Web Architect
>> http://bblfish.net/
>>
>> 		 	   		


-- 

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