[cabfpub] Proposed new ballot on IP Addresses in SANs

[Kurt Roeckx]

On Mon, Apr 25, 2016 at 03:56:40PM -0700, Ryan Sleevi wrote:
> 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.

OpenSSL also wants to be more strict in what it accepts, which is
one reason why I started with my x509lint, which results you can
now also see on crt.sh.


Kurt