I've always thought the reason OV/EV ballots haven't been proposed/passed is combination of a lack of interest from the browsers and the fact that governance reform seems to get in the way of everything else. I've for proposed tons of things over the years that simply fail because I can't get enough interest because they aren't shiny enough to capture attention. I don't think CAs would actually oppose a clean up ballot - and Hurst's proposal to require the BR OIDs for OV/DV wasn't opposed by all CAs.
A ballot standardizing on abbreviated states (for example) would probably pass. I think any ballot requiring a standard format of cert profiles would actually pass. And I think they are talking about standardizing a list of allowed sources for verifying incorporation on the validation working group. The CAB Forum just moves more slowly than it used to. We can speed it up by simply proposing more ballots. There's nothing that requires long waiting periods. Heck, if interested parties want to work on ballots with me, I'd be happy to propose them at the CAB Forum. That'd be really fun actually - propose a bunch of relying party ballots from the Mozilla community that we put forward/sponsor. LMK -----Original Message----- From: dev-security-policy <[email protected]> On Behalf Of Ryan Sleevi via dev-security-policy Sent: Wednesday, August 28, 2019 9:02 AM To: Corey Bonnell <[email protected]> Cc: mozilla-dev-security-policy <[email protected]> Subject: Re: GlobalSign: SSL Certificates with US country code and invalid State/Prov On Wed, Aug 28, 2019 at 7:13 AM Corey Bonnell via dev-security-policy < [email protected]> wrote: > Anyhow, judging from censys.io, it looks like there are far bigger > offenders of this particular quirky rule than Digicert and GlobalSign. > I'd love to know why the BRs/EVGs are inconsistent with this > requirement for jurisST having to be a full name, but ST can seemingly > be either. It looks like the existing language in the BRs for ST > stemmed from Ballot 88, but unfortunately there was little discussion > on the mailing list that I could find about the rationale for this > inconsistency. > > Ideally, the requirements would be identical so that Relying Parties > can more easily extract identity information from these certificates > to aid in trust decisions. > There's a long list of things that CAs that advocate for OV/EV information could be doing to make it reliable and useful to Relying Parties. Consider this post, from Ryan Hurst in 2012 - https://unmitigatedrisk.com/?p=203 - talking about the 'simple' challenges just in distinguishing DV vs OV certificates. The proliferation of CA-specific policy OIDs has, functionally, made this a non-trivial task. While the Baseline Requirements provide a series of policy OIDs that CAs may assert, the use is not mandatory nor widespread. With respect to OV/EV information, it's clear that in the absence of an allowlist, and more explicit profiles, the functional value to Relying Parties is going to be greatly limited. This is not an exclusive criticism of OV/EV either; the lack of technical profiles for both CRLs and OCSP represent significant challenges. The problem, as with all things in the Forum, is that the incentive structures are misaligned. There is questionable benefit, to a CA, to develop a ballot to normatively specify a requirement on the information sources or the formatting of certificates. While some have suggested the costs in determining adequate information sources (e.g. "does X meet the criteria of the BRs?") might be reduced by such a shared list, most of that cost has already been sunk by the extant CAs, so it only benefits new upstarts or those entering new jurisdictions. With profiles for certificates, it's even more marked - every profile represents a chance for the CA to be accused of violating them, and represents additional controls all CAs would need to implement. It's naturally in their own self-interest to not only not propose such changes, but oppose them when proposed, because it's all risk for benefit that they and their Subscribers do not realize. So it's left to browsers to normatively require things, much as it was with the Baseline Requirements. And we know the browsers are a busy lot, in part due to the influx of issues and the woeful responses and/or remediations. So what can be done? If folks joined the CA/Browser Forum as Interested Parties (and thus executed the IP agreement), it's a much quicker path towards writing technical changes which browsers might then be able to propose as draft ballots to then place into the BRs. Alternatively, folks here could open issues with Mozilla Policy, wholly ignoring the CA/Browser due to its many issues, proposing changes to Mozilla Policy. Mozilla could eventually propose these as ballots or, more pragmatically, CAs who have to follow these rules anyways might be inclined to formalize them into the BRs, rather than run the risk of future Root Store divergence. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
