[cabfpub] A few technical details about the case by TURKTRUST

Phillip philliph at comodo.com
Tue Jan 8 17:48:04 UTC 2013

On Jan 7, 2013, at 6:06 AM, Gervase Markham wrote:

> On 04/01/13 19:40, Rick Andrews wrote:
>> I have one concern about the post process control you’ve put into place.
>> You say that it will check the basicContraints value against the
>> respective certificate policy. I’m worried that if that test profile
>> gets put on the production system again, and certs are issued against
>> it, your post process control will not alert you, because the test
>> policy would say “add basicConstrains cA=true” and that would match the
>> issued certificate.
> I also had this concern. I think Rick's advice is very good.
> Question for the group: would it be a good idea to recommend it as a
> best practice that intermediates issued for the purpose of issuing
> end-entity certificates have a path length constraint? As I understand
> it, if TurkTrust's intermediate which mis-issued this certs had had such
> a constraint, the *.google.com and other certs created by the firewall
> appliance would not have worked. Am I right?

I was just about to suggest this as best practice. But it would be useful to know what the extent of browser/etc. support for constraint checking.

It seems to me that part of the problem here is that we have a fragmentary approach to explaining the security controls necessary to set up a CA.

The idea of Offline/Online roots is to ensure that the consequences of compromise of an online root are minimized to the greatest extent possible. So an online root should never have a need to generate a Cert signing cert and so should not have that capability. Are there other capabilities that we are missing that we can add to the list of limitations?

More information about the Public mailing list