RE: [foaf-protocols] Sanity check

I think we can go further with this analysis ot the topic (without worrying about TLS properties themselves). We have to recognize that, since webid protocols is a fucntion of https, and https leverages the ssl handshakes(s), one of the "elements" of the webid protocol is a function of one or more ssl handshake.
 
So, we must really understand the ssl handshake (and their sequencing). later, we will need to better understand the record layer, and how the integrity/confidentiality mechanisms of the security association  then interplay with the framing AND the interpersion of handshake RUNS on the bearer.
 
So what is webid protocol not like?
 
its not like saml-style websso (whose design crux revolves around secure xml type theory and secure serialization).
 
its not like ws-security (which revolves around layers of security protocols)
 
its not like classical https (in which client auth exists to authenticate a t-entity or a user, wthich authorizes this parties contribution of entropy to shared master keying)
 
its not like http webauth, including digest auth (whose design crux is about  HTTP-styled state management)
 
its not like ipsec with entity auth (which focuses on delegating to hosts and routers the power to speak for other layer entities)
 
its not like a layer 2 or layer security protocol (focussed on hiding syncronization information that implies crypto information, occuring due to error recovery procedures at the network layer)
 
....
 
so what is it?
 
in the computing model of the web, its a secure urlref. its an address, at which is found either a coded instruction or coded data. And, its nothing more. once this is added to the semantic web, the web then builds up its security model based on the urlref, now secured.
 
In classical security studies, the closest concept for the ssl handshake in its role of expressing the secure urlref is: the capability.
 
If one works with the conceptual framework, TLS as its thought about in simplifying journalistic circles and undergrad courses is irrelevant. Its just a tool for getting to the secure urlref. Even as TLS WG in IETF think about TLS is essentially irrelevant (as their focus is comsec of the internet, not faciliating the webbiness that fuses the power of people with the power of computing).
 
so what inferences can we make from the axiom, formulated above in terms of what it's not?
 
- sessions are not a consequence of the raw webid protocol, focussing on desire to fasion a stateless web architecture. This is not to say that an additional axioms cannot be assumed that cooperate with that of webid to define HTTP state and the notion of a session.
 
- entity authentication and confidence in the security of data communiations is not a dominant design issue. Much like PGP, an 80% world of confidence, assurance and strength is just fine, since the focus is NOT comsec. As above, assuming additional axioms could enable the webid world to work much closer to the 100% levels of confidence, assurance and strength in subcommunities. But, additing these is like optionally negotiating the fortezza ciphersuite in SSL3, which upped the anti way above and beyond what the common or garden RSA ciphersuites accomplished when managing who contributes what entropy and what entropy types to the master secret responsible for the security of the SSL handshake itself.
 
- a secure urlref is only "asserted" when the asserting party of this "claim" receives notice that the receiving party has knowledge of the master keys. Confirmation of this knowledge state instantaneously changes an "assertion attempt" into an assertion, now known as a claim. In SSL handshake terms, this state change relates to critical crypto and security properties of the so-called "finished messages".
 
- there are distinct relationship between seuqential handshakes on the same channel and two handshakes cooperating on distinct channels. The latter may be implementing a speaks-for relationship - a well-understood logical theorem that pertains to the notion of delegation. In the world of webids, delegation is about the forwarding of secure urlrefs (webids) and the control system that allows speaks-for relationship to exist and to be deciding and then encording authorization claims that give an agent  (possibly a foaf agent) "authority to forward" claims, according to the rules of a web-scale authorization logic.
 
 
> To: foaf-protocols@lists.foaf-project.org; nathan@webr3.org
> Date: Sat, 22 Jan 2011 17:46:49 +0100
> From: yngve@opera.com
> CC: public-xg-webid@w3.org
> Subject: Re: [foaf-protocols] Sanity check
> 
> On Fri, 21 Jan 2011 19:09:09 +0100, Nathan <nathan@webr3.org> wrote:
> 
> > Just a quick sanity check, TLS connections are encrypted (with a random 
> > key) or suchlike, before any certificates are passed, yes? (as in, all 
> > data, including certificates, are encrypted over the wire, using keys 
> > not found in the certificates).
> 
> That depends on the server configuration, there is no such restriction in 
> the TLS protocol.
> 
> A TLS client certificate can be sent in the initial handshake, or in a 
> later renegotiation of the connection. In the latter case it is often 
> triggered by the requested URL being in a specific group of URLs that 
> require authentication.
> 
> Please note that if the server requests authentication during 
> renegotiation then the server SHOULD be patched against the TLS Renego 
> vulnerability (patched by RFC 5746), and it should require clients to be 
> patched against that problem, too.
> 
> For reference, the client certificate keys are only used to sign a hash of 
> the handshake messages, the result becomes part of the final handshake 
> hash. They are not used as part of the keyexhange.
> 
> 
> -- 
> Sincerely,
> Yngve N. Pettersen
> 
> ********************************************************************
> Senior Developer Email: yngve@opera.com
> Opera Software ASA http://www.opera.com/
> Phone: +47 24 16 42 60 Fax: +47 24 16 40 01
> ********************************************************************
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols@lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols