On 1 November 2016 at 01:04, Peter Bowen <[email protected]> wrote: > > On Mon, Oct 31, 2016 at 3:02 PM, Stephen Farrell > <[email protected]> wrote: > > 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? > > 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. > So I think there is a privacy aspect here in addition to any corporate > secrecy aspect. > > 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
