<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 9, 2015 at 8:52 AM, Doug Beattie <span dir="ltr"><<a href="mailto:doug.beattie@globalsign.com" target="_blank">doug.beattie@globalsign.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="white" lang="EN-US" link="blue" vlink="purple"><p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">We had been planning to use CT with name redaction to support making all certificates publicly available without exposing the exact FQDNs being secured.  When CT is mandated for all certificates there will be no choice about whether or not to comply, but we hope name redaction is well defined and accepted by then. </span></p></div></blockquote><div><br></div><div>An important, and extremely relevant, point to the discussion of name redaction is that the only thing it witholds from the certificate is the DNS name. All other fields and extensions are (rightfully) treated as public data.</div><div><br></div><div>Obviously, there are degrees in which you could disclose information. For example, I'm sure some CAs would prefer to disclose issuer and serial number (e.g. what goes in a CRL), with possibly the addition of SPKI, but there's a whole host of other, relevant fields that appear in a certificate and that are governed by either root program requirements or by CA/B Forum documents (for example, policy OIDs being asserted are relevant - are these EV? DV? OV? IV? So to are basicConstraints - heaven forbid we have a CA trying to hide a basicConstraints CA=true!).</div><div><br></div><div>This goes back to the notion of *misissued* certificates requiring full disclosure, so that the public and the root programs can independently evaluate the assertions, scope, and related.</div><div><br></div><div>For the customers who care about privacy, my remark to them would be "Well, make sure your CA isn't going to misissue the certs with your secrets". Whether or not you can trust your CA to keep your domain names secret only extends as far as you can trust your CA to implement name redaction properly (if they're logging to CT) and that they've implemented the BRs / EVGs / Root Program requirements properly (so that they don't misissue)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="white" lang="EN-US" link="blue" vlink="purple"><p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt"> The only other alternative is to set up name constrained CAs for every enterprise customer, which is also certainly possible.</span></p></div></blockquote><div><br></div><div>Note that, even under the current BRs, such CAs unfortunately are considered in scope of the BRs. I personally find this quite unfortunate, as I think the 'scope of damage' of a name constrained CA is extremely limited. Even matters such as cryptographic policies I'm willing to be more lax on, because those are precisely the things that browsers can enforce (and, with increasing frequency, are enforcing), and it's the customer's failing to adhere to industry standards if they choose to ignore. However, such a customer ignoring it and only affecting '<a href="http://mysite.example.com">mysite.example.com</a>' is vastly different than a CA ignoring it and affecting 10-20% of the secure Internet,  and I don't think '<a href="http://mysite.example.com">mysite.example.com</a>' ignoring it with their name-constrained CA would be reason for taking action upon the root that gave out such an intermediate.</div></div></div></div>