Re: Web Object Encryption and Signing (WOES) at IETF

Got to study modern tls sockets this week, in which winsock interceptors "add security semantics" to the channel (tls or dtls).

Designed for corporate markets, the browser is largely sidelined. The browser pretends to the user that she is talking to site x (though she is not.) Data flows are inspected at the inspection point, malware signatures evaluated at wire speed of 40gbps, and tls sidechannels (custom record layer protocols) used to exchange  sideband signals between inspector and trusted desktop security agent - since the browser is treated as an untrustworthy system component, in general (being designed for webiness).

Of course the goal here is in part to redefine webiness to define a relevant browser assurance, that helps redefine the moribund trust research space (full with reputation, trust, threat, dossier  based conceptions based on metric theory).

Webid had to define a new relevant space that originates new secure communication modes at (huge) scale, rather than just reimplement old protocols with new syntaxes. 

My gut goes with connectionless https, with gdoi style key management (in signed canonical json or x509 certs, I could care not a jot which - unless legacy browsers are to be addressed).

On Feb 18, 2011, at 9:00 AM, Henry Story <henry.story@bblfish.net> wrote:

> 
> On 18 Feb 2011, at 17:32, Peter Saint-Andre wrote:
> 
>> On 2/18/11 9:29 AM, Henry Story wrote:
>> 
>>> For me it's easier to put all documents behind https, have users
>>> publish the public key as specified below for WebID authentication
>>> and do access control: only allow authorised users to retrieve the
>>> document. There you get on the fly encryption of any content you
>>> send.
>> 
>> To clarify requirements, many of those who are interested in this work
>> at the IETF want to make it possible for browser-based clients to do
>> things like encrypted instant messaging or voice and video signalling.
> 
> Though there again, I suppose the browser could just connect to the server 
> over https and send the content that way... That should be able to cover a 
> lot of use cases. I suppose one could also use DTLS for voice over ip.
> 
>> So perhaps the scope is a bit broader than WebID
> 
> different use cases probably...
> 
> It is just interesting to see how far one can push those down to the TLS level. Every time one can do that one reduces the need for a special encryption and authentication syntax for the content sent. The end user can just receive the content and parse it cleanly.
> 
>> (I confess to not having followed WebID closely).
> 
> In the current context one could think of WebID as just being https  that works. A client can connect securely and identify himself to  any server. The rest is then taken care of by TLS.
> 
> But signatures and encryption at the document level comes up all the time.
> 
> Btw. in the semweb land there is the work on "Signing RDF Graphs" 
> by Jeremy Caroll
> 
>   http://www.hpl.hp.com/techreports/2003/HPL-2003-142.html
> 
> Henry
> 
>> 
>> Peter
>> 
>> -- 
>> Peter Saint-Andre
>> https://stpeter.im/
>> 
>> 
>> 
> 
> Social Web Architect
> http://bblfish.net/
> 
> 
>

Received on Friday, 18 February 2011 18:00:07 UTC