RE: [TLS] Please discuss: draft-housley-evidence-extns-00 - use to create integrity-assured metadata

["Kemp, David P." <DPKemp@xxxxxxxxxxxxxx>]

> > [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@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls