On 3 Nov 2016, at 19:13, "Stephen Farrell" <[email protected]> wrote:
> > > 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. +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 > > 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 _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
