I have sent the following communication to CAs with root certificates in
Dear Certification Authority,
This note requests a set of immediate actions on your behalf, as a
participant in the Mozilla root program.
Mozilla recently removed the DigiNotar root certificate in response to
their failure to promptly detect, contain, and notify Mozilla of a
security breach regarding their root and subordinate certificates
If you ever have reason to suspect a security breach or mis-issuance has
occurred at your CA or elsewhere, please contact secu...@mozilla.org
Please confirm completion of the following actions or state when these
actions will be completed, and provide the requested information no
later than September 16, 2011:
1) Audit your PKI and review your systems to check for intrusion or
compromise. This includes all third party CAs and RAs.
2) Send a complete list of CA certificates from other roots in our
program that your roots (including third party CAs and RAs) have
cross-signed. A listing of all root certificates in Mozilla's products
is here: http://www.mozilla.org/projects/security/certs/included
3) Confirm that multi-factor authentication is required for all accounts
capable of directly causing certificate issuance.
4) Confirm that you have automatic blocks in place for high-profile
domain names (including those targeted in the DigiNotar and Comodo
attacks this year). Please further confirm your process for manually
verifying such requests, when blocked.
5) For each external third party (CAs and RAs) that issues certificates
or can directly cause the issuance of certificates within the hierarchy
of the root certificate(s) that you have included in Mozilla products,
a) Implement technical controls to restrict issuance to a specific set
of domain names which you have confirmed that the third party has
registered or has been authorized to act for (e.g. RFC5280 x509 dNSName
name constraints, marked critical)
b) Send a complete list of all third parties along with links to each of
their corresponding Certificate Policy and/or Certification Practice
Statement and provide public attestation of their conformance to the
stated verification requirements and other operational criteria by a
competent independent party or parties with access to details of the
subordinate CA's internal operations.
Each action requested above applies both to your root and to these third
Participation in Mozilla's root program is at our sole discretion, and
we will take whatever steps are necessary to keep our users safe.
Nevertheless, we believe that the best approach to safeguard that
security is to work with CAs as partners, to foster open and frank
communication, and to be diligent in looking for ways to improve. Thank
you for your participation in this pursuit.
Module Owner of Mozilla's CA Certificates Module
I presume that this is intended to communicate that "RFC5280 x509
dNSName name constraints, marked critical" is the only approved
approach, short of separate proposal and approval via this list.
> b) Send a complete list of all third parties along with links to each of
> their corresponding Certificate Policy and/or Certification Practice
Send where? If not this list, will it be forwarded to this list?
> and provide public attestation of their conformance to the
> stated verification requirements and other operational criteria by a
> competent independent party or parties with access to details of the
> subordinate CA's internal operations.
This seems like a clear (and welcome) change in policy, requiring that
RAs and SubCAs be audited. Is this a correct interpretation?
Some CAs have implemented software that checks constraints on name (not
marked critical), key usage, and/or enhanced key usage. The CA's
software won't issue a certificate for a request that violates the
constraints. For instance, some CAs have sub-CAs who are not allowed to
issue SSL certs, so they have implemented their own software to check
>> CAs are to respond to my Mozilla email address. The information that CAs
>> send to me in response to this communication will not be forwarded to
>> this list unless they specifically give me permission to do so.
> Doesn't this defeat the purpose of disclosure and work against the
> spirit of this list?
Mozilla's CA Certificate Policy has not yet been updated to require CAs
to publicly disclose their sub-CAs. Those updates to the policy are
still in draft form and under discussion.
There are some CAs with current contractual obligations that prevent
them from meeting the drafted/proposed updates to Mozilla's CA
The action items in our communication require prompt response that will
not wait until contracts and Mozilla's CA Certificate Policy can be updated.
>>>> and provide public attestation of their conformance to the
>>>> stated verification requirements and other operational criteria by a
>>>> competent independent party or parties with access to details of the
>>>> subordinate CA's internal operations.
>>> This seems like a clear (and welcome) change in policy, requiring that
>>> RAs and SubCAs be audited. Is this a correct interpretation?
>> Third-party organizations that can directly cause the issuance of
>> certificates must either constrained or audited.
> This differs from WorkInProgress InclusionPolicy #9, which says that
> SubCAs must be constrained or publicly disclosed. As I said, I welcome
> the audit requirement. However, I don't want to lose the disclosure
> requirement along the way.
See above. The disclosure discussion will continue later when we resume
discussions about updating Mozilla's CA Certificate Policy.