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
<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
today?
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
browsers.
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.
https://bugs.chromium.org/p/chromium/issues/detail?id=705285 would've
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"
intermediate(s).
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
maintainable solution.
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).
Fair enough.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
