CA/Application Verification

From MozillaWiki
< CA
Jump to: navigation, search

This page provides information about the evaluation of a CA's root inclusion or change request. See the Application Process Overview for the list of the steps in the application process.

Information Verification

In this phase, a representative of Mozilla or another Root Store Member of the Common CA Database (CCADB) will review and confirm that the information has been provided through the CCADB. They will check to make sure that all required information has been provided. They may ask for further information if it is needed. The duration of this phase depends on the completeness of the information provided in CCADB, documentation uploaded to Bugzilla, and the CA's responsiveness in providing further information when asked for it.

The person conducting initial information verification uses the CCADB to check the completeness of information about:

  • the CA owner,
  • the CA's auditor,
  • annual audits and auditor's key generation report(s),
  • the CA's policy and practices documentation, and
  • the root certificates themselves.

Important: The Mozilla representative should deny the root inclusion request during Information Verification when they are aware that the applying CA operator has engaged in Unacceptable Behavior or a collection of the Concerning Behaviors.

For each root certificate under consideration, the reviewer will confirm that information has been populated in the CCADB.

  1. For each root certificate, review:
    • Explanation of purpose
    • Root download URL
    • URL for full CRL (or JSON array constituting full CRL)
    • PKI Hierarchy (see below for specific items requiring Detailed Review)
    • For TLS server certificates, confirm whether the root certificate has been tested using:
    • For the email trust bit, a Mozilla representative will download the S/MIME certificate(s) from Bugzilla and check the chaining and root information.
  2. Review and verify that all relevant parts of the CA's Compliance Self-Assessment have been completed. The Compliance Self-Assessment is used to review the CA's policies and practices during the Detailed Review, explained below.
  3. Review audit documents to make sure that requirements are met.
    • Make sure the audit isn’t more than a year old.
    • Confirm that there is a URL link to an auditor's report for the root key generation event.
    • Determine the frequency at which any audit(s) for subordinate CAs are done.
    • Verify that the audit was performed by an independent third party.
    • Verify that the audit covers the practices and requirements for the trust bits requested.
    • Review the audit report to flag any issues noted in the report.
    • Do an independent verification of the audit when the report is provided by or posted by the submitter, rather than being posted on the auditor's site or the CPA Canada Webtrust site.
      • Look on the internet to verify that the auditor meets the policy requirements, and to find contact information for the auditor.
      • Using the contact information found on the internet, verify the authenticity of the report by inquiring with the auditor whether the report was issued by them and that the contents match the audit report that they issued.

A Mozilla representative will check for completeness of any additional, Mozilla-specific requirements.

Once all this data has been verified, Mozilla or a CCADB representative will update the whiteboard section in the bug to indicate that the request is ready for detailed review of the CA's documentation and public discussion.

Detailed Review

The detailed review phase occurs simultaneously with the public discussion phase. A representative of Mozilla, a Root Store Member of the CCADB, or of the Community (as agreed by a Mozilla representative) thoroughly reviews the CA’s documents and audits, existing bugs, and other public information sources such as crt.sh. Compliance with the Mozilla Root Store Policy, applicable CA/Browser Forum guidelines, and applicable audit criteria is assessed and deviations are noted. The findings from such reviews are summarized presented during public discussion.

Depending on the nature of the findings, the reviewer may choose to list some or all of them in the bug or in the CCADB discussion and give the CA the opportunity to address them (typically by updating documents or providing additional information).

CP/CPS Review

The CA's Compliance Self-Assessment is used to guide the detailed review of the CA's CP, CPS, or combined CP/CPS. (The Compliance Self-Assessment is a more comprehensive review than the list provided below.)

Review the CP and CPS or combined CP/CPS and compare them with the CA's responses in the Compliance Self-Assessment, including:

  • A statement that gives precedence to applicable CA/Browser Forum requirements;
  • Text that demonstrates the CA verifies all information to be included in certificates, as required by Mozilla's Root Store Policy and the CA/Browser Forum's Baseline Requirements;
  • Evidence that the CA follows Mozilla's required or recommended practices;
  • Instances where the CA might use forbidden or problematic practices;
  • A statement about the frequency of update for the CRLs for end-entity certificates chaining to the root; and
  • A statement about the maximum time until OCSP responders are updated to reflect end-entity revocation (if OCSP is enabled).

All documents supplied as evidence must be publicly available and must be addressed in any audit. Any substantial omissions submitted afterwards may need to be confirmed by an auditor, at Mozilla's discretion.

PKI Hierarchy Review

Review CA hierarchy information provided for each root (preferably in the form of both a diagram and a description).

  1. Make sure that there is a clear list and/or description of the internally operated subordinate CAs chaining to the root. For internally-operated subordinate CAs the key is to confirm that their operation is addressed by the relevant CP/CPS, and that any audit covers them as well as the root.
  2. Make sure there is a clear list and/or description of the subordinate CAs that are operated by third parties. Make sure there is a clear general description and an explanation as to how the CP/CPS and audits ensure the third parties are in compliance with our policy requirements as per the Subordinate CA Checklist.
    • Verify that contractual arrangements require third-party subordinates to operate in accordance with a CP/CPS that meets applicable requirements.
    • Investigate applicable technical arrangements on subordinate CAs, including EKUs and name constraints, pathlength constraintes that don't allow subordinates to create their own subordinates, etc.
    • Determine the extent and nature of audits performed against subordinate CAs, including whether or not subordinate CAs are included within the scope of any audit(s) done against the root CA, whether or not subordinate CAs are subject to third-party audits independent of any audit(s) done against the root CA, and whether or not you perform your own audits of subordinate CAs.
  3. Determine if there are any other root CAs that have issued cross-signing certificates for this root CA.

EV Enablement Review

For requests to enable a root so that EV certificates may be issued under that root:

  1. Verify the presence of the CA/Browser Forum's EV policy OID (2.23.140.1.1).
  2. Make sure the CP/CPS incorporate (directly or by referenced) the EV Guidelines as published by the CA/Browser Forum.
  3. Make sure there have been audits within the past year for both EV and non-EV TLS certificate issuance
  4. If any of the subordinate CAs that are operated by third-parties are or will be EV enabled, refer to the EV guidelines and make sure there are EV audit statements for them.

Public Discussion

Mozilla's root inclusion process occurs publicly, and anyone may participate. We therefore include in our evaluation process a six-week period for public comment during which interested parties may review the information the CA supplied, ask additional questions regarding the CA, and provide their opinions on whether the request should be approved or not.

For Mozilla, the public discussion process occurs in two steps. At the end of the six-week public discussion process, we will make a preliminary determination as to whether the request will be approved or not, based on the information supplied and the resolution of any new issues raised during public discussion.

Following the six-week discussion period, we announce a one-week "last-call" period, during which interested parties may make final comments. And after that phase, we will make a final decision by updating the request in Bugzilla.

Who participates in the public discussions?
Members of the Mozilla community volunteer their time to review CA inclusion requests and provide their feedback. Participants should have knowledge of PKI, business practices, and policies. The more participants contributing to each discussion, the better the discussion will be in regards to ferreting out issues, helping the requester to improve their practices, and bringing the discussion to closure.

Note: If you have not contributed to a discussion before, wait no more! The more you contribute to discussions, the more you establish yourself as a knowledgeable and objective reviewer. Then, when there is a request that you are particularly interested in providing feedback on, your contributions will be even more effective. Additionally, if you are a CA with a request in the queue, participating in other discussions is a great way to learn the expectations and be prepared for the discussion of your request.

What do reviewers look for?
Reviewers of CA inclusion requests look for anything which could be of concern to Mozilla.

  • Review the CP/CPS documents to determine if they are sufficiently detailed, and meet the requirements of Mozilla's CA Policy and the CA/Browser Forum's Baseline Requirements.
  • Are all items listed in the Mozilla Root Store Policy addressed?
    • In particular, are there effective controls for certificate issuance and auditing of the same, which include:
      • Verification of domain control for webserver certificates
      • Verification of email address control for email certificates
  • Are the Recommended Practices followed?
  • Are there any Problematic Practices?
  • Are there previous recommendations that should be taken into consideration in this case?
  • Are there any potential risks that should be investigated?

Note: The official position of Mozilla might be different than the recommendations and suggestions of the reviewer. Reviewers are encouraged to contribute their recommendations and suggestions to the discussions. A representative of Mozilla will state when the official position of Mozilla differs from what has been posted in a discussion.

Where do the discussions take place?
Public discussions about root inclusion and change requests take place in the CCADB public mailing list.

Will my input be viewed as representing my employer?
A representative of the CA whose root inclusion request is being discussed must clearly represent their employer and must promptly respond directly in the discussion thread to all questions that are posted.

All other contributors to the discussion may choose between representing their employer or not. When you post your input into the discussion, you may choose to use a non-work-related email address and/or add a note in your signature stating that the views/comments posted therein are of your opinion only, and do not represent the views/opinions of the company you work for. On the other hand, some contributors prefer to use their work email address and provide their input as an employee representing their employer. It’s up to you.

How long does a discussion take?
The discussion period is six weeks long.

How can you help?

You can help by reviewing and providing your feedback in each public discussion of root inclusion requests, or by asking a colleague to do so.

For each discussion for a CA that is new to Mozilla's program, there should be input from at least two people who have reviewed and commented on the request. The comment can be questions, requests for clarification, or statements about items that you find concerning with respect to how the CA follows Mozilla's Root Store Policy. The comment can also be as simple as “I have reviewed this request and find nothing of concern” (if that is indeed the case).

Discussion on Public List at CCADB.org

To begin this phase, a representative of Mozilla or one of the other Root Store Members of the CCADB will create a new discussion thread in the CCADB public mailing list and will post information to the associated bug that the public discussion has begun.

Here is how a typical discussion proceeds:

  1. A Mozilla or CCADB representative starts the discussion by providing a summary of the request, and a summary of the information about the CA's practices.
  2. People from the Community reply in the discussion to ask questions and comment on the request.
  3. A representative of the CA replies to the questions and comments in the discussion thread. This may result in further discussion. Others from the Community may add their opinions and ask more questions.
  4. Once the question/answer discussions have begun to reach conclusions, then a representative of the CA may propose changes to make to the CP/CPS to address the concerns. This may result in further discussion.
  5. After the discussions have resulted in a clear set of things to update in the CP/CPS and possibly operational practices, then the Mozilla or CCADB representative will close the discussion and track the action items in the bug. In some circumstances, the CA may have to complete action items after the six-week discussion period. Then the Mozilla representative will review and confirm whether the action items have been completed, and then the Mozilla representative may start a second round of discussion.

CAs are expected to participate directly in all discussions, by responding to questions raised in the public mailing list and/or posting comments to the bug. The discussion is public, so please ensure that any information provided is not proprietary or confidential. The more active CAs are in responding to inquiries within the discussion, the more productive the discussion will be.

At the end of the first public discussion phase, the Mozilla representative or representative of a CCADB Root Store Member will post a summary about the results of the discussion and any open action items. Technical concerns, information about subordinate CAs (particularly those operated by third-parties), and potentially problematic practices will be specifically stated. The resulting information will vary depending on what issues or items of note have been found.

If there are no open issues or action items after the first discussion period, and there is general agreement that the CA complies with our policy requirements, then the Mozilla representative will post a recommendation in the bug. The final decision on whether to include the root certificate will be at Mozilla's discretion.

Response to public discussion

If there are follow-up actions to be performed during the first public discussion phase, then the Mozilla representative may decide to postpone further public discussion until the CA addresses particular issues or provides additional information. The duration of this postponement is dependent on how long it takes to complete the action items. The CA should post updates to the action items in the bug. When the action items are completed, and verified by a Mozilla representative, the Mozilla representative may re-start public discussion.

Last Step in Public Discussion

In the final step of public discussion, a Mozilla representative will announce a final, "last call" discussion period of one week. Interested members of the general public may make final objections to Mozilla's announced intention. If there are no open issues or action items, and if there is general agreement that the CA complies with our policy requirements, then at Mozilla's discretion, a Mozilla representative will indicate in the bug whether the CA's request has been approved or denied.

NSS and PSM Bug Creation

For root CA certificates approved for inclusion, the Mozilla representative will create a new Bugzilla bug. (Example: https://bugzilla.mozilla.org/show_bug.cgi?id=1303377)

The new bug number will be noted in a comment in the original bug, and the original bug will be marked as being blocked by the new bug. Make sure that the CA's representative is on the CC list of the new bug, so that they will be notified if problems or questions that arise during build and test.

For root CA certificates approved for EV, the Mozilla representative will create another bug for the necessary changes to be made to the Mozilla Personal Security Manager (PSM). (Example: https://bugzilla.mozilla.org/show_bug.cgi?id=1303383)

Root inclusion and change requests are usually grouped and done as a batch about every 3 months. At some point within about 3 months of the NSS bug being created, a test build will be provided and the NSS bug will be updated to request that the CA test it. Everyone CC'd on the bug will get notification via email when that happens.

This work is distributed across many different people, and many different decision factors are considered in determining which version of Firefox will pick up a new version of NSS. This process cannot be expedited for any CA. The only time this process will be expedited is when there is a serious Security Concern.

After the root inclusion or change is confirmed to be part of a release of Firefox, a Mozilla representative will update the Whiteboard status of the bug, and the corresponding information in the Common CA Database.

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