[TLS] proof of receipt service , in RFC 4507; TLS Evidence relationship

[<home_pw at msn.com>]

  "The server MUST NOT
  assume that the client actually received the updated 
ticket until it
  successfully verifies the client's Finished message." 
[RFC 4507]

I've been modeling out the RFC additions to the state 
machine, and formulating the security claims a product would 
make, on asserting compliance. An interesting claim is 
possible, based on standard's language: Proof of receipt of 
the content of a ticket, based on the cryptographic 
properties of the finished messages (and the hashes involved 
in the finishing process).

This proof of receipt is obviously symmetric. There is proof 
the server received the client's ticket's content(s) too, in 
the server's finished message. The tickets contents are 
scheme-defined, of course. It can be a signed XML blob in 
there!

Good. This is what I always wanted. Now, in its own right, 
the handshake is a proof service for X data (not only the 
secure state transition). If certificate based ciphersuites 
are used, it becomes "connection-NR"-grade proof. Like 
TLS_Evidence asserted, any party can verify stored handshake 
messages, once the PMS is released to an affadavit/notarized 
process. The optin, willing acceptance rules governing 
agreements would seem to be built into the way the ticket 
extension is negotiated, and the obligations the endpoints 
have to validate tickets, during reliance and during 
assertion, per the protocol spec. 


_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls