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

[Ryan Sleevi]

On Tue, Jan 8, 2013 at 9:48 AM, Phillip <philliph at comodo.com> wrote:
>
> 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?

Depends on which cert you're talking about having the
pathLenConstraint. If we're talking about the existing TURKTRUST
intermediate, then yes, it would have acted as a mitigation, since EE
-> *.EGO -> TT-I -> TT-Root would have violated the pathLenConstraint
of TT-I. However, if you're talking about putting it on the *.EGO,
then no, it would not have worked.

>
> 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.

Why should this matter? This is not like nameConstraints, where it's
in a dedicated extension that might have the crit-bit set - this is
part of basicConstraints, where any client that wasn't checking bC
would be arguably so fundamentally flawed that it's a security risk in
its own right.

The failure mode of a client not observing pathLenConstraint is going
to be failing open, so I don't see browser support as an argument
against it.

For what it's worth:
OS X: 10.3+ (10.2 didn't check)
Windows: XP+ for sure, although I would hope as far back as the IE3+
days. I know there was the basicConstraints:isCA bug, so it's possible
there are a few (really old) versions that didn't, but that would
still fail open.
Linux: NSS in both 'legacy' (as used by FF) and 'libpkix' (as used by Chrome).
OpenSSL using the 'stock' cert verifier.
Android: At least as far back as 2.x, which is what I had handy to
check, but it should be 'all' AIUI.

>
> 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?
>

So in the case of managed PKI, you would propose that the certificate
be directly issued by the offline root-in-HSM? This creates potential
problems for the descriptions of certificate hierarchies, which
typically detail the offline-root-and-online-intermediates, and
describe the policies under which each intermediate issues
certificates. If these online-intermediates have a pathLenConstraint,
then in the managed PKI scenario, you can only be issued underneath
the root. The result of this is that it creates policy ambiguity as to
the nature of the policies that apply to the managed-intermediate.

If CAs were to design their hierarchy such that they have
offline-root-and-offline-intermediates, followed by online
intermediates, such that they can issue managed PKI certs via the
offline intermediate, and online certs via the online
(sub-)intermediate, then we get into a situation where we're creating
market forces that discourage SSL, by adding 1-3K overhead to the SSL
handshake and potentially blowing out the initial congestion windows
of most clients, forcing an extra RTT.

Maybe that's an incentive for CAs not to offer "managed PKI" services,
or to diversify roots, etc, but my fear is that the 'simplest'
implementation will not help the users.

The other thing to consider is that these constraints do work
retroactively for existing intermediate. They only apply when a CA
issues a new intermediate - which is a very rare event to begin with.
Unless all existing CAs were willing to phase out their existing
intermediates in favour of path-constrainted intermediates, then I
don't see this working. Further, when bringing online new
intermediates, the economic incentives are against including a
pathLenConstraint in a new intermediate, as it restricts the
capabilities of that intermediate as compared to potential competitive
forces in the market.

As such, short of MUST, whether at the CA/B Forum level or through the
individual browser programs, I'm not sure this really does much more
than make us feel good.