CA/Application Process: Difference between revisions

From MozillaWiki
< CA
Jump to navigation Jump to search
(Added or moved information about the root inclusion process)
 
(82 intermediate revisions by 5 users not shown)
Line 1: Line 1:
When distributing Mozilla and related software Mozilla includes a default set of X.509v3 certificates for various Certification Authorities (CAs). The certificates included by default are marked as being "trusted" for various purposes, so that Mozilla can use them automatically to verify certificates for SSL servers, S/MIME email users, and code signing without having to ask Mozilla users for further permission or information.
The internet secure communications system requires Certification Authorities (CAs) - parties trusted to attest to the identity of websites. Mozilla products ship a default list of CA certificates, which may change with each security patch or new version of the product. The following pages explain how the default list of CA certificates is managed.


The purpose of this wiki page is to describe Mozilla CA Certificates Module and provide general background information regarding how Mozilla and related software (e.g., Firefox, Thunderbird, Camino, etc.) uses certificates.
= Who May Apply =
An official representative of the CA must make the formal request for inclusion or update of their CA's root certificates. If you would like to see a particular root certificate included in Mozilla products, then please contact the CA who operates that root certificate.


=== What are certificates? ===
CAs must carefully consider whether their root certificate needs to be [[CA/Included_Certificates|directly included in Mozilla's root store]] or if it would be better to be a [[CA/Intermediate_Certificates|subordinate CA of an already-included CA]].
Certificates are used in the context of "public key" cryptography. More specifically, certificates are digitally signed data items combining a public key used for some purpose (e.g., enabling a web server to accept SSL connections) with information about the entity associated with the public key. Certificates are used in at least three functions within Mozilla and related software:
* when a user uses the software to connect to an SSL-enabled web server or other SSL-enabled servers, (e.g., an IMAP mail server)
* when a user uses the software to read digitally signed email from another user
* when a user uses the software to download and execute digitally signed executable code (e.g., a digitally-signed Java applet)


In public key cryptography the communicating entities (e.g., web servers or user email programs) each have a unique pair of cryptographic keys, a "private" key that is kept secret and a "public" key that is made known to others. In the various cryptography-based functions in Mozilla mentioned above public keys are not used in their "raw" form but rather are encapsulated in "certificates". (These are often referred to as "X.509 v3 certificates", from the name of the technical standard defining the certificates' format.)
[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's CA Certificate Policy] states:  "We will determine which CA certificates are included in Mozilla's root program based on the risks of such inclusion to typical users of our products." Including any CA carries a level of risk that is measured, in part, by the past record of the CA operator (or lack thereof), their responsiveness (or lack thereof), and the level of competence and precision demonstrated by the CA operator during the inclusion process. In some cases, a better alternative is to be a [[CA/Intermediate_Certificates|subordinate CA]] of a CA that is already [[CA/Included_Certificates|included in Mozilla's root store]].  


As noted above, a certificate is a digitally signed bundle of data that includes both the public key for a given entity and various pieces of information about that entity; for example, the certificate for a secure web server includes the domain name of the server, a certificate used for secure email includes the email address of the sending user, and the certificate for a signed Java applet includes the name of the organization or individual who developed and/or distributed the applet.
It is the responsibility of new applicants to justify why their root certificate needs to be included in Mozilla's root store and to explain why the inclusion will not introduce undue risk for Mozilla users. See the Mozilla wiki page [[CA/Quantifying_Value|"Quantifying Value: Information Expected of New Applicants"]].  


Digitally signing a certificate (or any other data) is done using some entity's private key. More specifically, certificate data are signed by taking the bit string representing the data and putting it through a specially-designed "hashing" operation that generates a small fixed-length bit string, and then encrypting that new bit string (the "hash") using some entity's private key to generate the "signature". Hash functions are mathematically designed to ensure that different bit strings will generate different hash values, and public/private key pairs and algorithms are designed to ensure that data encrypted by a private key can be easily decrypted only by the corresponding public key. (In both cases these guarantees are not absolute, but are as good as skilled cryptographers can make them.)
Having a root certificate you control included in Mozilla's root store is a major ongoing responsibility; it is '''not''' a one-time effort. It means that, in the normal case, the world will trust you to correctly issue digital certificates identifying any website and/or email address. There will be associated costs in maintaining the required security infrastructure, keeping up-to-date with evolving technical and procedural requirements, and conducting audits on an annual basis. After a CA operator has a CA certificate included in Mozilla's root store, it is expected that the CA operator will continue to be aware of ongoing discussions in [https://groups.google.com/a/mozilla.org/g/dev-security-policy the Mozilla dev-security-policy list] and [https://groups.google.com/a/ccadb.org/g/public the CCADB discussion group] and updates to [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy]. The CA is required to submit regular program updates to Mozilla via the [https://ccadb.org/ Common CA Database (CCADB)], including annual updates to their policy and audit documentation.


Someone receiving a copy of the data and its signature can verify the data and signature by decrypting the signature using the entity's public key to recover the original hash value, separately hashing the data to generate a new hash value, and then comparing the original hash value and the new hash value. If the recovered hash value and the newly-generated hash value match then the receiver can be reasonably sure that the data received are the same as the data as originally signed, and that the entity whose public key was used to verify the signature is the same entity that did the signing (with the corresponding private key).
= Process Overview =
This process is used to request any of the following:
* Include a new root certificate, even if the CA already has root certificates included in Mozilla's root store
* Include a renewed version or re-issued version of an already-included root certificate
* Enable EV treatment for an already-included root certificate
* Turn on additional trust bits for an already-included root certificate


Approval of one root certificate does '''not''' imply that other root certificates owned by the same CA operator would be accepted.


=== What are CAs? ===
It typically takes up to '''two years''' for a new CA to make it from one end of the process to the other. If the CA does not provide requested information in a timely manner, then the application can take even longer, or may be cancelled.


Briefly, a Certification Authority or CA is an entity that digitally signs other entities' certificates. (A Certification Authority is also sometimes referred to as a Certificate Authority.)
The overall steps of the CA certificate inclusion and update process are as follows. There are [[CA/Bug_Triage#Root_Inclusion.2FChange_requests_and_EV_Treatment_Enablement_Requests|Bugzilla Bug Whiteboard tags]] corresponding to many of these steps.


As mentioned previously, a certificate contains an entity's public key, and is digitally signed using some entity's private key. A "self-signed" certificate is one in which the private key used to digitally sign the certificate is the private key corresponding to the public key in the certificate itself; in other words, the entity signing the certificate is the same entity whose public key is in the certificate (hence the term "self-signed").
'''Parts of this root inclusion process are also set forth on the [https://www.ccadb.org/cas/public-group#root-inclusion-public-discussion CCADB website].'''


Verifying the digital signature on a self-signed certificate can then be done using the public key in the certificate itself, as described above. If the signature is valid then we can be reasonably sure that the public key in the certificate has not been corrupted in any way, and that any other data found in the certificate is as originally put there by the entity associated with the certificate and public key.
# A representative of the CA
#* Must review [[CA/Root_Inclusion_Considerations|Mozilla's Root Inclusion Considerations]] before starting this process. Mozilla will reject root inclusion requests when the applying CA has engaged in any of the unnaceptable behaviors, or an aggregate of the concerning behaviors or warning signs.
#* [[CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request|Submits a request for root inclusion]] in both Bugzilla and in the CCADB (a representative of Mozilla issues a [https://ccadb.org Common CA Database (CCADB)] license to the [[CA/Information_Checklist#CA_Primary_Point_of_Contact_.28POC.29|Primary Point of Contact]] for the CA), and
#* [[CA/Information_Checklist | Provides information about the CA and operation of the root certificate(s).]]
#** All information provided by the CA must be publicly available.
#** If the CA contracts to another organization to help with the root inclusion request, the representative of the CA must clarify that relationship in their request, and must provide clear information about who the ongoing [[CA/Information_Checklist#CA_Primary_Point_of_Contact_.28POC.29|points-of-contact]] will be for the CA.
#** New Applicants must submit a [[CA/Quantifying_Value|Value Justification]].
#** All Applicants must have a [https://www.ccadb.org/cas/self-assessment CCADB Self Assessment] that is not older than 365 days.
# A representative of Mozilla or another Root Store Member of the CCADB [[CA/Application_Verification#Information_Verification|confirms all information was provided by the CA]].
#* Refer to [https://www.ccadb.org/cas/public-group#root-inclusion-public-discussion "Prerequisites" to public discussion], which is conducted on the [https://groups.google.com/a/ccadb.org/g/public CCADB Public discussion list].
# [[CA/Application_Verification#Public_discussion|Public discussion]] for a six-week period begins on the [https://groups.google.com/a/ccadb.org/g/public CCADB discussion list]. If no concerns are raised during that time period, then the discussion may close and the request may proceed to the "last call" and approval phases.
# During the public-discussion phase, a representative of Mozilla, another Root Store Member of the CCADB, or the Community (as agreed by a Mozilla representative) may perform a [[CA/Application_Verification#Detailed_Review|detailed review of the CA’s CP/CPS and audit documents]]. During this phase, the CA may be required to update their CP/CPS and audit documents to become fully aligned with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy].
#* [[CA/CPS_Review|Previous detailed reviews of CA CP/CPS and audit documents]]
# A representative of the CA responds to questions and concerns posted during the public discussion of the CA's request. The CA also completes action items resulting from the public discussion, which may include updating processes, documentation, and audits.
#* If concerns are raised during the discussion about the CA having engaged in any [[CA/Root_Inclusion_Considerations#Unacceptable_Behavior|Unacceptable Behaviors]] or a collection of the [[CA/Root_Inclusion_Considerations#Concerning_Behavior|Concerning Behaviors]], then the representative of the CA shall provide a public response to https://wiki.mozilla.org/CA/Root_Inclusion_Considerations.
#* A discussion may be extended beyond the initial comment period if concerns or questions are raised that require further attention.
#* A discussion may be put on hold, pending a CA action item, such that the discussion may continue as soon as the CA has provided the requested information.
#* A representative of Mozilla or another Root Store Member of the CCADB confirms the completion of the action items and continues public discussion if needed.
# At the end of the six-week public discussion period, a representative of Mozilla or the Root Store Member who initiated the public discussion provides a summary within 5 business days noting any objections or open questions that did not receive a response from the CA owner and states the public discussion period has concluded.
#*  If there are outstanding issues that need to be addressed (e.g., a need for further information, or concerns about CA practices) then the request may be closed, moved back to the Information Verification phase, or put on hold pending future discussion after the CA has addressed the concerns.
# Following public discussion, a representative of Mozilla will post on the [https://groups.google.com/a/mozilla.org/g/dev-security-policy Mozilla dev-security-policy list] and indicate Mozilla's intent to either approve or reject the inclusion request.
#* This is the last call for objection. After one week, if no further questions or concerns are raised, then a representative of Mozilla may approve the request, by stating so in the bug.
# A representative of Mozilla [[CA/Application_Verification#NSS_and_PSM_Bug_Creation|creates a bug requesting the actual changes]] in NSS (and PSM for EV treatment).
# A representative of the CA confirms that all the data in the NSS bug is correct.
# A representative of Mozilla creates a patch with the new CA certificates and trust bit settings, and provides a special test version of Firefox.
#* Changes to NSS regarding CA certificate applications are usually grouped and done as a batch when there is either a large set of changes or about every 3 months.
# A representative of the CA [[CA/Application_Instructions#Test|tests the code changes]] using the test version of Firefox and confirms (by adding a comment in the NSS bug) that the correct certificate(s) is/are included and that the trust bits are correctly set.
# A representative of Mozilla requests that another Mozilla representative review the patch.
# A representative of Mozilla adds (commits) the patch to NSS, then closes the NSS bug as RESOLVED FIXED.
# Mozilla products move to using a version of NSS which contains the certificate changes. This process is mostly under the control of the release drivers for those products. See [https://wiki.mozilla.org/RapidRelease/Calendar Mozilla's Release Calendar.]
# The CA enters data into the CCADB for:
#* All certificates that are capable of being used to issue new certificates, and which directly or transitively chain to their root certificate(s) included in Mozilla’s Root Store that are not technically constrained as described in section 5.3 of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited Mozilla's Root Store Policy]; and
#* Revoked intermediate certificates that chain to their certificate(s) included in Mozilla's Root Store.


It is also possible for a certificate to be signed using some other private key belonging to a third party (i.e., an entity other than the one whose certificate it is). In this case verifying the information in the certificate requires having the public key for that third party. The third party's public key can itself be distributed in the form of a certificate, and that certificate can in turn by signed either by the third party itself (as a self-signed certificate) or by some other party entirely.
= Ways You Can Help =


In the scheme used by Mozilla, certificates for entities such as web servers, email users, or code developers are typically not self-signed but rather are signed by third parties (organizations or individuals) known as "Certification Authorities" or "CAs" for short. (CAs are in turn considered to be part of what is commonly referred to as a Public Key Infrastructure or PKI — although in fact it is possible to have a PKI that does not use CAs.) By signing the data in certificates CAs are assumed to be in some way vouching for the information contained in the certificate data.
Our most pressing need is help with [[CA/Application_Verification#Public_Discussion|reviewing and contributing to the public discussions]] of CA applications. Public discussions about root inclusions and most change requests take place in the [https://groups.google.com/a/ccadb.org/g/public CCADB public mailing list].
 
For example, a certificate used for a secure web server normally contains the domain name used to connect to the web server, and by signing such a certificate a CA is assumed to be vouching for the fact that the entity operating the web server (the entity that controls the server's private key corresponding to the public key in the certificate) actually controls the domain name associated with the server. Similarly, a certificate used for secure email should contain the email address of the person or organization that controls the corresponding email account, with the CA signing the certificate assumed to have verified that that is the case, and a certificate used for a digitally signed applet (or other executable code) should contain the name of the developer or distributor of the applet (again, assumed to be verified by the CA).
 
Verifying a typical web server, email user, or developer certificate then requires having the public key for the CA that signed the certificate. The CA's public key is itself distributed in the form of a certificate; this "CA certificate" is in turn digitally signed either by some other CA or by the CA itself (as a self-signed certificate). In the former case the CA is referred to as an "intermediate" CA; in the latter case the CA is referred to as a "root" CA, and its certificate is a "root CA certificate".
 
In general it is possible to have multiple root CAs; each root CA can then "issue" certificates directly for web servers, email users, developers, etc., by digitally signing the data in those certificates, or can issue certificates to one or more intermediate CAs, which then issue certificates in turn.
 
Note that in theory CAs are not necessary in order to support cryptography-based functions like secure web browsing, etc., and in fact there are systems like PGP that do not use CAs in the sense defined above. (PGP uses a separate "web of trust" system in which PGP users sign each others' keys.) However the main cryptography-based functions in Mozilla — secure web browsing, secure email, and digitally signed code objects — do assume the use of CAs, including root CAs.
 
=== Why does Mozilla include a default set of CA certificates? ===
 
Mozilla as distributed includes various CA certificates by default, in order to reduce the amount of configuration users have to do before they can use Mozilla for these cryptographic-based functions.
 
As discussed in the answer to the previous question, in order to verify a certificate for a web server, email user, or code developer, Mozilla must thus have the certificate for the CA that issued (i.e., digitally signed) the certificate being verified. If the CA is an intermediate CA then Mozilla must also have the certificate for the CA that issued the intermediate CA's certificate, in order to verify that certificate as well. This other CA may be a root CA or yet another intermediate CA; in the latter case yet another CA will be involved, and so on.
 
Mozilla continues verifying certificates until it comes to a point where it needs a root CA certificate, corresponding to the root CA that issued the original web server, etc., certificate or that issued an intermediate CA's certificate. Since root CA certificates are self-signed, Mozilla can verify such a certificate using the public key in the root CA certificate itself, and if that verification completes successfully then the process is done.
 
In some cases Mozilla can get the CA certificate(s) from the same place and in the same way as it got the original certificate; for example, if a web server presents its own certificates to Mozilla then it could also present the needed CA certificate(s) as well, including the root CA certificate and any intermediate CA certificates. (Such a set of linked certificates is known as a "certificate chain".)
 
However it is also convenient for Mozilla to keep its own copies of certificates, including root CA certificates in particular. Among other things, Mozilla cam mark a given root CA certificate as being valid for verifying certain types of certificates, and as not being valid to verify other types of certificates.
 
For example, a particular root CA may issue certificates only for web servers, not for email users or code developers; in the Mozilla certificate database this root CA's certificate could be marked as being valid only for verifying web server certificates. If Mozilla receives a email user certificate issued by this root CA (or by an intermediate CA under the root CA) it would then raise an error condition and alert the user; on the other hand web server certificates issued by the root CA (or an intermediate CA under it) would be verified by Mozilla without error and with no need for user intervention.
 
This process of marking root CA certificates as being valid for verifying certain types of certificates is commonly known as "trusting" the root CA, and the special flags associated with each root CA certificate are known as "trust bits".
 
If Mozilla or related software did not already have a copy of a given root CA certificate then it would be unable to automatically determine whether certificates issued by that root CA (or subordinate CAs) should be accepted or not, and would have to prompt the user as to what to do. Most users don't know what CAs are or don't possess the necessary information to properly decide what Mozilla should do. To prevent these typical Mozilla users from having to deal with this issue, Mozilla and related software includes a pre-loaded set of default root CA certificates, with the trust bits set appropriately.
 
These pre-loaded root CA certificates are distributed with Mozilla and related software in the form of a shared library installed on users' systems along with the rest of the software executable code. They can therefore be updated when new versions of the software are release.
 
The pre-loaded CA certificates are included in the following files:
* Windows: libnssckbi.dll
* Unix, Linux, and other *nix variants: libnssckbi.so
* Mac OS X: Contents/MacOS/libnssckbi.dynlib
 
The pathnames above are for Firefox, and are relative to the directory in which the Firefox software is installed; the full pathnames depend on the operating system and the exact software in question.)
 
=== What is the Mozilla CA Certificate Policy? ===
 
add text here
 
=== Who decides which CA certificates to include in Mozilla products? ===
 
add text here
 
=== How does a root certificate get included in Mozilla products? ===
 
add text here
 
=== What if I don't trust a particular Certification Authority? ===
 
add text here

Latest revision as of 18:02, 29 August 2024

The internet secure communications system requires Certification Authorities (CAs) - parties trusted to attest to the identity of websites. Mozilla products ship a default list of CA certificates, which may change with each security patch or new version of the product. The following pages explain how the default list of CA certificates is managed.

Who May Apply

An official representative of the CA must make the formal request for inclusion or update of their CA's root certificates. If you would like to see a particular root certificate included in Mozilla products, then please contact the CA who operates that root certificate.

CAs must carefully consider whether their root certificate needs to be directly included in Mozilla's root store or if it would be better to be a subordinate CA of an already-included CA.

Mozilla's CA Certificate Policy states: "We will determine which CA certificates are included in Mozilla's root program based on the risks of such inclusion to typical users of our products." Including any CA carries a level of risk that is measured, in part, by the past record of the CA operator (or lack thereof), their responsiveness (or lack thereof), and the level of competence and precision demonstrated by the CA operator during the inclusion process. In some cases, a better alternative is to be a subordinate CA of a CA that is already included in Mozilla's root store.

It is the responsibility of new applicants to justify why their root certificate needs to be included in Mozilla's root store and to explain why the inclusion will not introduce undue risk for Mozilla users. See the Mozilla wiki page "Quantifying Value: Information Expected of New Applicants".

Having a root certificate you control included in Mozilla's root store is a major ongoing responsibility; it is not a one-time effort. It means that, in the normal case, the world will trust you to correctly issue digital certificates identifying any website and/or email address. There will be associated costs in maintaining the required security infrastructure, keeping up-to-date with evolving technical and procedural requirements, and conducting audits on an annual basis. After a CA operator has a CA certificate included in Mozilla's root store, it is expected that the CA operator will continue to be aware of ongoing discussions in the Mozilla dev-security-policy list and the CCADB discussion group and updates to Mozilla's Root Store Policy. The CA is required to submit regular program updates to Mozilla via the Common CA Database (CCADB), including annual updates to their policy and audit documentation.

Process Overview

This process is used to request any of the following:

  • Include a new root certificate, even if the CA already has root certificates included in Mozilla's root store
  • Include a renewed version or re-issued version of an already-included root certificate
  • Enable EV treatment for an already-included root certificate
  • Turn on additional trust bits for an already-included root certificate

Approval of one root certificate does not imply that other root certificates owned by the same CA operator would be accepted.

It typically takes up to two years for a new CA to make it from one end of the process to the other. If the CA does not provide requested information in a timely manner, then the application can take even longer, or may be cancelled.

The overall steps of the CA certificate inclusion and update process are as follows. There are Bugzilla Bug Whiteboard tags corresponding to many of these steps.

Parts of this root inclusion process are also set forth on the CCADB website.

  1. A representative of the CA
  2. A representative of Mozilla or another Root Store Member of the CCADB confirms all information was provided by the CA.
  3. Public discussion for a six-week period begins on the CCADB discussion list. If no concerns are raised during that time period, then the discussion may close and the request may proceed to the "last call" and approval phases.
  4. During the public-discussion phase, a representative of Mozilla, another Root Store Member of the CCADB, or the Community (as agreed by a Mozilla representative) may perform a detailed review of the CA’s CP/CPS and audit documents. During this phase, the CA may be required to update their CP/CPS and audit documents to become fully aligned with Mozilla's Root Store Policy.
  5. A representative of the CA responds to questions and concerns posted during the public discussion of the CA's request. The CA also completes action items resulting from the public discussion, which may include updating processes, documentation, and audits.
    • If concerns are raised during the discussion about the CA having engaged in any Unacceptable Behaviors or a collection of the Concerning Behaviors, then the representative of the CA shall provide a public response to https://wiki.mozilla.org/CA/Root_Inclusion_Considerations.
    • A discussion may be extended beyond the initial comment period if concerns or questions are raised that require further attention.
    • A discussion may be put on hold, pending a CA action item, such that the discussion may continue as soon as the CA has provided the requested information.
    • A representative of Mozilla or another Root Store Member of the CCADB confirms the completion of the action items and continues public discussion if needed.
  6. At the end of the six-week public discussion period, a representative of Mozilla or the Root Store Member who initiated the public discussion provides a summary within 5 business days noting any objections or open questions that did not receive a response from the CA owner and states the public discussion period has concluded.
    • If there are outstanding issues that need to be addressed (e.g., a need for further information, or concerns about CA practices) then the request may be closed, moved back to the Information Verification phase, or put on hold pending future discussion after the CA has addressed the concerns.
  7. Following public discussion, a representative of Mozilla will post on the Mozilla dev-security-policy list and indicate Mozilla's intent to either approve or reject the inclusion request.
    • This is the last call for objection. After one week, if no further questions or concerns are raised, then a representative of Mozilla may approve the request, by stating so in the bug.
  8. A representative of Mozilla creates a bug requesting the actual changes in NSS (and PSM for EV treatment).
  9. A representative of the CA confirms that all the data in the NSS bug is correct.
  10. A representative of Mozilla creates a patch with the new CA certificates and trust bit settings, and provides a special test version of Firefox.
    • Changes to NSS regarding CA certificate applications are usually grouped and done as a batch when there is either a large set of changes or about every 3 months.
  11. A representative of the CA tests the code changes using the test version of Firefox and confirms (by adding a comment in the NSS bug) that the correct certificate(s) is/are included and that the trust bits are correctly set.
  12. A representative of Mozilla requests that another Mozilla representative review the patch.
  13. A representative of Mozilla adds (commits) the patch to NSS, then closes the NSS bug as RESOLVED FIXED.
  14. Mozilla products move to using a version of NSS which contains the certificate changes. This process is mostly under the control of the release drivers for those products. See Mozilla's Release Calendar.
  15. The CA enters data into the CCADB for:
    • All certificates that are capable of being used to issue new certificates, and which directly or transitively chain to their root certificate(s) included in Mozilla’s Root Store that are not technically constrained as described in section 5.3 of Mozilla's Root Store Policy; and
    • Revoked intermediate certificates that chain to their certificate(s) included in Mozilla's Root Store.

Ways You Can Help

Our most pressing need is help with reviewing and contributing to the public discussions of CA applications. Public discussions about root inclusions and most change requests take place in the CCADB public mailing list.

Retrieved from "https://wiki.mozilla.org/index.php?title=CA/Application_Process&oldid=1251680"