One last comment and then I'll leave this alone; Apologies, too, for chiming in 
late, but I was away last week...



Robin Wilton

Technical Outreach Director - Identity and Privacy

On 2 Nov 2016, at 15:58, "Jeremy Rowley" <[email protected]> wrote:

> Here's what we are dealing with on this front:
> 
> The EU has a right to be forgotten which requires a data controller to remove 
> data that  is no longer necessary or irrelevant for the original purposes for 
> which the data was collected. Primarily, courts have interpreted this as 
> requiring a search engine to remove information about a person at that 
> individual’s request. This has caused consider headaches for Google. 

There's a long-standing privacy principle that data should not be retained for 
longer than is necessary for the purpose for which it was collected*. The 
simplest defence against possible "wacky" court decisions is for CT operators 
to be transparent about what they are logging, why, and how long they expect 
the data to be needed for. If you say "we collect this data in order to produce 
an audit trail of CA activity, and because the data is of most use 
retrospectively we expect to need to keep it for [n] years", you establish a 
clear baseline during which, in the absence of any other specific privacy 
harms, your legitimate default position can be to retain the data.

It does, however, imply that a log owner should have a process for deleting log 
data at the end of that n-year period.  The good news is that CT log data, by 
its very nature, is already conveniently time-stamped, batched, etc., so 
managing its expiry should not require any changes to the data schema itself.

(Very few data controllers put this into practice, regrettably, but that's a 
whole other rant).

Yrs.,
Robin


> 
> CT monitors are likely considered a search engine that identify certificates 
> with personal information included. However, CT, by design, cannot delete 
> information from logs and any deletion will cause the log to fail. This puts 
> CT at odds with EU privacy laws as certificate subjects often contain 
> individual information, email addresses specified in the SANs, and SANS DNS 
> entries that identify an individual (albeit this is a stretch). 
> 
> I'm having trouble reconciling how a monitoring service/log operator is 
> supposed to comply with the EU requirements without supporting redaction. 
> 
> Jeremy
> 
> 
> -----Original Message-----
> From: Trans [mailto:[email protected]] On Behalf Of Stephen Farrell
> Sent: Monday, October 31, 2016 4:03 PM
> To: Peter Bowen <[email protected]>; Melinda Shore <[email protected]>
> Cc: [email protected]
> Subject: Re: [Trans] Topicality
> 
> 
> Peter,
> 
> On 31/10/16 19:01, Peter Bowen wrote:
>> On Mon, Oct 24, 2016 at 9:37 PM, Melinda Shore <[email protected]> 
>> wrote:
>>> You may have seen the recent announcement from the Chrome team that 
>>> as of October 2017 certificates will need to comply with Chrome's CT 
>>> policy in order to be trusted.  There was also an invitation to 
>>> discuss that on the trans mailing list.
>>> This is a reminder that mailing list discussions need to remain 
>>> focused on the specifications being produced by the working group - 
>>> that is to say, policies related to individual implementations are 
>>> out of scope for the working group except to the extent that they 
>>> bear on decisions related to our working group drafts.
>> 
>> Paul and Melinda,
>> 
>> Do you consider discussion of use cases for privacy to be in-scope for 
>> this group or do you consider only the technical implementation of 
>> privacy (e.g. section 4 of 6962-bis and the redaction draft) to be 
>> in-scope?
> 
> (Wearing no IETF hat, but perhaps the hat of someone interested in privacy...)
> 
> I do not believe that it makes sense for us to talk as if privacy was a 
> concept that applies to corporate entities.
> 
> I do believe that your text above conflates privacy (a human
> concept) with corporate secrecy (a useful but different thing) in ways that 
> are in the end damaging to both. (I further and even moreso believe that such 
> conflation would be damaging to the IETF were we to slip into the bad 
> practice of not calling out that terminological sloppiness.)
> 
> I totally get that redaction has utility for folks who need corporate secrecy 
> on a temporary basis. I absolutely do not accept that that has any privacy 
> aspect.
> 
> Can you call out the privacy aspect that applies to humans and that is a real 
> part of the question related to support for redaction in CT?
> 
> Thanks,
> S.
> 
> 
>> 
>> Thanks,
>> Peter
>> 
>> _______________________________________________
>> Trans mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/trans
>> 
> 
> _______________________________________________
> Trans mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/trans

_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans

Reply via email to