RE: [TLS] Please discuss: draft-housley-evidence-extns-00 (resend)
Ari Medvinsky <arimed@windows.microsoft.com> Wed, 20 December 2006 18:00 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx5k7-0007hI-4C; Wed, 20 Dec 2006 13:00:39 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx5k5-0007gx-Eo for tls@ietf.org; Wed, 20 Dec 2006 13:00:37 -0500
Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx5k2-0002eJ-VB for tls@ietf.org; Wed, 20 Dec 2006 13:00:37 -0500
Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 20 Dec 2006 10:00:34 -0800
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) with Microsoft SMTP Server id 8.0.685.24; Wed, 20 Dec 2006 10:00:33 -0800
Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2825); Wed, 20 Dec 2006 10:00:33 -0800
x-mimeole: Produced By Microsoft Exchange V6.5
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 (resend)
Date: Wed, 20 Dec 2006 10:00:32 -0800
Message-ID: <802A881C87166D4597F9EEFC3F04F4F80347EB77@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <009201c7245b$192dbc00$6801a8c0@rps.local>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Please discuss: draft-housley-evidence-extns-00 (resend)
Thread-Index: Accjr+HsSWE6R2eZR0SIMuOXIpaeHwAAn9+gACTeRuAAAMk8IAAEMZKwAAGX1QA=
References: <009201c7245b$192dbc00$6801a8c0@rps.local>
From: Ari Medvinsky <arimed@windows.microsoft.com>
To: Mark Brown <mark@redphonesecurity.com>, tls@ietf.org
X-OriginalArrivalTime: 20 Dec 2006 18:00:33.0959 (UTC) FILETIME=[BEC80B70:01C72460]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f
Cc:
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org
I agree with Stefan. In general I see a lot of potential for signature support in TLS for commerce, non-repudiation and secure audit scenarios. The term evidence brings in a legal discussion that clearly does not belong here. Ari Medvinsky Sr. Program Manager Windows Security -----Original Message----- From: Mark Brown [mailto:mark@redphonesecurity.com] Sent: Wednesday, December 20, 2006 9:20 AM To: tls@ietf.org Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 (resend) Stefan, (resend, to tls@ietf.org, with additions to the first paragraph) Thanks for your helpful comments. I don't agree entirely with you, specifically your position that signatures are (must be?) application level constructs, but you're probably in the majority on this issue. My opinion is based on personal experience though. I am working on a router project that uses TLS Evidence and Authorizations at the TLS level only: http://www.navysbir.com/06_1/215.htm The router works below the application-level and aims at high assurance under Common Criteria, e.g. EAL6. Its design and implementation has been and will continue to be carefully scrutinized. This project does not depend on "signer's intent" though, and perhaps intent is what you locate at the application level? I think you're right about this: the wisest choice may be to wait and see how things pan out in the legal community, and not try to extract a final answer from them too soon. Would the TLS WG be willing to extend the charter for evidence even if a large part of the discussion was hosted by a lawyer community and could take some time to hash out? For those of you who are interested in the legal aspect of "evidence", I am currently engaged in conversation with the American Bar Association's Information Security Committee listserv. If you would like to enter that discussion, please let me know. The ABA ISC discussion has recently rehashed the use of the term "evidence" with respect to TLS Evidence. To summarize that discussion as fairly as I can, I think as long as one spells evidence with a lowercase "e" and not as Evidence or EVIDENCE the lawyers on the ISC listserv are comfortable with the term. I also plan to work closely with the ABA Digital Evidence Project over the next year as well, and my first project with DEP is to hash out terms together. The following is a snippet -- really, a teaser -- for those of you with some inclination to join the ABA ISC group: (mark) > The TLS definition of "evidence" is unstated to allow it to flex with the > prevailing > definition in the legal world (this decade's definition or the next's). > > You say the definition of evidence is anything that can be "thrown into > the > pot", which seems reasonable to me. > (Steven Teppler) > > First, what is unknown is the definition of "evidence" as the technical > > protocol means it. In the legal world, anything can be, and usually > > thrown > > into the pot as, evidence. How is this specie of evidence different > from > > other evidence? > (mark) > TLS Evidence does not claim some special privilege e.g. being > non-repudiable. It's just evidence like everything else in the pot. The > specter of duress is never eliminated, for example. How could it be? > Neither does TLS Evidence claim any special privileges to magically gain > affirmatives to any of the following: > (Steven Teppler) > > Is EG'd evidence automatically admissible? Does it > > automatically exclude contradictory digital data or testimony? Does it > > generate enough evidence to survive a summary judgment motion? Does it > > satisfy a burden of production? Burden of persuasion? If so, why isn't > > some modifier, such as "trusted evidence" or "summary judgment > eliminator" > > used? > (mark) > No thank you! If a court chose to admit TLS Evidence into a trial then > that > court could examine it as a record like anything else. The TLS Evidence > draft standard _only_ defines a minimum technical standard for security > measures including cryptographic/equality tests which must be passed > before TLS Evidence is "born". Best regards, mark _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls
- RE: [TLS] Please discuss: draft-housley-evidence-… Mark Brown
- RE: [TLS] Please discuss: draft-housley-evidence-… Peter Williams
- RE: [TLS] Please discuss: draft-housley-evidence-… Ari Medvinsky
- RE: [TLS] Please discuss: draft-housley-evidence-… Peter Williams
- RE: [TLS] Please discuss: draft-housley-evidence-… Mark Brown
- RE: [TLS] Please discuss: draft-housley-evidence-… Stefan Santesson
- RE: [TLS] Please discuss: draft-housley-evidence-… Peter Williams
- RE: [TLS] Please discuss: draft-housley-evidence-… Kemp, David P.