RE: [TLS] Please discuss: draft-housley-evidence-extns-00<

[Stefan Santesson <stefans@xxxxxxxxxxxxx>]

After paying careful attention to this debate, I would like to summarize my view on this proposal and give my recommendation to the WG.

My conclusion is that if the legal perspective of this proposal is removed, then it has potential and I would therefore vote YES to accept this draft as a TLS WG item.

The proposal can provide a relatively simple mechanism to authenticate events, such as agreements, conducted over a TLS session and there is no working, off the shelf, alternative solution available today that works cross platforms.

Example scenario:
The server side wants to present a some data to the client that the user has to accept. Such as agreeing to a purchase order.

If this is to be a signed agreement, we have building blocks like http get, CMS, XML DigSig and WS*, but they don't provide a complete solution for the whole chain of events from formatting the request from the server to invoke a signed acceptance, presenting the data in a way that is processed and uniformly displayed by the client, UI invocation for user consent, signing and returning the signed data.

This proposal provides an interesting "low budget" alternative by adding authentication to approvals that otherwise work just the way most businesses do today (based on plain http) but where the conversation making up this "acceptance" could be authenticated by a signature. This would add to the current level of security of a procedure that is already in use in many businesses. Adding this feature would have minimal impact on current application software and business systems. By doing this on the TLS layer many aspects of the "acceptance" could automatically be recorded such as client software version and html code provided for the data presentation. Things that adds to the audit value but would take enormous standards effort to get captured and documented in an application layer signature.

The TLS group should not speculate in the legal consequences of adding this authentication mechanism, but should make sure that the protocol is well defined and technically sound. Special attention should be given to development of a good security considerations section.

In the end of this process we will either have a good and solid protocol extension to TLS or have reached a point where we realize that this is a bad idea. But I strongly believe that this document, if developed, should be developed under TLD WG review and change control.


Stefan Santesson
Senior Program Manager
Windows Security, Standards



_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls