Some of the methods of implementing these suggestions seem complex, but there’s a lot of good ideas here. Clint, what do you think of my suggestion on asking some outside SMEs to chime in?
Respectfully, Tarah Wheeler Principal Security Advocate Senior Director of Engineering, Website Security Symantec [email protected]<mailto:[email protected]> From: Clint Wilson <[email protected]<mailto:[email protected]>> Date: Friday, November 18, 2016 at 7:53 AM To: Tarah Wheeler <[email protected]<mailto:[email protected]>>, Eran Messeri <[email protected]<mailto:[email protected]>> Cc: Rob Stradling <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [Trans] Call for adoption: draft-strad-trans-redaction-00 Hi all, I’d like to propose that the redaction I-D allow for redacting labels above the 2nd level domain, as determined by the public suffix used, of SAN:dNSName values. For example, redaction of “secret.example.com<http://secret.example.com>” would result in “{redacted}.example.com<http://example.com>” while “secret.example.co.uk<http://secret.example.co.uk>” would result in “{redacted}.example.co.uk<http://example.co.uk>”. The I-D should also allow for redaction of some subject DN values, especially commonName (the unfortunate reality is this field is still used… frequently). To (hopefully) address some of the concerns redaction has encountered in the past, we’d like to propose the addition of a “redaction signal”. This is essentially the domain owner publicly signaling that they have opted-in to redaction of their certificates. While this does not solve the issue of a client being unable to authoritatively determine that the host name being observed during certificate verification is the one intended in the redacted precertificate, it does introduce a mechanism for the entity that CT is intended to protect to assert their acceptance of this tradeoff. We haven’t identified the precise mechanism via which this redaction signal would be communicated, but two options we want to throw out are CAA records and HTTP header (such as the proposed Expect-CT header). We also have not identified who/what should verify the redaction signal and when. A CA should check for the presence of the redaction signal before submitting a redacted precert, but if that were the only entity checking, we would need to determine a way to publicly audit this check. A Log Operator might check for the presence of a redaction signal before accepting a redacted precert, but this introduces a new requirement for logs to make some form of connection to the domain(s) in the precert. A relying party might check for the presence of the redaction signal when verifying the SCTs, but the lack of a redaction signal at the time of connection does not necessarily represent the state of redaction signal at the time of precert submission. A log monitor might check for a redaction signal when a precert is discovered for a domain of interest, in order to help determine whether a discovered precert might represent misissuance. Cheers! On Wed, Nov 16, 2016 at 5:45 PM Tarah Wheeler <[email protected]<mailto:[email protected]>> wrote: I’m glad to hear it, and looking forward to it. I’d like to ask about the two things that seem really necessary to me; sometimes a technical RFC lacks within it the rationale for why we do things. I’ve been creating essentially a white paper at the same time as writing comments and some prescriptive thoughts on privacy. There’s a fundamental disagreement here over why we would want privacy and transparency on a variable slider, and ultimately, it comes down to the motivations of the entities involved. Some of us want to sell a product that provides privacy, and some of us want to sell a product that is only possible with transparency. Let’s not pretend that we’re not all faced with differing incentives. I’ve been on this list for a while, and very quiet because in general, it seems like a fool’s game to try to argue people out of acting in their best interests. It wasn’t until now that I had a solid idea of what would be useful to this process. There are some very smart people in information security. There are those with strong inclinations towards advocating privacy at multiple levels of organizational size from a individual to a YUUUUUUGE company (sorry, couldn’t resist, and we all need to laugh a bit now and then). There are those who see full transparency as a virtue and I can certainly understand why, both on an ideological and a financial level. I’ve watched this situation be cautiously talked around for months now, and I’d be interested to hear people’s thoughts on asking some unassailably corporate-neutral experts on both sides of this debate to provide guidance. Whose opinion are you interested in hearing on whether or not permitting certificate privacy and accepting it as a browser standard is a good idea? I’m putting myself and Symantec out there in a vulnerable way; I and we might not always hear what we want to hear, but every one of us wants to make the internet better in the way we believe will work best. Respectfully, Tarah Wheeler Principal Security Advocate Senior Director of Engineering, Website Security Symantec [email protected]<mailto:[email protected]> From: Eran Messeri <[email protected]<mailto:[email protected]>> Date: Tuesday, November 15, 2016 at 6:17 PM To: Tarah Wheeler <[email protected]<mailto:[email protected]>> Cc: Rob Stradling <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [Trans] Call for adoption: draft-strad-trans-redaction-00 AIUI _______________________________________________ Trans mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/trans
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
