[cabfpub] [EXTERNAL] Brazilian bank DNS heist
rob.stradling at comodo.com
Thu Apr 13 14:47:45 UTC 2017
On 10/04/17 15:51, Ryan Sleevi wrote:
> On Mon, Apr 10, 2017 at 10:36 AM, Rob Stradling wrote:
> Not all CAs have chosen to use separate intermediate(s) to issue
> only EV certs.
> e.g., https://crt.sh/?Identity=%25&iCAID=904
> I didn't say they have - I said they should.
They _could_, for sure.
But "they should"? Citation needed. What root program(s) require this
> Any CA who isn't using a distinct EV intermediate can, in the future, do
> so for new certifictes, w/o any issue. That's not a hard blocker.
> Whereas adding an "EV only" option to HSTS would...
> 1) avoid the need to coordinate and maintain a list of "EV only" pins.
> That's not correct. It just outsources the problem back to the user and
> the browsers - any site operator would need to know what constitutes as
> "EV only". For example, if browsers don't all update their EV list on
> the exact same day (and they don't), then you end up in a situation
> where Browser A recognizes a site as EV-only and Browser B does not. The
> implications of this are that the site would break in Browser B (if the
> pin was noted).
OK, so there are at least 3 groups of intermediates that issue EV certs:
1. Issue EV certs, but also issue non-EV certs.
2. Issue only EV certs, but not trusted for EV on all EV-capable
3. Issue only EV certs, and trusted for EV on all EV-capable browsers.
I agree that 'any site operator would need to know what constitutes as
"EV only"', so yes, there would need to be an official list of "EV only"
(group 3) intermediates/pins published somewhere, and maintained.
(Publication and maintenance of such a list could be largely automated
by adding a page to crt.sh or some other root program aggregator service).
> 2) avoid the need for site operators to update their local copies of
> the list of "EV only" pins.
> It doesn't. A site operator would constantly have to be checking what
> sets of CAs the browser noted were for EV only, to make sure their CA
> was providing that.
Checking != Updating.
Both your HPKP-based approach and my HSTS-based approach would require
the site operator to regularly check that the EV intermediate they
currently use is still on the group 3 list.
However, your HPKP-based approach would also require the site operator
to add/remove a pin every time a different EV intermediate is
added/removed from the group 3 list.
> It's riskier for browsers to do so, because now there's zero
> relationship with the customer (the site operator) and with the CA (to
> make sure their PKI hierarchy is sane). As plenty of CAs in the Forum
> can attest to, they have been bitten where cross-signs of their
> intermediates lead to incorrect recognition of EV status. Or browser
> bugs related to certificate policies.
This is a fair point.
completely bricked (in Chrome) any site using an affected EV cert if my
proposed HSTS-based "EV only" approach was in use. Whereas with your
HPKP-based approach, the sites would've still been accessible, albeit
without the EV indicator (due to the bug).
It makes a nice change for HPKP to be the non-footgun approach to something!
> This instead promotes a direct relationship between the customer and the
> CA, which is the only relationship for which a reliable means of
> communication exists (quite literally, in the case of EV!)
> 3) work even in the case of a CA that hasn't chosen to use "EV only"
> Sounds like you're saying CAs are incapable of change? ;)
Not at all. I was merely looking at the current landscape and
attempting to determine the path of least resistance towards a
> More pragmatically, nothing about the proposed solution is blocked on
> any new development, other than the CA needing to do something if the CA
> wants to offer this service to its subscriber. That's quite literally
> the exact place the cost of work should be borne. A CA can dedicate one
> or more intermediates to EV and begin issuing _today_ (provided they've
> got their ceremonies scripted and ready).
Senior Research & Development Scientist
COMODO - Creating Trust Online
More information about the Public