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

[Phillip]

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?