Google Groups

Re: Subordinate-CAs from trusted roots for 'managing encrypted traffic'

Stephen Schultze Feb 2, 2012 8:27 AM
Posted in group:
On 2/2/12 10:29 AM, Patrick Tate wrote:
> Trustwave recently posted an update on their CPS page:
> "It has been common practice for Trusted CAs to issue subordinate
> roots for enterprises for the purpose of transparently managing
> encrypted traffic. In the past, Trustwave, like many of our peers in
> the industry, has enabled organizations to perform this activity. Due
> to events of the past year, Trustwave has decided to revoke all
> subordinate roots issued for this purpose."
> Does anyone else read this that they have previously issued trusted
> subordinate-CAs from their public roots, specifically to allow
> interception and MITM of SSL traffic?
> Wouldn't that mean that they've been allowing 'enterprises' to
> purposefully mis-issue certificates - like Diginotar, only condoned,
> and with the consent of the CA?

It's not clear what "transparently managing encrypted traffic" means.
Perhaps you should ask them that, and for a list of all revoked Sub-CAs
(to be publicly disclosed to this list).

> I understand they're now revoked (supposedly), but why should Mozilla
> still maintain trusted root CAs for Trustwave and '...peers in the
> industry...' who do this?
> I know there was discussion about disclosure of subordinate CAs from
> the trusted CAs, but I see no reason why Mozilla should maintain any
> trusted CA that isn't willing to disclose a list of all subordinate
> CAs that are *not* hosted with the trusted CA or under a sufficient
> Mozilla-approved audit scheme audited infrastructure.

I wholeheartedly agree.

Of course, the current policy does not require this.  All the more
reason to adopt updates to the policy in the near future.

Of course, there is a difference between third-party CAs that use their
CA certs only for issuing certs for domains they control and third-party
CAs that issue certs for domains that they do not control.  Which
practice a given entity is undertaking is entirely cryptographically
opaque to Mozilla, and is governed by, at best, contract (under the
current policy).  This is the heart of the problem with trying to make
policy based on a distinction between promised practices versus
disclosed and cryptographically demonstrable controls.