mozilla / www.ccadb.org Goto Github PK

Some links are broken in http://ccadb.org/rootstores/how

1. Second bullet point in
   http://ccadb.org/rootstores/how#membership-requirements
   Agree to [Mozilla’s Common CA Database Agreement][CCADB-Agreement].

2. sixth bullet point in
   http://ccadb.org/rootstores/how#membership-application
   The following information for the person who has the authority to sign [Mozilla’s Common CA Database Agreement][CCADB-Agreement] on behalf of your organization:

3. Last sentence in
   http://ccadb.org/rootstores/how#membership-application
   [CCADB-Agreement]: /rootstores/mozilla-ccadb-agreement.pdf

Please add a new page to ccadb.org: https://ccadb.org/cas/request-access

The content for the new page is here:
https://docs.google.com/document/d/1QW2-7OeOVAU3D-68jgZon7Nd7fnpV6jivQwYclLpoyA/edit?usp=sharing

Then add a "Request Access" link for this new page to https://ccadb.org/cas
The link should go just below "Login to CCADB".

Then delete the "Requesting a License" section from https://ccadb.org/cas/getting-started.

Update the CCADB policy to specify the format for the dates and the certificate thumbprints, so that ALV will have a higher success rate. This has become more important now that ALV has been extended to intermediate certificate records.

The CCADB is using "CA Owner" instead of "CA" in many documents. This should be done in the CCADB Policy, too.

Please add the following section to https://ccadb.org/cas/intermediates
I think this new section should go above the 'Adding Intermediate Certificate Data' section.

Section Heading: Updating Audit Statements

Section Contents:
~~
All CAs are required to update the audit and CP/CPS information for their certificate hierarchies at least annually. CAs are expected to maintain their intermediate certificate records themselves and to directly enter the corresponding updated audit statements via the following instructions. Audit information for root certificate records must be provided via an Audit Case.

Note: If the audit statements for an intermediate certificate are the same as the certificate that signed it, then check the "Audits Same as Parent" checkbox instead of providing separate audit information.

1. Login to the CCADB.
2. Navigate to the intermediate certificate record. Here are some ways to do that:
   -- The "My Outdated Audit Statements for ICs" report has links to the intermediate certificate records. The report is available in the 'Reports' tab in the 'CA Community Reports' folder.
   -- Enter the name or SHA-256 fingerprint of the intermediate certificate into the 'Search' at the top of the window in the CCADB.
   -- Click on 'CA Owners/Certificates' tab, then in 'View:' select “Community User’s Intermediate Certs” and click on 'Go'.
3. Click on the 'Edit' button and enter the audit and CP/CPS information, then click on the 'Save' button.
4. Click on the 'Mass Update Audit/CP/CPS Data' button to apply changes to other intermediate certificates in the same hierarchy, if applicable.
   ~~

There has been confusion about the Audit Case process in regards to intermediate cert records. CAs keep wondering how to indicate which intermediate certs the Audit statements also apply to. So we need to update ccadb.org/cas/updates to clarify that the Audit Case process is only for the certificates that are directly included in the root stores, and that CAs must directly update the audit statements for their intermediate cert records.

Here's a possible way to handle this...

Update the first paragraph of ccadb.org/cas/updates to say:
All CAs are required to update the audit, CP, CPS and test website information for their certificate hierarchies at least annually. CAs are expected to maintain their intermediate certificate records <link to ccadb.org/cas/intermediates> themselves and to directly enter the corresponding updated audit statements <link to ccadb.org/cas/fields#audit-information>. This page describes the process for providing annual updates for the root certificates that are directly included in Root Stores.

Placeholder to record and collaborate on future enhancements to the incident reporting template...

1. Specify it's considered "good practice" to respond to incidents in Markdown, rather than attaching a PDF in response to the incident report table defined on CCADB.org
2. Consider including bulleted lists in the template to more directly address areas of interest (i.e., add considerations for whether issuance was stopped and the number of affected certificates)

... more to come.

In http://ccadb.org/cas/updates#instructions

Please:

• Replace both occurrences of ‘Add Root Cert For This Audit Info’ with 'Add Root Case'

• Change Step 6 to
  In the ‘Audit Case’ page, in the ‘Custom Links’ section and click on “List All Root Certs for This CA”. This information will be helpful while you create Root Cases to indicate which root certificates were in scope of your audit statements.

The second row of http://ccadb.org/cas/fields#audit-information needs to be updated. Probably best to change it to:
URL to an auditor's statement that the operation of this certificate has been audited according to Mozilla's Root Store Policy <link: https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#audit-criteria>.

Also, please add a row for Audit Period, with text:
For each Audit Statement provide the Audit Period Start Date and Audit Period End Date.
In a period‐of‐time audit, the Audit Period is the period between the first day (start) and the last day of operations (end) covered by the auditors in their engagement.
The period during which the CA issues Certificates SHALL be divided into an unbroken sequence of audit periods. An audit period MUST NOT exceed one year in duration.

The CCADB stores a couple of different types of "contact" records:

• Primary POC (1 or more): someone who is "authorized to speak for and to bind the CA that they represent."
• POC (0 or more): Another contact at that CA.
• Email Alias (1 or 2): defined as "more likely to continue working as personnel change".

All are per-organization values, and I don't believe any of them are published. However, this then leads to a question about which contacts should be used in what circumstances.

The Common CCADB Policy says:

"Notification of security and audit-related issues will be emailed to all POCs and the email aliases; CAs are advised to supply sufficient POCs that will enable them to respond to an issue promptly."

This is a bit of an administrative pain.

The proposal is that we change this to "email the primary POCs and CC the first email alias", to reduce the administrative burden on Root Stores.

Gerv

Please update http://ccadb.org/cas/updates#instructions to match the new workflow by replacing the current steps 7 through 14 with the following two steps.

7. Click on the ‘Add/Update Root Cases’ button to indicate which root certificates are covered in the audit statements. For each covered root certificate, check the boxes corresponding to the audit statements that apply. Then click on the "Apply Changes" button. This will create corresponding Root Cases.

8. If any of the root certificates covered by these audit statements can validate TLS/SSL certificates, then you need to also provide the URLs to the test websites. If the root certificate is enabled for EV treatment, then the TLS/SSL certs for the test websites must also be EV.
   ** Scroll down to the "Root Cases" section, or click on the "Root Cases" link near the top of the page.
   ** Click on the "Edit" link for the Root Case to modify.
   ** Enter the URLs to the test websites (valid, expired, and revoked)
   ** Click on the ‘Save’ button

In https://ccadb.org/resources#general

Please change these 3 links
http://ccadb-public.secure.force.com/mozilla/AllCertificateRecordsCSVFormat
https://ccadb-public.secure.force.com/mozilla/AllProblemReportingMechanismsReport
https://ccadb-public.secure.force.com/mozilla/AllCAAIdentifiersReport

to
https://ccadb-public.secure.force.com/ccadb/AllCertificateRecordsCSVFormat
https://ccadb-public.secure.force.com/ccadb/AllProblemReportingMechanismsReport
https://ccadb-public.secure.force.com/ccadb/AllCAAIdentifiersReport

We should add a section to https://www.ccadb.org/cas/incident-report that sets expectations about when and how frequently a CA should provide an update about their incident until it is fully resolved.
e.g. If the CA provides a timeline for when they will take action (and that is accepted) then they must provide an update by each date set out in their timeline.
Otherwise the CA should provide a weekly update until they have fully resolved the incident on their end and are just waiting for root store operators to request further actions, close the issue, or make other determinations...

So I noticed someone mistakenly duplicated the content in readme.md file
The content-
www.ccadb.org
Prerequisites
Installation and
Running and testing locally
are duplicate 😂

It seems important to secure this site with HTTPS. @flamingspaz did this for community & participation static sites using Terraform, Cloudfront, & Lambda:

https://discourse.mozilla.org/t/securing-github-pages-with-terraform-cloudfront-and-lambda/24215

Section 5.1 (Audit Statement Content) states:

An authoritative English language version of publicly available audit information must be uploaded to the CCADB no later than three months after the end of the audit period. In the event of a delay greater than three months, the CA Owner must provide an explanatory letter signed by the Qualified Auditor.

However, does not specify where the explanatory letter must be sent.

In a future update to the CCADB policy, require these letters to be:

1. mailed to [email protected], or
2. posted to Bugzilla.

Add the following two links to the Mozilla section of https://ccadb.org/resources

1. https://wiki.mozilla.org/CA/Communications

2. https://wiki.mozilla.org/CA/Incident_Dashboard

This page describes the six-week CCADB Public Discussion process.

Update the page to align expectations that once started, the six-week period shall not be paused.

Modify https://www.ccadb.org/policy#5-policies-practices-and-audit-information to clarify that CAs are not expected to keep audit information up-to-date for intermediate certificates that are technically-constrained as described in section 7.1.5 of the CA/Browser Forum Baseline Requirements.

Please add the following sentence to the top of http://ccadb.org/cas/updates#instructions

The following instructions explain how to create an Audit Case in which you will indicate a set of audits and CP/CPS documents, and then you will create corresponding Audit Root Cases to indicate which root certificates were in scope of those audits.

(There is still frequently confusion causing CAs to create multiple Audit Cases for one set of audits, or to not add the Audit Root Cases.)

Related to a recent message sent to [email protected], we should document the fields included in the “All Certificate Information (root and intermediate) in CCADB (CSV)” report.

todo: Record field summary here and consider publication on CCADB.org.

Please replace the 4 bullet points of Item #7 of http://ccadb.org/cas/updates#instructions with the following bullet point.

• Click on the 'Edit Test Websites' button, update the URLs to the 3 test websites for each root certificate, and click on 'Apply Changes'.

In the https://ccadb.org/cas/updates page please add a section called "Test Preliminary Audit Statements". It should go under the "Audit Case Workflow" section.

Contents:

To test that preliminary audit statements will pass ‘Audit Letter Validation (ALV)’, the CA may do the following:

1. Attach the audit statements to a Bugzilla Bug <link to https://ccadb.org/cas/fields#uploading-documents>, indicating that they are preliminary.
2. Create an Audit Case in the CCADB, providing links to the audit statements that were attached to the Bugzilla Bug.
3. Add a Case Comment to the Audit Case that says: "Preliminary Audit Reports".
4. Follow the rest of the Audit Case Workflow <link to https://ccadb.org/cas/updates#audit-case-workflow> to run ALV on the preliminary audit statements.
5. When the audit statements are finalized, update the links, re-run ALV, and add a Case Comment that says: "Final Audit Reports".

The View in each Tab and the list in each Search in Salesforce defaults to recently viewed records, which is causing confusion for CAs. Unfortunately Salesforce does not currently allow us to change this.

http://ccadb.org/cas/getting-started#navigating-the-interface
add a second bolded(?) paragraph in this section that says:

"The View in every tab and search defaults to recently viewed items only. You must select the View or start the search and click on the 'Go!' button to see the full set of data you are looking for."

And in step 9 of http://ccadb.org/cas/updates#instructions
bold or italicize this existing text:
"Default list in Search shows recently viewed records. Be sure to enter the beginning of your cert name followed by asterisk (e.g. A*), and click on the ‘Go!’ button."

Please add the following two links to the General section of the Resources tab. Feel free to modify the names...

1. CSV Report of Cert Records in CCADB
   http://ccadb-public.secure.force.com/mozilla/AllCertificateRecordsCSVFormat

2. Certificate and Website Configurations
   https://censys.io/

Please update http://www.ccadb.org/rootstores/mozilla-ccadb-agreement.pdf
to the new license-fee-based version of the agreement, which is here:
https://bugzilla.mozilla.org/attachment.cgi?id=9111773

Clarify that when CAs provide audit statements in the CCADB, they need to provide a separate and independent PDF for each audit type. This will probably involve updating https://www.ccadb.org/policy and https://www.ccadb.org/cas/alv.

Please create a separate page for documentation about mass importing intermediate certs. The info is currently here:
https://wiki.mozilla.org/CA:SalesforceCommunity:MassImport

In http://ccadb.org/cas/intermediates please add the following sub-section in the "Adding Intermediate Certificate Data" section, but under the "Clone" sub-section.
~~
Mass Import
CAs who have a large number of intermediate certificates to add to the CCADB may request that their data be mass imported from a spreadsheet or CSV file, by sending email to their root store operator. Doing the mass import process involves a significant amount of manual work, so if you have less than 20 intermediate certificates please enter them by hand.
~~
Have 'mass import process' link to the new page.

Thanks!

I have received this request many times...
It would be very helpful if the following pages had a click-able index at the top of them (for the main section headings):
https://ccadb.org/policy
https://ccadb.org/cas/fields
https://ccadb.org/cas/intermediates
https://ccadb.org/cas/updates

As of January 1 2019, Mozilla requires that all GitHub projects include this CODE_OF_CONDUCT.md file in the project root. The file has two parts:

1. Required Text - All text under the headings Community Participation Guidelines and How to Report, are required, and should not be altered.
2. Optional Text - The Project Specific Etiquette heading provides a space to speak more specifically about ways people can work effectively and inclusively together. Some examples of those can be found on the Firefox Debugger project, and Common Voice. (The optional part is commented out in the raw template file, and will not be visible until you modify and uncomment that part.)

If you have any questions about this file, or Code of Conduct policies and procedures, please see Mozilla-GitHub-Standards or email [email protected].

(Message COC001)

As discussed on m.d.s.p., when a CA certificate appears on the audit statement of both the issuer and subject and those are two different organizations, expectations for CP/CPS disclosure are unclear. We may want to require information for both the cert and the Subject + SPKI, or decide which one is appropriate. I think the CP/CPS of the CA in possession of the private key (i.e. the Subject of the cert) is the appropriate one to disclose for these certificates. However, the responsibility of disclosing falls on the Issuer.

Please add instructions to http://ccadb.org/cas/updates about the "Recognized CAA Domains" and "Problem Reporting Mechanism" fields.

In #3 add bullet:
The 'Recognized CAA Domains' and 'Problem Reporting Mechanism' fields will be automatically filled in when you click on the 'Submit' button, so leave them blank to begin with. You can change them later if needed.

Then add another step (15?) for updating these two fields...
Check that the information in the 'Recognized CAA Domains' and 'Problem Reporting Mechanism' fields is current and of the correct format.
-- 'Recognized CAA Domains' should be a comma-separated list of Certification Authority Authorization (CAA) domain names recognized in a CAA record's issue and issue wild property tags.
-- 'Problem Reporting Mechanism' should provide brief instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter relating to certificates.

Modify https://www.ccadb.org/policy#5-policies-practices-and-audit-information to clarify that CAs are not expected to keep audit information up-to-date for revoked intermediates.

Some CAs are still getting confused with Audit Cases, and I think it would help to add a very high level list of what they need to do...

Please add the following section to the top of the page in https://ccadb.org/cas/updates
~~
Audit Case Workflow
To provide annual audit statements, the CA does the following:

1. Create an Audit Case in the CCADB - one Audit Case per set of audit statements.
2. Fill in the Auditor, Audit Information, and CP/CPS Information sections.
3. Click on the ‘Add/Update Root Cases’ button to indicate which root certificates are covered in the audit statements, and which audit statements apply to each of those roots.
4. Click on the ‘Edit Test Websites’ button to make sure the test websites are correct.
5. Click on the ‘Audit Letter Validation (ALV)’ button, and work with your auditor to resolve all problems.

After ALV is run, the Audit Case gets automatically assigned to a Root Store Operator for review and final processing.
~~

Determine and document what is expected when not all of the intermediate certs with the same Subject+SPKI are technically constrained.
e.g. is it OK for these to be inconsistent as per:
https://crt.sh/mozilla-disclosures#disclosedwithinconsistentaudit
For example:
https://crt.sh/?id=1612093347 -- technically constrained, so no audit statements
https://crt.sh/?id=319549067 -- not technically constrained, so audit statements required

Subject + SPKI SHA256 | 98F39514BA28174E9B3D46C7997E27F759FACFD96C26E3A38834BC9B6BDA27F7

Kathleen writes:

Please add a section to ccadb.org called "Information for Partners" or "Information for Root Store Operators" or such. It would have these links:

Login to CCADB -> https://ccadb.my.salesforce.com/
CCADB Partnership Information -> https://wiki.mozilla.org/CA:CommonCADatabase:RootStoreOperators