[cabfpub] [EXTERNAL] Brazilian bank DNS heist
rob.stradling at comodo.com
Thu Apr 13 08:27:15 MST 2017
On 13/04/17 15:57, Ryan Sleevi wrote:
> On Thu, Apr 13, 2017 at 10:47 AM, Rob Stradling wrote:
> They _could_, for sure.
> But "they should"? Citation needed. What root program(s) require
> this today?
> Microsoft's most recent policy update proposed adding this, but it was
> pointed out that CAs are not presently doing that. I think that's a
> reasonable statement for SHOULD, but not MUST, to borrow from RFC 2119.
You got a link for that?
On https://aka.ms/rootcert, the closest thing I see is...
"New intermediate CA certificates under root certificates submitted for
distribution by the Program must separate Server Authentication, S/MIME,
Code Signing and Time Stamping uses. This means that a single
intermediate issuing CA must not be used to issue both server
authentication, S/MIME, and code signing certificates. A separate
intermediate must be used for each use case."
...which doesn't mention EV at all.
> After all, by separating out unique issuance, CAs enable their customers
> to improve their security stance. I should hope the position you're
> advocating is not that the only things worth doing are those which are
> required on CAs - that'd be a rather cynical take on the state of CA
> 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).
> I disagree, and of course, do not support that. Group 2 is wholly
> sufficient for the security needs of users,
Ah, you're right. My mistake.
Group 2 is sufficient for the HPKP-based approach. The "EV only"
intermediates do need to only issue EV certs, but those intermediates
don't need to be trusted-for-EV by all browsers. (They do of course
need to be trusted-for-serverAuth by all browsers though).
BTW, did your "not support that" comment also apply to the idea of
adding a page to crt.sh (or some other root program aggregator service)
that would automatically maintain the list of (group 2!) "EV only"
> and avoids introducing an
> additional third party (browsers) into mediating that relationship. I
> would be happy to point out a variety of CAs who have had difficulty in
> having their roots or intermediates EV recognized, due to incomplete
> audits or documentation. Were such an "EV only" policy implemented as
> you've proposed, those CAs would find themselves unable to provide their
> services to customers. I'm sure you can appreciate why CAs should find
> that undesirable.
> A cynical take would be to suggest that by defining it as Group 3, it
> may be an attempt by CAs to "increase" the compatibility risk of
> removing EV for a particular CA, thereby trying to capture more of the
> market. Whether or not that is the intent, that would certainly be a
> result, and as such, would be unquestionably unacceptable from the
> browser side, and thus unlikely to ever be supported. By going through
> Group 2, those issues are ameliorated regardless of whether or not the
> browser supports or recognizes the CA's EV status, and Group 2 is fully
> accomodated today by browsers via HPKP.
I like a good conspiracy theory as much as the next guy, but I'm afraid
in this case it was just insufficient coffee. :-)
> 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.
> Again, my proposal has nothing to do with Group 3 in order for site
> operators to recognize the security benefits nominally afforded by the
> enhanced vetting claimed by EV. It only requires that issuing CAs make a
> distinction between Group 1 and Group 2, and to allow subscribers to
> choose to pin to Group 2. It leaves the trust relationship solely
> between the customer and the set of issuing CAs, and if a customer
> cannot trust a CA to follow its own CP/CPS, well then, what good is
> Not at all. I was merely looking at the current landscape and
> attempting to determine the path of least resistance towards a
> maintainable solution.
> Right, the HPKP solution can be implemented tomorrow, with the only
> change being on CAs that don't already distinguish from EV capable
> intermediates and non-EV capable intermediates. That is, quite
> literally, the path of least resistance :)
Yeah, you've convinced me now. Thanks for helping me to get my head
Senior Research & Development Scientist
COMODO - Creating Trust Online
More information about the Public