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

[Martin Rex <martin.rex@xxxxxxx>]

Benjamin Black wrote:
> 
> i know approximately nothing of EU data protection requirements, but
> something about US and payment card industry data protection
> requirements.  if there is PII or payment instrument information in the
> "audit record" produced by this proposal, then that audit record must
> either be modified to eliminate or secure the PII/PI sections, defeating
> the purpose of the record, or it must be treated, in its entirety, as
> PII/PI.  that second option is particularly onerous.

Interesting!  So this problem may actually exist in the US as well,
albeit not as thorough as here.

So an application-level approach should not only standardize the
tagging of to-be-signed content, it should actually provide two
seperate tags resulting in two independent signatures, one
over all the data that ought to be authenticated during
processing of the transaction and one signature over only
the data that is to (and legally permitted to be) persisted.


Since some people are so keen on having the signature be
created in close vincinity of the TLS implementation:
this shouldn't be such a difficult problem.

In contrast to the TLS Evidence architecture, an app-level
approach is just fine with the communication/signalling
capabilities of the exiting software architecture.

possible Frontend-signing scheme at app-level:

client  -> TLS ->  page request            -> TLS  ---> server
client  <- TLS <-  FORM with sign-request <-  TLS  ---  server
client  -> TLS   (client requests signature)
client  <- TLS   (client receives signature)
client  -> TLS -> POST with signed reply  ->  TLS ---->  server

No backward signalling, reversing the message stream between
server and server-side TLS(-accellerator) necessary
(for triggering evidence start,end, retrieving result
 and evidence blob)


-Martin

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