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

[Martin Rex <[e-mail]>]

Mark Brown wrote:
> 
> Obviously the choice to share data should be made in light of legal and
> moral obligations stemming from the data contents.  TLS Evidence is content
> agnostic.  But for the case of integrity-assured data/metadata, perhaps it
> is useful to transmit and share TLS Evidence in addition to persisting it as
> an audit trail.  So far we've really only talked about the audit trail uses
> (and potential abuses) of TLS Evidence where (presumably) very few should
> read it.
> 
> For example, if any of the final recipients are not attached via trusted
> connection to the TLS server (for example, if any of the recipients are not
> on the box with the TLS server, or if you just can't trust the connection
> for some other reason), those recipients might benefit from integrity
> assurance / proof of origin for the data/metadata that was received.  This
> may be relevant to the TLS accelerator scenario David mentions.  In that
> case an app may feel a little queasy about the client's identity since the
> app never gets let in on -- and has no recourse to -- the client
> authentication process.

Now I'm slighlty confused about how that should work.

As you said, TLS Evidence is content agnostic, and covers the raw
datastream plus the TLS handshake.

What the application is going to receive is only a fraction of
the stuff that was signed and various middleware layers in between
will have likely aggregated, reformatted, canonicalized, modified,
stripped protocol layers and converted to local character set
before the application gets its hands on the request data.

So in general, even if the application jumps hoops to retrieve
the raw TLS evidence, it can only perform a consistency check
on the opaque blob checking the signature, it will usually have
zero chance to verify that the request it has received through
the regular protocol stack really matches to what is scattered
somewhere with in the opaque TLS Evidence blob.

-Martin

_______________________________________________
TLS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls