<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 25, 2016 at 3:32 PM, Dean Coclin <span dir="ltr"><<a href="mailto:Dean_Coclin@symantec.com" target="_blank">Dean_Coclin@symantec.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I’m not sure if this is relevant but one of the problems we ran into with the Code Signing BRs was that we had added language that a timestamp server must be compliant with RFC 3161. When the auditors took a look at that they said, “Do you really want us to develop audit criteria for every aspect of RFC 3161? If so, that will be a very difficult and expensive audit”. So we backed off on that broad description and were able to describe the items in 3161 we felt were important and auditable.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I raise this only because I’m hearing a similar discussion below with respect to RFC 5280. Perhaps it’s not the same but I only raise it so that if it is expected that auditors will pick apart the RFC and develop audit criteria against it, the audit scope may dramatically increase. Alternatively, are there specific items in the RFC that you might want to call out as important and have them listed separately ?</span></p></div></blockquote><div><br></div><div>As discussed during the recent Scottsdale F2F, yes, I believe that is a desirable property for auditors. As a root store operator, it is quite disappointing and depressing to see the number of violations of RFC5280, particularly egregious ones that can impact security and well-behavedness. For example, I can think of a CA who was improperly encoding their RSA moduli as negative numbers (due to improper DER encoding), which is mathematically insane and just happened to work because OpenSSL and NSS were silently fixing it up (of course, leading them to improperly handle certain negative numbers)</div><div><br></div><div>As mentioned during Don's update, I had discussed with a number of WebTrust auditors about how existing tooling could and should be used to automate these sorts of compliance assessments. Peter Bowen's work on certlint/cablint provide an excellent baseline of detecting non-compliance, providing an objective metric to be measured against - and, when bugs are found, to be resolved within the community as points of ambiguity (such as the wildcard discussion) or as bugs within the tool (as IPv6 has been pointed out)</div><div><br></div><div>The non-compliance of CAs to RFC5280 and related have caused significant hurdles in improving Chrome's certificate validation code, as we're constantly having to work through not only the spec, but examine other implementations to see what sorts of voodoo and dark-magic have been imbued to work around matters of non-compliance. I'm sure, from the CA side, this can be appreciated in terms of not understanding how browsers build certificate chains, so I would hope we can all agree that objective standards - like 5280 is meant to be (and the underlying ASN.1 specifications like X.690) - help the industry move at a faster, better pace.</div><div><br></div><div>Given the non-compliance we've seen with encoded CRLs, or with OCSP responders, or, for that matter, with timestamp servers, and given that there's a clear and auditable criteria set forth in the BRs, I absolutely welcome auditors improving their audit criteria to address these during audit, as it would significantly save costs for implementors and for the ecosystem, which would hopefully help CAs themselves reduce costs on things like support, since they would be objectively following the spec, and could thus rapidly pinpoint the issue.</div></div></div></div>