Hiya, On 01/11/16 01:04, Peter Bowen 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
"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. > 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.) > 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? :-) > 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. > > 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. > 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. Again, please show us evidence from the public logs. That'd be compelling where speculation is not. But please note that redaction in CT is not the only possible mitigation - it may be better to say to CAs: "Hey, don't issue certs with PII unless the EE wants that really" since after all certs that end up in logs are mostly TLS server certs and hence will be picked up via zmap anyway if they are on the public Internet. (And those that are not on the public Internet because of corporate secrecy requirements are not relevant for privacy.) > > So I think there is a privacy aspect here in addition to any corporate > secrecy aspect. And you also agree that separating those concepts is important? I hope so. If not, please do argue that. If so, let's see if there are really any important privacy cases here or if the only interesting ones relate to corporate secrecy. (Which, again is IMO a totally valid concept in many, but not all, guises.) Actually, my meta-suggestion is to start a new thread that does not have the failing of fatally mixing corporate secrecy and privacy. (Or even two threads if you think both concepts need discussion for CT.) S. > > Thanks, > Peter > > _______________________________________________ > 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
