New Sub CAs under the DigiCert RSA and ECC Transition Roots

2017-11-10 Thread Ben Wilson via dev-security-policy
In the spirit of full transparency and in attempt to comply to the extent we
can with Mozilla policy, on Thursday, Nov. 2, we created several sub CAs
under two new "transition" roots (yet to be submitted as roots).  These sub
CAs haven't been uploaded yet to the CCADB because no instances of the roots
have been created in the CCADB.  Also, I don't have access, yet, to the
Symantec roots in the CCADB, so while these sub CAs chain to the DigiCert
RSA and ECC transition roots (which have been cross-certified by the
Symantec roots - see https://ccadb.force.com/0011J1BtNYx and
https://ccadb.force.com/0011J1BtNaF), they are not listed yet in the
CCADB (because as a technical matter, I have no access - I get an error when
I attempt to do so).  No end entity certificates have been issued by the new
sub CAs.  We'll get those sub CAs uploaded to the CCADB when I get access
first thing next week. 

 

Ben Wilson, JD, CISA, CISSP

VP Compliance



 



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Acquisition policy (was: Francisco Partners acquires Comodo certificate authority business)

2017-11-10 Thread Wayne Thayer via dev-security-policy
On Thu, Nov 9, 2017 at 1:25 PM, Peter Kurrasch via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> There's always a risk that a CA owner will create a security nightmare
> when we aren't looking, probationary period or not. In theory regular
> audits help to prevent it, but even in cases where they don't, people are
> free to raise concerns as they come up. I think we've had examples of
> exactly that in both StartCom and Symantec.‎
>

I agree. What we're really talking about here is the removal of trust in a
CA based on new information. In the case of an acquisition, that
information may not be publicly available until after a deal is completed,
making the current requirement to halt issuance very disruptive. I'd modify
section 8.1 of the policy to distinguish an acquisition of the CA
operations from a purchase of a root key, and only require approval prior
to issuance in the latter case.

>
>
Perhaps one way to think of it is: Do we have reason to believe that the
> acquiring organization, leadership, etc. will probably make good decisions
> in the furtherance of public trust on the Internet? For a company that is a
> complete unknown, I would say that no evidence exists and therefore a
> public review prior to the acquisition is appropriate. If we do have
> sufficient evidence, perhaps it's OK to let the acquisition go through and
> have a public discussion afterwards.
>

The CA should be responsible for providing information about the effect of
the acquisition on their operations. In this case, Robin provided some
essentials:

>As you have seen from the announcement, we have a new CEO and new Chairman
>who have prior experience in managing a trusted CA organization.
>
>There are to be no resultant changes to our CPS, our operations, our
>business policies or procedures, or the secure locations from which we
>operate our CA infrastructure.
>
>The operational personnel in Comodo CA Limited will not change.  The
>certificate validation teams will remain unchanged.

The policy already requires the CA to disclose any CPS changes. I'd add a
requirement that the CA provide a public statement describing all material
changes that will be made as a result of the acquisition. That statement
should be signed by Senior management of the acquiring company. The CA
should also [obviously] be expected to answer any reasonable questions that
are raised during the discussion period.

>
> The Francisco Partners situation is more complicated, however. Francisco
> Partners itself does not strike me as the sort of company that should own a
> CA but only because they are investors and not a public trust firm of some
> sort. That said, they are smart enough to bring in a leadership team that
> does have knowledge and experience in this space. Unfortunately, though,
> they are also bringing in a Deep Packet Inspection business which is
> antithetical to public trust. So what is one to conclude?
>
> The reporting that I've seen seem to indicate that Francisco Partners will
> not (will never?) combine ‎PKI and DPI into a single business operation.
> They have to know that doing so would be ruinous to their CA investment. If
> we assume they know that and if we are willing to take them at their word,
> I suppose it's reasonable to "allow" the transfer as it relates to Mozilla
> policy. If we should learn later on that that trust was misplaced, I'm sure
> we will discuss it and take appropriate action at that time.
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy