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
security.
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).
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"
intermediates?
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
anything?
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
around this.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
