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

I don't see any choice. TLS Evidence has to become a work 
item. This is not to say I support the particular technical 
approach: but the initiative is appropriate, addressing with 
technical means both data retention (corporate wiretapping 
obligations) and the way in which regulated ESIGN sites are 
applying https and SSL in practice.

----- Original Message -----
From: <home_pw@msn.com>
To: "Steven M. Bellovin" <smb@cs.columbia.edu>
Cc: "Omirjan Batyrbaev" <batyr@sympatico.ca>; <tls@ietf.org>
Sent: Thursday, January 11, 2007 12:49 PM
Subject: Re: [TLS] Please discuss: 
draft-housley-evidence-extns-00<

>> In any event, your analysis and conclusions are wrong.

I've been following up the claim. Specifically, the claim 
that its all wrong (the implication being its peter 
bullshit...) And the facts are more interesting that I first 
thought - mostly because of some new features of IE7 (and 
vista).

I've (re)found two https sites that require custom 
https-plugins or custom https browsers. Each have 
(ESIGN-citing) site policies that assert that the 
plugin/custom-app is the "secure signing device" required by 
ESIGN. One uses a MSN Money plugin to web-browser (or the 
MSN Money application), and the other example used a 
scripted quicktime plugin. Both, plugins interacted with 
(regulated) financial sites, where specific policies were 
disclosed concerning "writings".

Of course, the whole thrust of ESIGN was to define that 
records (such as electronic signature (including the digital 
variety)) can constitute "writings" - despite the 17th 
Century laws being phrased in old-fashioned media terms 
(paper, pens, handwriting, etc). The (legal) nature of any 
writing, ESIGN variants included, continues to demand that 
they must be reduced to tangible form; that requirement does 
not go away, for electronic records/signatures.

In the case of SSL-based signatures, from custom https 
plugins (with their assured trust models and CAs etc), that 
form has to be the server-side audit trail itself - the 
packets, the TCP fragments, the SSL ciphertext, its 
cleartext handshakes, or the http data within. TLS Evidence 
is on the right track, as are other means of exploiting the 
SSL handshake to preserve (and optionally secure) the 
"recordation" act.

One of the cuter features of the modern IE7 browser, and 
vista OS, concerns its support for handling the trusted 
path. One notes from sites that exploit Microsoft own 
CardSpace (federation) layer 5/6/7 identity technology that 
certain critical security operations can now CONTROL the UI: 
presumably to ensure the trust path policy control is in 
effect.

On non-vista reference monitors, IE7 also provides a lower 
assurance version of the same path property. It allows 
HTML/javascript to control the webpage UI, specially. Here, 
something that looks like a "Popup" can be visualized by the 
browser engine instance, whose own rendering backgrounds the 
main page post its page-level rendering. This 
"backgrounding" prevents one from interacting with the 
details material (in any normal sense). Upon clicking the 
http(s) button link in the only party of the page that is 
not-backgrounded, end-user control is resumed - allowing one 
to interact with the page. This all represent a nice "secure 
signing device" in its own right, contrasting with earlier 
generations of plugin-based soft-signing devices. Whether 
the control release the UI based on the response from the 
server or not (e.g. a signed xml msg, or a new https 
sessionid value with a receipt-mac within), is a matter for 
further investigation.

Of course, "secure signing" device is a legal convention, 
not a technical security claim; it is that which merely 
satisfies the legal definitions in ESIGN. It embodies what 
lawyers require when addressing the obligation to ascertain 
the intent of the parties and their consumer consent, when 
using electronic signatures in important transactions 
requiring "writing protocols".

I don't see any choice. TLS Evidence has to become a work 
item. This is not to say I support the particular technical 
approach: but the initiative is appropriate, addressing with 
technical means both data retention (corporate wiretapping 
obligations) and the way in which regulated ESIGN sites are 
applying https and SSL in practice. 

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