On Monday, October 31, 2016, Stephen Farrell <[email protected]> wrote:
> > Hiya, > > "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. Isn't that an element of log policies - and what clients are logging? These certs definitely exist - but the combination of client behavior and log policies have, so far, prevented them from being logged, and only incidentally so. > > > 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.) > > I fail to see how ACME relates. This is a question of PKI: does TRANS exist solely for elements of browser-mediated Web PKI, or is it for more? In either case, they extend beyond issuance via ACME, and speak to policy, so I don't feel we can be so easily dismissive. > > 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? :-) Are you suggesting these cases are not valid? Because Peter is far from the only one to bring them forward, as we've heard it in the past in relation to ETSI profiles and the EU Trust List from a number of CAs. Are you suggesting this isn't the venue to discuss technical solutions, as it relates to CT, to those problems? > > 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. Are you suggesting that CT does not need to be aware of what is possible, either through other WGs actions (such as NSEC/NSEC3) or through other bodies, such as IANA/ICANN? It so, can you articulate what you view as the appropriate scope of function and discussion here? I mean that as an honest question. > > 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. I am sorry, but I find this argument going against the seeming IETF principles of not favoring a particular vendors policies. What is a public log, in your view? What policies do you believe logs must have for acceptance? How do you respond, given that some CAs and log operators have explicitly stated they want to log email and code signing certificates? Concretely, WoSign is such an example of a CA doing that. It seems the core of your objections are simply "Chromium policies have prevented this" - but as the person responsible for those policies, I don't find that argument particularly compelling or convincing, and certainly not in line with the feedback we've received at Google, nor necessarily how I think Chrome would like to see CT grow. Perhaps it's easier to just ask - do you view CT as only valid for a limited subset of Internet-facing, "publicly trusted," id-kp-serverAuth EKU bearing certificates? If so, could we see if there's consensus with that view? Because at present, the tech neither requires nor states that, and perhaps that's core to determining whether your dichotomy of privacy and confidentiality is accurate and reflected in both the tech and the running code.
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
