On 3 November 2016 at 19:33, Jeremy Rowley <[email protected]> wrote: > 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),
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 > 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 protected]] > Sent: Thursday, November 3, 2016 1:13 PM > To: Jeremy Rowley <[email protected]>; Ben Laurie <[email protected]>; > Peter Bowen <[email protected]> > Cc: Melinda Shore <[email protected]>; [email protected] > Subject: Re: [Trans] Topicality > > > > On 03/11/16 17:42, Jeremy Rowley wrote: >> 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. > > Again - there is no "EU directive" that calls for deletion of > this PII, that's just speculation. > > S. > >> >> -----Original Message----- >> From: Trans [mailto:[email protected]] On Behalf Of Ben Laurie >> Sent: Thursday, November 3, 2016 11:31 AM >> To: Peter Bowen <[email protected]> >> Cc: Melinda Shore <[email protected]>; [email protected]; Stephen Farrell >> <[email protected]> >> Subject: Re: [Trans] Topicality >> >> On 3 November 2016 at 16:36, Peter Bowen <[email protected]> wrote: >>> On Thu, Nov 3, 2016 at 8:45 AM, Ben Laurie <[email protected]> wrote: >>>> On 1 November 2016 at 01:04, Peter Bowen <[email protected]> wrote: >>>>> >>>>> There are certificates that have personal information (e.g. given >>>>> name, surname, and physical location) in the subject distinguished >>>>> 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). >>>>> We already see this with domains in many countries where the full >>>>> registrant details are not publicly available. >>>>> >>>>> Additionally, while 6962-bis does focus on certificates used for TLS >>>>> server authentication, there are other types of certificates that >>>>> 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. >>> >>> How does CONIKS doesn't solve the problem of server authentication >>> certificates that identify an individual as the certificate >>> 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 >>> "traditional" PKI and only for server authentication, these certs are >>> still problematic to log unredacted. >> >> 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! >> >> _______________________________________________ >> 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
