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

From: Martin Rex <[email-masked]>
Date: Fri, 12 Jan 2007 00:47:18 +0100 (MET)

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: "Mark Brown" <[email-masked]>
Date: Thu, 11 Jan 2007 20:11:49 -0600

Martin,

Precautions as described in TLS Evidence 6.2 use security measures that
prevent accidental loss, alteration, and unauthorized disclosure or access.
They are strong enough to satisfy Visa's CISP.  There should be no problem.

If the business determines that it has a business reason to store the TLS
Evidence -- you would need that to justify buying the disk drives -- then
that business reason is the business's justifying need under the directive
you cite.

http://europa.eu.int/ISPO/legal/en/dataprot/directiv/directiv.html
SECTION VIII - CONFIDENTIALITY AND SECURITY OF PROCESSING
Article 17 Security of processing

"1. Member States shall provide that the controller must implement
appropriate technical and organizational measures to protect personal data
against accidental or unlawful destruction or accidental loss, alteration,
unauthorized disclosure or access, in particular where the processing
involves the transmission of data over a network, and against all other
unlawful forms of processing.
"Having regard to the state of the art and the cost of their implementation,
such measures shall ensure a level of security appropriate to the risks
represented by the processing and the nature of the data to be protected.

This directive makes it clear that it will hold organizations to the highest
standard of security measures in this case: "in particular where the
processing involves the transmission of data over a network."  But obviously
TLS session encryption satisfies this standard.  And obviously, persisting
the packets does not degrade the encryption.  So by persisting the packets,
you've satisfied the highest standard.

> albeit not as thorough as here.

In recent years Visa's CISP program became mandatory.  It is available here:

http://usa.visa.com/download/business/accepting_visa/ops_risk_management/cis
p_PCI_Data_Security_Standard.pdf

Page 4: "Requirement 3: Protect Stored Data
Encryption is the ultimate protection mechanism because even if someone
breaks through all other protection mechanisms and gains access to encrypted
data, they will not be able to read the data without further breaking the
encryption. This is an illustration of the defense in depth principle."

Visa's CISP clearly regards encryption (and good key management) highly,
since here "Encryption is the ultimate protection mechanism."  TLS
accomplishes all this excellently. 

--mark

---

From: Martin Rex <[email-masked]>
Date: Fri, 12 Jan 2007 14:56:23 +0100 (MET)

> Article 17 Security of processing

I can not really comment on the US aspect of this, but for the European,
and in particular for the German aspect, you are plain wrong.

Since you reference the EU data protection directive, you seem to
have entirely missed the much more important obligations from
Article 6 (b,c,d,e).

It is not up to the business to determine necessary data, and if
they process it (persisting counts as processing according to Art 2 b),
**they** have, among other things, to ensure accuracy of personal data,
and fix or delete when they learn about inaccuracy.

Although there is an clear and obvious business need for an ISP to memorize
the IP address to customer mapping for a flatrate DSL customer who is
online, the german court clearly declined that need after the customer
hangs up.  The courte issued an order to delete the record after hangup,
and they also prohibited the ISP from further collecting (let alone storing)
volume transfer data for the flatrate customer.  The court set out
a fine of 100000 Euro or 6 month in Jail for the CEO of the ISP for
further non-compliance.  This was about the data of ONE SINGLE CUSTOMER!
That ruling was upheld by the german supreme court.

As far as the blind raw communication capture approach by TLS Evidence
approach is concernd -- just "accidentally" include (entirely) unnecessary
and possible even incorrect data in the datastream and wait until the
business has persisted the TLS Evidence.  Then you can force the business
to either delete the unnecessary data or to fix or delete the incorrect
data in the persisted record.  The EU data protection directive doesn't
care whether fixing or deleting parts of the record invalidate a
digital signature.

-Martin