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 <dev-security-policy-boun...@lists.mozilla.org> On 
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Wednesday, August 28, 2019 9:02 AM
To: Corey Bonnell <cbonn...@outlook.com>
Cc: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org>
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 < 
dev-security-policy@lists.mozilla.org> 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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to