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

Martin Rex <martin.rex@sap.com> Thu, 11 January 2007 20:43 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H56lX-0003Nv-EC; Thu, 11 Jan 2007 15:43:15 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H56lV-0003Nq-Mt for tls@ietf.org; Thu, 11 Jan 2007 15:43:13 -0500
Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H56lU-0006pr-6V for tls@ietf.org; Thu, 11 Jan 2007 15:43:13 -0500
Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id VAA22555; Thu, 11 Jan 2007 21:43:01 +0100 (MEZ)
From: Martin Rex <martin.rex@sap.com>
Message-Id: <200701112043.VAA02623@uw1048.wdf.sap.corp>
Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00<
To: stefans@microsoft.com
Date: Thu, 11 Jan 2007 21:43:02 +0100
In-Reply-To: <A15AC0FBACD3464E95961F7C0BCD1FF01D6E0EAA@EA-EXMSG-C307.europe.corp.microsoft.com> from "Stefan Santesson" at Jan 11, 7 06:33:08 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
X-SAP: out
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: martin.rex@sap.com
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

Stefan Santesson wrote:
> 
> Could you elaborate in what ways this would be incompatible with
> the EU data protection directive?

I already gave two examples.  I need to point out that the EU directive
is a framework with some wiggle room for national governments in making
laws that are being used in court.  I'm familiar only with the German
incarnation of the data protection directive.

I actually used the wrong URL last time (the telecommunications subset)
the data protection act appears to be this one:

http://europa.eu.int/ISPO/legal/en/dataprot/directiv/directiv.html

>
> I went over this with one of the leading Lawyers in Sweden on
> electronic signature implementations within the EU directives
> and we could not identify any significant problems.

I'll try to give you some guidance, but IANAL.  I draw my conclusions
from (German) court decisions, mainly those that were decided by
appeals or supreme court.

See definitions for "personal data" (Art 2a), "processing" (Art 2b), etc.

The problems arise from the fact that by signing the raw communication
data, the business is almost always going to "capture" information
that is unnecessary for the intended (business) purpose (see Art 6 a,b,c)
and quite possibly information which the business doesn't know ahead of time,
however a business is required to obtain a **VOLUNTARY** explicit and
individual consent agreement listing the exact information that is to be
processed, exact purpose of processing

While some specific data might be vital for a business purpose or
transaction, a blanket capture at the network level is very likely
to result in capturing of unnecessary data.  Removing the unnecessary
data after the capture might likely be difficult, because it will
invalidate the digital signatures on the rest (and once they're
invalid, it turns out it was a real waste to create them in the first
place).

The data protection directive requires the business to take efforts
to not collect unecessary data (Art. 2 a,b,c) in the first place,
and to delete every piece of information when it is no longer
necessary.  A broken protocol design that makes vital information
inseperable from unnecessary or no longer necessary information
(because of a digital signature that would be no longer verifiable)
is no valid excuse for not deleting it.

E.g. there is no necessity to persist a User-Agent: or HTTP-Refer:
from a HTTP GET request, so if that information is not deleted
when the online session ends, it is a violation of the data
protection directive.

As I mentioned before, the German supreme court made a final decision
about 2 months ago that it is(was) illegal to keep a record of the
equivalent of a DHCP-Lease for an internet DSL-flatrate customer
(IP+customer+start-time+end-time) after the customer hangs up.
(and the only reason why (only) phone companies will be able to keep
 this record in the future is a recently enacted legislation,
 but that is about very specific information and network/phone
 operators and providers only).

I expect there will be a lot of gobbledigoo in an TLS Evidence
capture which MUST be deleted when the session ends.  

Even if the business is able to obtain the purely volutary,
and formally correct consent agreement from his customer
for keeping all gorily detailed unnecessary information,
not providing a capability to delete the unnecessary data
upon request would amount to a violation of the data
protection act. 

Want to put a TLS Evidence persising business out of business?
Sign up, purchase, check your http-watch what crap they captured
which they aren't entitled to.  It wouldn't be suprising if
they actually failed to obtain a valid consent agreement.
But even if they do ...  wait 2 weeks, request a detailed
status report of what data they (admit to) store (Art 12),
revoke consent for all unnecessary data, go to court and
they'll likely have to massively purge "TLS evidence"
and/or junk their software or go out of business.


Btw. if a business fails to list a piece of information that it
intends to process or an intended purpose in the consent agreement,
then the content agreement will be invalid in its entirety!


> 
> He could see no problem with recording data during a session and
> save it as an audit record. Signed or not.
>
> If there would be an issue (due to collection of personal data
> from the certificate etc), it could be solved by an agreement
> between the customer and the merchant or alternatively between
> the certificate holder and the CA.

No, that will be generally insufficient.

Other than what is common abusive practice in the US, the courts
here in Germany are _dead_serious_ about (a) businesses avoiding
to collect unecessary data, (b) consent agreements being accurate
about the exact information and purpose, (c) every piece of
information being deleted when it is no longer necessary
(and not when it seems fit) and (d) the consent agreement being
purely voluntary (no pressure of any kind) and revokable at any time.

Consumer protection associations will be able to get cease-and-desist
orders against companies persisting TLS Evidence that includes unnecessary
data or data for which no valid consent agreement is obtained or where
they do not or can not delete unnecessary data.


-Martin

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