Subject: Re: [Trans] Topicality

From: Stephen Farrell <[email-masked]>
Date: Tue, 1 Nov 2016 10:11:14 +0000

On 01/11/16 03:34, Peter Bowen wrote:
> On Mon, Oct 31, 2016 at 6:33 PM, Stephen Farrell
> <[email-masked]> wrote:
>> On 01/11/16 01:04, Peter Bowen wrote:
>>> On Mon, Oct 31, 2016 at 3:02 PM, Stephen Farrell <[email-masked]> wrote:
>>>>
>>>> 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?
>>>
>>> There are
>>
>> "Are" or "could be"?
>>
>> Serious question. The (non)existence of those in 6962 logs
>> seems to me to be a) highly pertinent and b) demonstrable.
> 
> I'm not sure how you get that these don't exist.  Using the given name
> and surname attribute types as indications of PII, and removing one
> issuer's apparently confusion between surname and serial number, I see
> thousands.  A few examples:
> 
> https://crt.sh/?id=9031476
> https://crt.sh/?id=8997821
> https://crt.sh/?id=45107003
> https://crt.sh/?id=31130948

Thanks. I'd be interested if there's a way to count
how many logged certs have givenName, surname or
similar attributes. Anyone with better log-foo know?

> 
>>> certificates that have personal information (e.g. given
>>> name, surname, and physical location) in the subject distinguished
>>> name or the subject alternative names.
>>
>> I can well imagine certs for web servers with some PII
>> embedded for no good reason. "Don't do that by accident"
>> would be as good a bit of advice as we could offer in
>> CT I think as it's really much more an issue for acme
>> in terms of current IETF work. (Or at least arguably.)
> 
> I wouldn't call this by accident.  Microsoft's root program
> requirements (http://social.technet.microsoft.com/wiki/contents/articles/31633.microsoft-trusted-root-program-requirements.aspx)
> explicitly call out Individual Validation (IV) is section 4(a)(15).
> IV, by definition, puts Personal Information in the subject of the
> certificate.

Again, do we have a count of how many of those (IV certs)
are logged?

> 
>>> It is very possible that there
>>> may be a desire to redact this information (in fact it could even be
>>> required in some jurisdictions as CT could be considered a database).
>>
>> The above has "possible," "may be a desire," "could even
>> be" and "could be considered" all in one sentence. That
>> is not a template for a winning argument is it? :-)
> 
> I'm not a lawyer, so I'm not going to make any legal conclusions.  

I wasn't making a legal point:-)

> So
> I'm going to continue to qualify anything related to legislation that
> may exist in certain jurisdictions in which CT logs may exist.  Yes,
> that is heavily caveated again, so feel free to ignore, but it is a
> real concern.
> 
>>> We already see this with domains in many countries where the full
>>> registrant details are not publicly available.
>>
>> DNS registration policies are not in scope here though.
> 
> I wasn't suggesting that they were.  I was using it to demonstrate a
> related case where it was judged that restriction of information was
> beneficial.
> 
>>>
>>> Additionally, while 6962-bis does focus on certificates used for TLS
>>> server authentication, there are other types of certificates that
>>> could be logged.
>>
>> How many have been logged? Serious question. If there is a
>> real problem here, I'm interested. If there is not, then I,
>> for one, am not. Finding the evidence either way should not
>> be hard.
> 
> Why does it matter how many have currently been logged?  Isn't the
> point of this WG to create tech spec for a certificate log that can
> log any kind of certificate?  Is it possible emailProtection certs
> aren't being logged because of privacy concerns?

It is entirely possible. Or it could be that those aren't
being logged for other reasons.

My main point is that it would be an error to conflate
(a) requirements for privacy with (b) requirements for
corporate secrecy. Those need to be discussed separately
as the issues are quite different. And while it is perhaps
possible that one technical approach might exist to address
both sets of issues, that would surprise me, given that
the requirements for (a) and (b) differ so much.

S.

> Thanks,
> Peter

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 1 Nov 2016 10:21:43 +0000

On 01/11/16 03:38, Ryan Sleevi wrote:
> On Mon, Oct 31, 2016 at 7:45 PM, Stephen Farrell
>> No, that's an empirical question, to rephrase it: Show me the
>> certs:-)
>>
>> Really, it is a serious question when considering the difference
>> between corporate secrecy and privacy. I totally accept that there
>> are issues with the former (e.g. with <newproduct>.example.com)
>> but I'd like to see evidence if someone claims that the latter
>> is an issue. ("The latter" being the privacy of humans, not the
>> secrecy of organisations.)
> 
> "Show me the certs with PII" is a somewhat problematic stance, isn't
> it? 

I guess it might sound like it yeah:-) But see my mail to
Peter, a count of those with likely-sensitive attributes
would be a good start.

> To what end will it help you or the community evaluate? 

It'd help evaluate the seriousness of the potential privacy
issue with current logging. My sense going in was that this
(inclusion of PII in certs in logs) wasn't too big a deal,
but I could well be wrong.

> I'm not
> sure I accept at all your line of questioning, so perhaps, before
> needlessly dropping PII, you can suggest how that would change your
> response, if at all.

I am quite interested in discussing privacy issues if they
exist here. (I don't however accept that corporate secrecy
is a privacy issue.)

> 
>>> - and what clients are logging? These
>>> certs definitely exist - but the combination of client behavior and log
>>> policies have, so far, prevented them from being logged, and only
>>> incidentally so.
>>
>> I don't follow that, can you elaborate?
> 
> The extant logs all generally have policies that restrict the roots
> from which they log, or even more narrowly, restrict the purposes for
> certs which they log.
> 
> Similarly, the majority of log clients - those submitting to logs -
> restrict what they log to a subset of what they see. Similarly, these
> log clients only see particular types of certs, rather than the
> broader corpus out there.
> 
> For concrete example: It's certainly be technically possible that
> Google could decide to log every S/MIME certificate it saw. But would
> it be wise? Of course not.

Agreed.

> 
>> The WG charter calls out web site cert misissuance as thing#1
>> and http/tls as the same (in the deliverable bit).
>>
>> Acme relates as follows: if there are certs containing PII,
>> instead of trying to handle those via redaction during the
>> act of CT logging, one could recommend not including the PII
>> in the certs. (It is arguable that that is a sufficient
>> answer, but nonetheless it could be argued to be one, in the
>> context of the IETF.)
> 
> Of course, that doesn't address the issue pointed out earlier by Peter
> - that certificates are in use for more than just TLS, and issued by
> means more than ACME.
> 
> It sounds like your suggestion is only certs issued by ACME should be
> logged via CT. Naturally, I reject that conclusion.

No that was not my suggestion at all.

> You're directly proposing policy solutions, right now ("Don't log"),
> and rejecting even exploring or entertaining the technical discussion.
> Is that intentional, or simply a misunderstanding?

That's a wild misinterpretation of what I said. If you can
point to where I "rejected even exploring" anything then I'd
be very happy to retract that.

> 
>>> Are you suggesting that CT does not need to be aware of what is possible,
>>> either through other WGs actions (such as NSEC/NSEC3) or through other
>>> bodies, such as IANA/ICANN?
>>
>> I've no clue what the above means, sorry.
>>
>> Guessing though, as to what might constitute an answer: I do
>> not think that CT needs to try to address problematic things
>> like ICANN registrar policies that call for PII to be generally
>> visible. To the extent one has a problem with that, (and I do
>> as it happens) the trans WG is the wrong venue, was my point.
> 
> I'm suggesting that CT needs to at least be aware of other privacy
> preserving efforts - such as NSEC3 or DPRIVE - and as such, cannot
> unconditionally say "Don't do that", when other IETF technologies
> support "do that" - at least, not without a reasonable discussion of
> why. 

I'm entirely fine with discussion of privacy as it relates
to CT, and would be glad to see that. My main point is that
privacy is entirely different from corporate secrecy, and
conflating the two would be an error.

> I don't believe you've posed why, other than you don't like it,
> or don't feel the use case exists, but if that's the level of
> discussion, then I fear we will make no progress, especially given
> that even the original message contained such evidence. My hope was
> that here in the IETF we could try to find solutions for problems, and
> only punt them when we believe they are better served elsewhere - but
> I feel like your line of reasoning is to try to punt anything you
> don't like.

Every time you tell me what you feel I think, you go wrong.
Maybe concentrating on what I say will be more useful?

> 
>>> It so, can you articulate what you view as the appropriate scope of
>>> function and discussion here? I mean that as an honest question.
>>
>> As with the above, I'm too confused to answer. (And figure
>> there's some underlying miscommunication going on here.)
> 
> Are the only certificates CT cares about TLS server certificates?

No. Those are the most important use-case for now though.

I do also think we need to be careful to not try to e.g.
re-design e2e secure interpersonal messaging based on CT. While
getting better e2e secure interpersonal messaging would be
a fine thing, there is much more to that than considering
CT.

So going beyond the well understood use-cases has a number
of risks.

> 
> If not, then you already have ample evidence in the form of S/MIME
> certificates, or in digital signature certificates, that privacy is an
> aspect of the discussion.
> If you don't agree with that, let's find out why.
> If you do, then can we accept there's a privacy argument, and not just
> a corporate secrecy requirement, and move on to the technological
> discussion?

To reiterate: I'm very happy if we discuss privacy so long
as we do not conflate that with corporate secrecy. There are
requirements for both, but they are far from the same.

S.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 1 Nov 2016 16:48:52 +0530

> On Nov 1, 2016, at 00:31, Peter Bowen <[email-masked]> wrote:
> 
> 
> 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?

Yes that is in scope.

What we want to avoid is talking about specific vendors' use and local policy.

Technical discussions are in scope, especially if it relates to RFCs or drafts or new ideas for potential new work.

Paul
> 
> Thanks,
> Peter
> 
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 1 Nov 2016 04:21:19 -0700

> exist here. (I don't however accept that corporate secrecy

I don't see how, within a certificate, you can draw that line.

We know people are deploying DNS names with PII (the U.K. tax offices
naming scheme, for example, uses tax identifiers as subdomains). We know
CAs are deploying subject naming information in certificates, and these are
issued to natural persons. givenName and Surname are an example, but as
Peter points out, CAs are issuing certificates for individuals (IV), and
these are permitted to put the PII in the O field.

I appreciate the "data needed" viewpoint, but I don't agree with using the
extant logs to justify that viewpoint, especially when you consider what
the extant logs are presently logging, and what's desired to be logged.

I can appreciate you see a difference between corporate secrecy vs personal
privacy - but perhaps you could articulate how that codifies into
certificates being issued, or its technical relevance. I can understand
that playing into discussions about which to punt on, but I don't feel
you've done a good job articulating why you feel this distinction is
relevant, or what end it serves, given the context of certificates.

> conflating the two would be an error.

Can you suggest a meaningful distinction between these two, as expressed in
certificates?

> of risks.

Can you expand on what you see as well-understood? I thought both IV certs
and QCP certs were well understood, at least within the context of the Web
PKI.

> requirements for both, but they are far from the same.

Can we infer that you're happy to discuss corporate secrecy as well? Could
you expand on why you see these requirements as different?

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 1 Nov 2016 12:13:42 +0000

Hiya,

> I don't see how, within a certificate, you can draw that line.

That's a fair question. I'm not sure I can draw a clean
distinction, but then again the same is true e.g. wrt
source IP addresses sometimes being (considered by
some courts as) PII and sometimes not.

We can however distinguish the <newproduct>.example.com
use-case for corporate secrecy - in that case, there is
mostly a need for secrecy only until the web site is
launched.

And that does differ from inclusion of non-changing PII
(such as givenName) in DNs. To the extent there are any
privacy issues with including a givenName, those issues
don't go away in a few weeks.

I'm less clear myself on the real need for keeping
some hostnames secret forever but yet have the certs
for those publicly logged. It may be that the better
approach to that is to make clear that semantically
meaningful hostnames in certs inevitably exposes
those semantics, leading to a "dr. dr. it hurts when
I do this" answer.

> naming scheme, for example, uses tax identifiers as subdomains). 

I'd say that's a fairly clear example of a not-great
design, once CT (or passive DNS) is considered. I
don't have a strong position as to what the WG ought
do about that, if anything.

> We know

Are those all used for TLS client auth or in applications
above TCP or TLS? It sounds like it'd be a fine thing if
someone was motivated to describe the cases like that that
have been seen in current logs, as well as cases where the
inclusion of such information in certs is known but those
are not ending up in logs.

Absent that description, I'm not sure we can see what changes
or additions the WG might develop. (Note: I'm not asking
that such descriptive material be in an I-D or RFC.)

I'd also comment that it may be the case that some CA
practices that seemed ok before CT, might no longer seem
like such a good idea now. And that's ok - I think that's
just showing some evolution towards a better PKI. We do
of course need to try not break things as we go but I
don't think that just because one of the O(100) CAs in
the world has been doing X necessarily means that X has
to be catered for via changes to CT.

> the extant logs are presently logging, and what's desired to be logged.

I don't understand the above.

> relevant, or what end it serves, given the context of certificates.

The distinction is relevant in that methods to protect
corporate secrecy might or might not assist with personal
privacy.

> Can you suggest a meaningful distinction between these two, as expressed in

I think the distinction is that privacy relates to people,
whereas corporate secrecy does not, one is trying to protect
some corporate asset. As I said above I don't claim to have
a crisp way to distinguish those "as expressed in X.509."

That might emerge though from discussion, not sure.

> and QCP certs were well understood, at least within the context of the Web

I don't get the question sorry. What I'm saying is that
we need to be careful e.g. when discussing how CT might
relate to better interpersonal messaging. That doesn't
mean that we shouldn't discuss such things, but we ought
not think that changes to CT will somehow make better e2e
email happen - that'd be a cart before the horse kind of
thing.

> Can we infer that you're happy to discuss corporate secrecy as well? 

Of course.

> Could

See above wrt the duration for which protection is needed
issue for one well known use case for corporate secrecy.

In terms of privacy, I think there's a difference in that
the use of certs that might contain PII may be such that
equivalent (but not necessarily bitwise identical) PII is
inevitably exposed (say in mail header fields) to the point
where there's no good reason to try hide the version of
that information that's visible in a CT log.

I think it is also the case that there will be cases where
the best way to protect PII is to say "putting that in a
cert is not best practice as it'll show up in CT logs." That
may well conflict with some existing CA practices, which is
something that warrants discussion. Note I'm not saying
that "omit PII" is "the one true answer" but it might be
the best we can do in some cases.

There is also a danger if we allow redaction to be posed as
a solution for long-term exposure of PII - the danger being
that that might allow forms of mississuance to re-emerge
whilst not actually protecting privacy. (If redaction is
posed as a privacy protection, then in principle one has
to be able to redact nearly any field in X.509, which is
a danger for the effectiveness of CT I think.) I think
that danger is itself a sufficient reason to distinguish
carefully between privacy and corporate secrecy in CT
discussions.

S.

---

From: Jeremy Rowley <[email-masked]>
Date: Wed, 2 Nov 2016 15:57:58 +0000

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. 

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-masked]] On Behalf Of Stephen Farrell
Sent: Monday, October 31, 2016 4:03 PM
To: Peter Bowen <[email-masked]>; Melinda Shore <[email-masked]>
Cc: [email-masked]
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-masked]> 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,
> 

(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.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 2 Nov 2016 16:13:27 +0000

On 02/11/16 15:57, Jeremy Rowley wrote:
> 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.
> 
> 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.

What makes you think redaction would help? If anything from the
entry in the log correlates with the cert then some wacky court
could decide who knows what... Particularly with stuff like that
so-called right to be forgotten, I'm not clear that we can plan
ahead and guess what courts might or might not decide. (And IANAL
of course:-)

S.

PS: As with the rest of this thread, the above is with no hats.

> 
> Jeremy
> 
> 
> -----Original Message----- From: Trans
> [mailto:[email-masked]] On Behalf Of Stephen Farrell Sent:
> Monday, October 31, 2016 4:03 PM To: Peter Bowen <[email-masked]>;
> Melinda Shore <[email-masked]> Cc: [email-masked] Subject:
> Re: [Trans] Topicality
> 
> 
> Peter,
> 
>>> 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?
> 
> 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-masked] https://www.ietf.org/mailman/listinfo/trans
>> 
>

---

From: Jeremy Rowley <[email-masked]>
Date: Wed, 2 Nov 2016 16:20:37 +0000

Wacky court decisions are always a risk. However, the EU has established that data collectors must delete public facing personal information at the information holder's request. There's a big difference between planning for unknown legal changes and accounting for decisions already made. By requiring logging of PII, we're essentially asking logs to fail on a regular basis. Although redaction of subject info doesn't guarantee a log won't fail because of a right to be forgotten request, it does move logs in the direction of compliance.

Jeremy

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Wednesday, November 2, 2016 10:13 AM
To: Jeremy Rowley <[email-masked]>; Peter Bowen <[email-masked]>; Melinda Shore <[email-masked]>
Cc: [email-masked]
Subject: Re: [Trans] Topicality

S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 2 Nov 2016 16:49:31 +0000

On 02/11/16 16:20, Jeremy Rowley wrote:
> Wacky court decisions are always a risk. However, the EU has
> established that data collectors must delete public facing personal
> information at the information holder's request. 

I don't believe "delete" is right there - search engines gave
different results when queried in different ways or from
different places and the underlying sources (e.g. newspaper
articles) weren't affected directly IIUC. While that is an
evolving situation I'm not sure we can safely conclude what
any of it might mean for CT. (Or for CRLs I guess if we
want to get into speculation;-)

S

> There's a big
> difference between planning for unknown legal changes and accounting
> for decisions already made. By requiring logging of PII, we're
> essentially asking logs to fail on a regular basis. Although
> redaction of subject info doesn't guarantee a log won't fail because
> of a right to be forgotten request, it does move logs in the
> direction of compliance.
> 
> Jeremy
> 
> -----Original Message----- From: Stephen Farrell
> [mailto:[email-masked]] Sent: Wednesday, November 2, 2016
> 10:13 AM To: Jeremy Rowley <[email-masked]>; Peter Bowen
> <[email-masked]>; Melinda Shore <[email-masked]> Cc:
> [email-masked] Subject: Re: [Trans] Topicality
> 
> 
> 
>> 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.
>> 
>> 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.
> 
> What makes you think redaction would help? If anything from the entry
> in the log correlates with the cert then some wacky court could
> decide who knows what... Particularly with stuff like that so-called
> right to be forgotten, I'm not clear that we can plan ahead and guess
> what courts might or might not decide. (And IANAL of course:-)
> 
> S.
> 
>> Monday, October 31, 2016 4:03 PM To: Peter Bowen
>> <[email-masked]>; Melinda Shore <[email-masked]> Cc:
>> [email-masked] Subject: Re: [Trans] Topicality
>> 
>> 
>> Peter,
>> 
>>>> 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?
>> 
>> I do not believe that it makes sense for us to talk as if privacy
>> was a concept that applies to corporate entities.
>> 
>> 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-masked] https://www.ietf.org/mailman/listinfo/trans
>>> 
>> 
> 
> 
>

---

From: Jeremy Rowley <[email-masked]>
Date: Wed, 2 Nov 2016 17:09:51 +0000

CRLs don't contain PII. It's just a serial number and status code. That's a big difference than email address, names, locations, etc.

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Wednesday, November 2, 2016 10:50 AM
To: Jeremy Rowley <[email-masked]>; Peter Bowen <[email-masked]>; Melinda Shore <[email-masked]>
Cc: [email-masked]
Subject: Re: [Trans] Topicality

S

---

From: Peter Bowen <[email-masked]>
Date: Wed, 2 Nov 2016 10:12:27 -0700

> ahead and guess what courts might or might not decide. (And IANAL

Stephen,

We don't need to plan for all eventualities, but I think it is
reasonable to plan for cases that are predictable.

Consider the following specific case:

An individual ("Alex Bauer" as an example) who is a German citizen and
resident registers a domain name (contosoedumakation.de) and gets a
certificate with GN=Alex,SN=Bauer in the subject and
www.contosoedumakation.de as a dNSName type Subject Alternative Name.
The certificate has a validity period of 90 days.  Alex sells that
domain name to someone else and ceases to have any involvement with
the domain or new registrant.  A year later, the new registrant sells
it to someone else who starts to use it to host various content that
Alex wants no association with.

Alex files a request to remove any information associating Alex Bauer
with contosoedumakation.de.  What does a CT log operator do?

Thanks,
Peter

---

From: Richard Clayton <[email-masked]>
Date: Wed, 2 Nov 2016 17:46:51 +0000

In message <[email-masked]>,
Jeremy Rowley <[email-masked]> writes

>Wacky court decisions are always a risk. However, the EU has established that 
>data collectors must delete public facing personal information at the 
>information holder's request. 

nope

it says that the data processor must balance the rights of the data
subject with the reason for doing the processing and the legitimate
rights of the public to see the result of that processing

after that balance has been done then it may well be (as in the Costeja
case) that deletion is the correct thing to do. However, in many other
cases the data can remain available (and indeed Google regularly rejects
requests to remove search results).

in this context one might also pay attention to Breyer v Deutschland
(where the court held that dynamic IP addresses were capable of being
personal data) because the judgment also observed that processing IP
addresses in order to keep web servers secure was legitimate...  viz:
even though it's personal data you can still use it provided that your
processing is appropriate

IANAL (but I drink coffee with them regularly)

- -- 
Dr Richard Clayton                               <[email-masked]>
Director, Cambridge Cybercrime Centre                mobile: +44 (0)7887 794090
Computer Laboratory, University of Cambridge, CB3 0FD   tel: +44 (0)1223 763570

---

From: Ben Laurie <[email-masked]>
Date: Thu, 3 Nov 2016 15:45:48 +0000

On 1 November 2016 at 01:04, Peter Bowen <[email-masked]> 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,
> >>
> > I do not believe that it makes sense for us to talk as if
> > privacy was a concept that applies to corporate entities.
> >
> > 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.)
> >
> > corporate secrecy on a temporary basis. I absolutely do not
> > accept that that has any privacy aspect.
> >
> There are certificates that have personal information (e.g. given
> name or the subject alternative names.  It is very possible that there
> could be logged.  For example a certificate that is used with email
> and contains both the email address and given/surname.  It might be
> that the owner of the certificate only wishes to disclose this binding
> to people receiving email from them rather than publicly disclosing
> it.  We have also seen requests for certificates that cover phone
> numbers.  A similar situation would apply -- having an "unlisted"
> number should be possible, where the subject details (other than phone
> number) are only known to a group of people who communicate with the
> number.

For these use cases, something CONIKS-like is probably more appropriate.

> So I think there is a privacy aspect here in addition to any corporate
> secrecy aspect.
>
> Thanks,
> Peter
>

---

From: Peter Bowen <[email-masked]>
Date: Thu, 3 Nov 2016 09:36:42 -0700

> For these use cases, something CONIKS-like is probably more appropriate.

How does CONIKS doesn't solve the problem of server authentication
certificates that identify an individual as the certificate
subscriber?  Even if we assume for the moment that 6962bis is only for
"traditional" PKI  and only for server authentication, these certs are
still problematic to log unredacted.

Thanks,
Peter

---

From: Ben Laurie <[email-masked]>
Date: Thu, 3 Nov 2016 17:30:59 +0000

On 3 November 2016 at 16:36, Peter Bowen <[email-masked]> wrote:
> subscriber?

Sorry, I was referring to the latter cases - e.g. S/MIME (which is
what you seem to be describing).

>  Even if we assume for the moment that 6962bis is only for

Since the personal info in those cases is not relevant to browsers
validation of the cert, in principle I can't see why we would care if
it were redacted. OTOH, the certificate is public anyway, so not sure
why redacting it in the log is useful.

The real problem is the certificate, not the log entry!

---

From: Jeremy Rowley <[email-masked]>
Date: Thu, 3 Nov 2016 17:42:19 +0000

Unlike the certificate, which can be deleted, revoked, or in some other way
removed from the CA's database and the server, a certificate cannot be
removed from a CT log, meaning it's impossible to delete PII in compliance
with the EU directive. 

-----Original Message-----
From: Trans [mailto:[email-masked]] On Behalf Of Ben Laurie
Sent: Thursday, November 3, 2016 11:31 AM
To: Peter Bowen <[email-masked]>
Cc: Melinda Shore <[email-masked]>; [email-masked]; Stephen Farrell
<[email-masked]>
Subject: Re: [Trans] Topicality

On 3 November 2016 at 16:36, Peter Bowen <[email-masked]> wrote:
>>> name or the subject alternative names.  It is very possible that 
>>> there may be a desire to redact this information (in fact it could 
>>> even be required in some jurisdictions as CT could be considered a
database).
>>> that the owner of the certificate only wishes to disclose this 
>>> binding to people receiving email from them rather than publicly 
>>> disclosing it.  We have also seen requests for certificates that 
>>> cover phone numbers.  A similar situation would apply -- having an
"unlisted"
> certificates that identify an individual as the certificate 

Sorry, I was referring to the latter cases - e.g. S/MIME (which is what you
seem to be describing).

Since the personal info in those cases is not relevant to browsers
validation of the cert, in principle I can't see why we would care if it
were redacted. OTOH, the certificate is public anyway, so not sure why
redacting it in the log is useful.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 3 Nov 2016 19:13:25 +0000

> removed from a CT log, meaning it's impossible to delete PII in compliance

Again - there is no "EU directive" that calls for deletion of
this PII, that's just speculation.

S.

---

From: Jeremy Rowley <[email-masked]>
Date: Thu, 3 Nov 2016 19:33:30 +0000

Depends on your interpretation of Article 12 of Directive 95/46/EC, the ECHR, 
and the potential impact of Article 17 of the new GDRP, although I suppose the 
data is still considered necessary in relation to purposes for which it was 
discussed and there are legitimate grounds for the processing. Given that 
names and email addresses will be discussed if subject information is included 
(especially if we'd like CT to eventually apply to s/MIME certs), I'd like a 
way to redact the info as it's questionable whether "forever" on a CT long 
complies with the requirement to keep the data no longer than necessary.

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]]
Sent: Thursday, November 3, 2016 1:13 PM
To: Jeremy Rowley <[email-masked]>; Ben Laurie <[email-masked]>; 
Peter Bowen <[email-masked]>
Cc: Melinda Shore <[email-masked]>; [email-masked]
Subject: Re: [Trans] Topicality

S.

---

From: Ben Laurie <[email-masked]>
Date: Fri, 4 Nov 2016 12:29:43 +0000

On 3 November 2016 at 19:33, Jeremy Rowley <[email-masked]> wrote:
> (especially if we'd like CT to eventually apply to s/MIME certs),

Redaction is not the correct solution for S/MIME certs. As I already
said, something CONIKS-like would be more appropriate (i.e. something
that hides the email in a verifiable way). I imagine there are other
possibilities.

> I'd like a

---

From: Robin Wilton <[email-masked]>
Date: Mon, 7 Nov 2016 11:26:28 +0000

> this PII, that's just speculation.

+1; and, much as I hate to draw attention to something which I think is bound to be misused (not by the CT community, I hasten to clarify...), the Data Protection Directive and the GDPR both contain a provision for processing of personal data "in the legitimate interests of the data controller". It seems to me that CT could build a strong case on that basis, since maintenance of an audit trail of certificate-related activity is its raison d'être.

Yrs.,
Robin

---

From: Robin Wilton <[email-masked]>
Date: Mon, 7 Nov 2016 13:35:55 +0000

> want to get into speculation;-)

Correct. The "Google Spain" ruling specified that under certain circumstances, search engines should "de-list" results identifying the claimant by name. As Stephen says, the ruling didn't oblige data controllers to delete the material itself. 

Whether or not the court expressed this as part of its rationale (I don't know), part of the practical issue they we trying to address was the ease with which copies of the material could be published. The court chose to make it harder to locate the material, rather than try to stamp it all out at source.

HTH,
Robin

---

From: Robin Wilton <[email-masked]>
Date: Mon, 7 Nov 2016 13:51:24 +0000

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

> 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,…

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