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 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 >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
