[cabfpub] [EXTERNAL] Brazilian bank DNS heist

[Ryan Sleevi]

On Thu, Apr 13, 2017 at 11:27 AM, Rob Stradling <rob.stradling at comodo.com>
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 :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170413/07420257/attachment-0003.html>