On Wed, Aug 28, 2019 at 12:36 PM Jeremy Rowley <jeremy.row...@digicert.com>
wrote:

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

Not all CAs and no true Scots, but it's true that when Microsoft attempted
to require this via policy, there were significant enough concerns that led
them to withdraw some of these elements.


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


I mean, I think we're more in agreement than disagreement. Browsers have
higher priorities, generally focused on ensuring their existing members are
compliant and actually following the rules set out by the contracts and
root policy expectations, and that the issues that the CAs have are getting
addressed meaningfully and in a timely fashion. I can assure you, it's a
full time job and then some - between Kathleen handling the additions,
Wayne doing CP/CPS reviews and supporting Mozilla, and myself doing many of
the incident investigations, there's very little time for much else. CAs,
as a collective (although there are of course individual exceptions),
haven't really taken to improving things for relying parties. It may be
that CAs don't understand the challenges RPs face, or it may be that they
don't recognize the innate value in consistency.

I've had conversations with CAs, about allowlists, and I've gotten enough
pushback from enough CAs to say "OK, it's a better use of time to focus on
the things of immediate concern - like SC22 - than to try and fight a
battle on two fronts". We know some members of the CA/Browser Forum were so
vociferously opposed to improved requirements of RAs that the amount of
time it would take to improve things was simply not proportionate to the
value browsers would receive; after all, it'd only apply to OV/EV, and as
we see, if CAs are willing to let those go fallow, so be it.

It's worth noting that GLEIF itself made it clear that they saw many of
these issues and designed both the administrative structure and the
requirements to learn from these mistakes. Conceptually, an LOU recognized
by GLEIF is doing the same thing a CA recognized by a browser is doing for
OV/EV - vetting organizational information. It's conceptually similar to
eIDAS, in that there's multiple legal frameworks incorporating those
results, but very distinct from eIDAS, in that it's independent and
non-profit. Structurally, decisions are not made by the LOUs (aka CAs),
they're made by the LEI ROC (aka Browsers) - those who depend on the
stability and correctness of the system. GLEIF acts as a caretaker, but
itself remains independent from the LOUs and the system itself. You can
read more
https://www.gleif.org/en/about/governance/mou-between-gleif-and-lei-roc# ,
but I highlight it to emphasize that, structurally, the answer for why
hasn't much been done has been that the incentives are misaligned for CAs
to do this, the value to browsers is commensurately low (e.g. why browsers
don't recognize OV and have expressed concerns with EV, among other things).

Anyways, that's my pitch for why
1) Folks should file Moz Policy issues first and foremost, because that's a
direct way you have to raise and highlight concerns
2) Care needs to be taken to "do it right" - this is true of all standards
work, and doesn't come overnight, but it can start by just making sure
there's a clear description of the problem and a clear description of the
considerations made
3) Either Mozilla may bring these issues to the Forum (if they are
priorities for Mozilla), or CAs may want to consider doing so (if it
impacts the value proposition to Relying Parties)

Nothing prevents change, except for the number of hours in a day :)
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to