Mozilla is considering a change to the way that it handles certificates issued by externally operated sub-CAs in an effort to gain more control of how these CAs issue certificates and what those certificates can do.
The proposal would involve some new controls to help verify that certificates are using keys in the correct ways and aren’t abusing their position in the certificate chain.
“The proposal is that the EKU [extended key usage] would be specified in the intermediate certificates, and the crypto code would look up the certificate chain at the EKU extensions to make sure that the end-entity certificate is allowed to be used for that purpose. The old NSS code does this if the EKU extension is present in the intermediate certificate, but the new libpkix code doesn’t currently do this,” Mozilla’s Kathleen Wilson wrote in a message on a Google group about the proposed change. “I propose that we consider using EKU in this way and requiring it in Mozilla’s CA Certificate Policy for externally-operated subordinate CAs.”
The proposal sparked a long conversation among representatives of certificate authorities, some of whom questioned the idea of Mozilla requiring audits or other controls from companies that they don’t have any authority over. But Mozilla’s position is that CAs that want to be in its trusted root program need to conform to the rules it sets forth, and those may include the new constraints for externally operated subordinate CAs.
Specifically, Mozilla is asking that such subordinate CAs either be audited or have certain technical constraints placed on their usage of keys passed down from CAs farther up the chain.
“Each externally-operated subordinate CA that is not technically constrained must be publicly disclosed, along with the subordinate CA’s corresponding Certificate Policy or Certification Practice Statement and public attestation of the subordinate CA’s conformance to the stated certificate verification requirements and other operational criteria by a competent independent party or parties with access to details of the subordinate CA’s internal operations. The subordinate CA’s certificate verification requirements and operational criteria must satisfy the requirements of Mozilla’s CA Certificate Policy. The CA’s Certificate Policy or Certification Practice Statement must indicate where the list of publicly disclosed subordinate CAs may be found on the CA’s website,” the new proposed text reads. “For an externally-operated subordinate CA to be considered technically constrained, the subordinate CA certificate (and any intermediate certificates chaining up to that certificate) must include an Extended Key Usage (EKU) extension specifying the key usage of the certificates it can sign.”
The CA system has been a target of a lot of criticism in the last year or so, thanks mainly to a series of high-profile compromises of CAs such as DigiNotar and Comodo that resulted in fraudulent certificates being issued for a long list of domains. Those compromises led to a lot of public discussion about the structure of the CA system, the way in which its run and how easy it is for fraudulent or stolen certificates to end up in circulation. No major changes to the system itself have come from those conversations yet, but some of the browser vendors have been changing aspects of their root CA programs.
