[cabfpub] Proposed new ballot on IP Addresses in SANs

Ryan Sleevi sleevi at google.com
Mon Apr 25 22:56:40 UTC 2016


On Mon, Apr 25, 2016 at 3:32 PM, Dean Coclin <Dean_Coclin at symantec.com>
wrote:

> 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.
>
>
>
> 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 ?
>

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)

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)

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160425/b4cd928c/attachment-0003.html>


More information about the Public mailing list