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

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

Reply via email to