RE: [TLS] Please discuss: draft-housley-evidence-extns-00 - use to create integrity-assured metadata
"Kemp, David P." <DPKemp@missi.ncsc.mil> Thu, 11 January 2007 17:07 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H53Ox-00054K-9H; Thu, 11 Jan 2007 12:07:43 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H53Ow-000545-1I for tls@ietf.org; Thu, 11 Jan 2007 12:07:42 -0500
Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H53Ou-00049K-Ha for tls@ietf.org; Thu, 11 Jan 2007 12:07:42 -0500
Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id l0BH7dGs020973 for <tls@ietf.org>; Thu, 11 Jan 2007 12:07:39 -0500 (EST)
Received: from 144.51.60.34 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Thu, 11 Jan 2007 12:07:39 -0500
Received: from EXCH.missi.ncsc.mil ([144.51.60.19]) by gto.missi.ncsc.mil with Microsoft SMTPSVC(5.0.2195.6713); Thu, 11 Jan 2007 12:07:39 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 - use to create integrity-assured metadata
Date: Thu, 11 Jan 2007 12:07:42 -0500
Message-ID: <FA998122A677CF4390C1E291BFCF59890667755B@EXCH.missi.ncsc.mil>
In-Reply-To: <015c01c73596$2d61a910$6801a8c0@rps.local>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Please discuss: draft-housley-evidence-extns-00 - use to create integrity-assured metadata
Thread-Index: Acc1Gxlo7ZAOVkjhRMGHgHSy+keYrwADDp0QAB1epxA=
From: "Kemp, David P." <DPKemp@missi.ncsc.mil>
To: tls@ietf.org
X-OriginalArrivalTime: 11 Jan 2007 17:07:39.0187 (UTC) FILETIME=[FF8EC830:01C735A2]
X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-14928003
X-TM-AS-Result: : Yes--7.900100-0-31-1
X-TM-AS-Category-Info: : 31:0.000000
X-TM-AS-MatchedID: : 147018-150567-110462-702054-703468-709415-105040-701297-701741-701749-704645-703964-707225-701542-700955-121628-106470-700478-702388-703875-702126-702726-703585-701455-710742-704977-139010-702071-704921-700842-707289-700454-702643-121155-702358-105700-708792-705092-711232-704195-113228-709170-700865-706110-700726-702260-704407-703712-704461-701461-703907-700057-702898-701914-702895-148050-20040
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
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
> > [Dave] The purpose of the proposal is to explore options to > > allow certificate-enabled clients to provide broadcast > > (1-to-many) persistent authentication without having to > > install SOA (WS-*) or other signing-capable plugins on > > the client. It may or may not be architecturally a better > > choice to do signing through Web Services vs. TLS. But > > while you're crying crocodile tears over TLS's > > "reputation" should it ever gain the ability to do > > digital signatures, save a few for Vista and digital IDs. > > > > Consumer-to-provider authentication (as opposed to > > consumer-to-provider's-TLS-accelerator) is needed, > > has both benefits and the abuse potential you are > > worried about, and is happening regardless of whether > > TLS is extended. > > [Peter] This is a fascinating interpretation of the purpose of the > work item. So, lets explore it. I had personally NOT got ANY > of this from the doc/author-disclosures , so far. I got it from Page 12 of the I-D: For example, a client may request access to a resource provided by the server, provide sufficient authentication and authorization information grounds to convince the server to grant the requested access, and receive an affirmative response from the server. A record of TLS Handshake protocol messages representing this example may provide a sufficient record of the intent of both the client and the server. I loathe the use of "intent of the client" here because it smacks of NR and lawyers and judges. But if the client generates a request for a particular resource, then the provider of the resource can assume from the mere existence of a request that the client "intends" to perform some function (such as GET) on that resource. The motivation is separation between outward-facing interfaces contained in a DMZ and back-end transaction processors separated from the DMZ by a high assurance content-validating proxy. I'd much rather see "TLS Evidence" called "Authenticated Stream-to-Transaction Conversion" since that is my motivating scenario, but I don't speak for the authors. The "evidence" in this case is not intended to be used by courts or snoopy governments, it is intended for a transaction processor that receives a request and needs to authenticate the original requestor directly rather than accepting the word of a hackable front end contained in a DMZ. "Broadcast" authentication doesn't mean that there are necessarily many recipients of a specific request (although there could be, for load sharing), just that the requestor has no need to know anything (including certificate info) about the provider back-end in order to enable the back end to authenticate the requestor. It's just another way to express the difference between persistent and session-oriented data authentication. Dave _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls
- Re: [TLS] Please discuss: draft-housley-evidence-… home_pw
- RE: [TLS] Please discuss: draft-housley-evidence-… Mark Brown
- Re: [TLS] Please discuss: draft-housley-evidence-… Martin Rex
- Re: [TLS] Please discuss: draft-housley-evidence-… home_pw
- RE: [TLS] Please discuss: draft-housley-evidence-… Kemp, David P.
- RE: [TLS] Please discuss: draft-housley-evidence-… Mark Brown
- Re: [TLS] Please discuss: draft-housley-evidence-… Martin Rex
- RE: [TLS] Please discuss: draft-housley-evidence-… Stefan Santesson
- Re: [TLS] Please discuss: draft-housley-evidence-… home_pw
- Re: [TLS] Please discuss: draft-housley-evidence-… Martin Rex
- Re: [TLS] Please discuss: draft-housley-evidence-… home_pw
- Re: [TLS] Please discuss: draft-housley-evidence-… Martin Rex
- RE: [TLS] Please discuss: draft-housley-evidence-… Kemp, David P.
- Re: [TLS] Please discuss: draft-housley-evidence-… home_pw
- Re: [TLS] Please discuss: draft-housley-evidence-… Martin Rex
- Re: [TLS] Please discuss: draft-housley-evidence-… Martin Rex
- RE: [TLS] Please discuss: draft-housley-evidence-… Mark Brown
- Re: [TLS] Please discuss: draft-housley-evidence-… Martin Rex
- Re: [TLS] Please discuss: draft-housley-evidence-… Martin Rex
- Re: [TLS] Please discuss: draft-housley-evidence-… Martin Rex
- Re: [TLS] Please discuss: draft-housley-evidence-… Nelson B Bolyard
- Re: [TLS] Please discuss: draft-housley-evidence-… Peter Gutmann
- Re: [TLS] Please discuss: draft-housley-evidence-… Omirjan Batyrbaev
- Re: [TLS] Please discuss: draft-housley-evidence-… Peter Gutmann
- Re: [TLS] Please discuss: draft-housley-evidence-… Steven M. Bellovin
- Re: [TLS] Please discuss: draft-housley-evidence-… home_pw
- Re: [TLS] Please discuss: draft-housley-evidence-… home_pw
- Re: [TLS] Please discuss: draft-housley-evidence-… Russ Housley
- Re: [TLS] Please discuss: draft-housley-evidence-… home_pw
- Re: [TLS] Please discuss: draft-housley-evidence-… Martin Rex
- Re: [TLS] Please discuss: draft-housley-evidence-… Martin Rex
- Re: [TLS] Please discuss: draft-housley-evidence-… Martin Rex
- Re: [TLS] Please discuss: draft-housley-evidence-… home_pw
- Re: [TLS] Please discuss: draft-housley-evidence-… Martin Rex
- Re: [TLS] Please discuss: draft-housley-evidence-… Martin Rex
- Re: [TLS] Please discuss: draft-housley-evidence-… Russ Housley
- RE: [TLS] Please discuss: draft-housley-evidence-… Peter Williams
- RE: [TLS] Please discuss: draft-housley-evidence-… Kemp, David P.
- Re: [TLS] Please discuss: draft-housley-evidence-… Peter Gutmann
- Re: [TLS] Please discuss: draft-housley-evidence-… Martin Rex
- RE: [TLS] Please discuss: draft-housley-evidence-… Peter Williams
- Re: [TLS] Please discuss: draft-housley-evidence-… Russ Housley
- RE: [TLS] Please discuss: draft-housley-evidence-… Peter Williams
- RE: [TLS] Please discuss: draft-housley-evidence-… Kemp, David P.