On Thu, Apr 13, 2017 at 11:27 AM, Rob Stradling <[email protected]> wrote: > > 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. I wasn't saying it was required, it had been proposed and discussed, as I recall. Looking through the CA/B Forum archives, https://cabforum.org/pipermail/public/2015-July/005793.html captures some of the reaction that CAs had regarding the policy as written, which Jody later clarified (and is why aka.ms/rootcert doesn't reflect that). This was with respect to standardizing the requirement of the OIDs in the end-entity certificates, which required cutting new intermediates for CAs in order to include that OID to ensure that path processing appropriately flowed those policy OIDs down. > 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? No, the 'not support' it was related to the idea of requiring the use of Group 3 intermediates. I would _love_ to see CAs take more proactive steps in segmenting their intermediates and documenting those policies. Just like I would _love_ to see more documentation about CAA. And I would _love_ to see more documentation about certificate profiles. In short, I love more documentation, preferably that Someone Else maintains :) > 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. :-) =) Glad it was not intentional, but it would still have that effect, and thus is expressly undesirable. Hence my vocal and strong opposition to the premise - anything that increases the compatibility risks of responding to misissuance is... undesirable :)
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
