1737866 - Update Root Inclusion Cases to have the new work flow and UI

Status: RESOLVED FIXED

(CA Program :: Common CA Database, task)

Description

[Kathleen Wilson]

Update Root Inclusion Cases to have the work flow and UI that we introduced in the new CA Information Update Request (Non-Audit) Case type (Bug #1711589).

Comment 1

[Kathleen Wilson]

Consider Bug #1779073 during this redesign.

Comment 2

[Kathleen Wilson]

Add Root Certificate:

• Create a separate process for CAs to add new root certificate records to the CCADB, before creating a root inclusion request.
  • New Audit Case type called "Create Root Record"
  • This would essentially be an Audit Case with an additional tab: ADD ROOT
• Require CA to complete the "Create Root Record" Case before creating a corresponding Root Inclusion Request
• Root Inclusion Request will display information directly from the CA Owner and Root Cert records (not copied, and not editable via root inclusion case)
  • Option to Discuss: Root Inclusion Case could also list the latest Audit Case for each root cert in the request

The following needs to be discussed more.
e.g. What happens when the CA wants to request 2 roots included in Apple, 3 roots included in Microsoft, and 1 included in Mozilla?

• Could have one Root Inclusion Case which has a tab for each root store. Within each tab, the CA can indicate which root certificates and trust bits / EKUs they want to apply to the root store for.
  OR
• Upon creation of Root Inclusion Request, have a checkbox for CA to select each root store that they are applying to.
• Upon submit create one Root Inclusion Request case per root store applying to.
• Common information should go into Audit, Information Update, and "Create Root Certificate Record" cases.
• Only root store specific information should go into the Root Inclusion Request cases
  • we’ll need to review/discuss this as we design the new root inclusion cases

Comment 3

[Chris Clements]

Some suggestions for the added tab(s) in the Root Record case:

• ADD ROOT

  • Enter PEM
  • Key Generation Date [date picker]
  • Key Generation Audit Report Date [date picker]
  • Key Generation Audit Report [text for URL]

• PKI HIERARCHY

  • Intended Use Case(s) Served: [drop down with values of either: multi-purpose root, dedicated TLS hierarchy, dedicated S/MIME hierarchy, dedicated code signing hierarchy [include whatever use cases/trust bits are relevant to other programs]
  • CA/Browser Forum Certificate Policy Identifiers included in HTTPS certificates chaining to this root [selection box]:
    • Domain Validated (2.23.140.1.2.1)
    • Organization Validated (2.23.140.1.2.2)
    • Extended Validation (2.23.140.1.1)
  • Domain validation methods used during TLS certificate issuance
    • TLS Certificate Domain Validation Methods in Use [selection boxes with values, below]:
    • Email, Fax, SMS, or Postal Mail to Domain Contact (BRs 3.2.2.4.2)
    • Constructed Email to Domain Contact (BRs 3.2.2.4.4)
    • DNS Change (BRs 3.2.2.4.7)
    • IP Address (BRs 3.2.2.4.8)
    • Validating Applicant as a Domain Contact (BRs 3.2.2.4.12)
    • Email to DNS CAA Contact (BRs 3.2.2.4.13)
    • Email to DNS TXT Contact (BRs 3.2.2.4.14)
    • Phone Contact with Domain Contact (BRs 3.2.2.4.15)
    • Phone Contact with DNS TXT Record Phone Contact (BRs 3.2.2.4.16)
    • Phone Contact with DNS CAA Phone Contact (BRs 3.2.2.4.17)
    • Agreed-Upon Change to Website v2 (BRs 3.2.2.4.18)
    • Agreed-Upon Change to Website - ACME (BRs 3.2.2.4.19)
    • TLS Using ALPN (BRs 3.2.2.4.20)
  • Is this root CA certificate cross-signed by another root? [text]
  • Are there any externally operated ICAs in this hierarchy? [text]
  • Are there any external Registration Authorities in this hierarchy? [text]
  • Description of PKI hierarchy [text]
  • Is this a dedicated TLS Hierarchy? (Y/N)

• SELF-ASSESSMENT

  • Completed Self-Assessment [upload file]

Comment 4

[Chris Clements]

Feedback from 8/11 CCADB SC meeting. This supersedes comment 3.

Three high-level changes:

1. Existing CA Audit Update Request case is renamed to "Add/Update Root Request" and a new "ROOT INFO" tab is added to the case
2. Existing CA Information Update Request (Non-Audit) case is deprecated
3. Existing CA Root Inclusion Request case is converted to a new lightning workflow (detailed design to be described in a future separate comment)

Components of new ROOT INFO tab re: #1:

ADD a "Select Root Certificates for this Case" function (similar to what currently exists for the TEST WEBSITES tab) where a user can add or remove one or more root CA certificates for entering or updating ROOT INFO data. Add the upload PEM function so a user can add a new root CA certificate to CCADB. After selecting one or more root CA certificates, the sections below are presented for each root (again similar to the existing TEST WEBSITES tab). For a new root, the fields will be blank. For an existing root, the fields will populate with existing data.

Application Information (Currently exists in Root Case but should be renamed to "Root CA Background".)

• Explanation [text]
• Role [text]
• Root Certificate Download URL [text]

Certificate Data [Fields NOT editable; extracted from PEM] (Currently exists in Root Case. No change.)

Select all that apply to this Certificate (Currently exists in Root Case. Remove from ROOT INFO.)

Test Websites (Currently exists in Root Case. Remove from ROOT INFO and add to TEST WEBSITES tab.)

Test Results (When EKU has id-kp-serverAuth) (Currently exists in Root Case. Remove from ROOT INFO and add to TEST WEBSITES tab.)

PKI Hierarchy (Currently exists in Root Case. Add additional fields noted below.)

• Cross-Signed by another Root Cert? [radio button]
• Has Externally Operated SubCAs? [radio button]
• CP/CPS allows Ext Operated SubCAs? [radio button]
• Has External Registration Authorities? [radio button]
• CP/CPS allows External RAs? [radio button]
• Description of PKI Hierarchy: [text]
• ADD Intended Use Case(s) Served: [drop down with values of either: multi-purpose root, dedicated TLS hierarchy, dedicated S/MIME hierarchy, dedicated code signing hierarchy]
• ADD CA/Browser Forum Certificate Policy Identifiers included in HTTPS certificates chaining to this root: [one or more selection box]
  • Domain Validated (2.23.140.1.2.1)
  • Organization Validated (2.23.140.1.2.2)
  • Extended Validation (2.23.140.1.1)
• ADD Other Certificate Policy Identifiers included in subscriber certificates chaining to this root:
  • OID [text]
• ADD TLS Certificate Domain Validation Methods in Use: [one or more selection boxes with values, below]
  • Email, Fax, SMS, or Postal Mail to Domain Contact (BRs 3.2.2.4.2)
  • Constructed Email to Domain Contact (BRs 3.2.2.4.4)
  • DNS Change (BRs 3.2.2.4.7)
  • IP Address (BRs 3.2.2.4.8)
  • Validating Applicant as a Domain Contact (BRs 3.2.2.4.12)
  • Email to DNS CAA Contact (BRs 3.2.2.4.13)
  • Email to DNS TXT Contact (BRs 3.2.2.4.14)
  • Phone Contact with Domain Contact (BRs 3.2.2.4.15)
  • Phone Contact with DNS TXT Record Phone Contact (BRs 3.2.2.4.16)
  • Phone Contact with DNS CAA Phone Contact (BRs 3.2.2.4.17)
  • Agreed-Upon Change to Website v2 (BRs 3.2.2.4.18)
  • Agreed-Upon Change to Website - ACME (BRs 3.2.2.4.19)
  • TLS Using ALPN (BRs 3.2.2.4.20)

ADD Self-Assessment

• Self-Assessment: [text for URL]

ADD Key Generation

• Key Generation Date: [date picker]
• Key Generation Audit Report Date: [date picker]
• Key Generation Audit Report: [text for URL]

Comment 5

[Clint]

From discussion today, Apple requests the following also be added:

Add “subjectKeyId”: from Extraction Results to the “Certificate Data” section of Root Certificate records.
Add “authorityKeyId”: from Extraction Results to the “Certificate Data” section of Root Certificate records.
Add “subjectKeyId”: from Extraction Results to the “Certificate Data” section of Intermediate Certificate records.
Add “authorityKeyId”: from Extraction Results to the “Certificate Data” section of Intermediate Certificate records.
Add “subjectKeyId” of the CCADB-associated Parent Root CA to the “Certificate Data” section of Intermediate Certificate records (<- This shouldn't strictly be necessary in perpetuity, but if we ran a check of this data across all Intermediate and Root Certificate records, it would identify if any CCADB associations are incomplete or inaccurate.)

Comment 6

[Kathleen Wilson]

(In reply to Clint from comment #5)

From discussion today, Apple requests the following also be added:
...
To Summarize: Add “subjectKeyId” and “authorityKeyId” from Extraction Results to the “Certificate Data” section of root certificate records, intermediate certificate records, and the new root information tab on Cases.

Field names:
subjectKeyId -> Subject Key Identifier
authorityKeyId -> Authority Key Identifier

These fields should go between "Public Key Algorithm" and "SPKI SHA256".

Add “subjectKeyId” of the CCADB-associated Parent Root CA

On intermediate certificate records, add "Root Certificate SKI" (not editable) to the "CA Owner/Certificate Information" section, between "Root Certificate" and "CA Owner". This value will need to be filled in by the same batch job that fills in the "Root Certificate" field. When the batch job determines the value for the "Root Certificate" field, it should also fill in "Root Certificate SKI" with the "Subject Key Identifier" of that root certificate.

Help text: The Subject Key Identifier of the root certificate that this intermediate certificate chains up to in the CCADB.

Comment 7

[Kathleen Wilson]

In the new "ROOT INFORMATION" tab, please make "Intended Use Case(s) Served" a multi-pick list (like CA/B Forum Certificate Policy Identifier) and include the following options:
Server Authentication (TLS) 1.3.6.1.5.5.7.3.1
Secure Email (S/MIME) 1.3.6.1.5.5.7.3.4
Client Authentication 1.3.6.1.5.5.7.3.2
Code Signing 1.3.6.1.5.5.7.3.3
Document Signing AATL 1.2.840.113583.1.1.5
Document Signing MS 1.3.6.1.4.1.311.10.3.12
Encrypting File System 1.3.6.1.4.1.311.10.3.4
IP Security 1.3.6.1.5.5.7.3.5
Time Stamping 1.3.6.1.5.5.7.3.8

Comment 8

[Chris Clements]

In the new ROOT INFORMATION tab:

• Collapse Explanation and Role into a single field and update the tooltip to say “Explain why this root needs to be considered for inclusion by a CCADB Root Store Member. Explain the unique function of this root.”
• Add a tooltip for Intended Use Case(s) Served to say “Select the extKeyUsage values that are present in the subordinate CA and subscriber certificates below this root.”
• Change the current "Available" values for CA/B Forum Certificate Policy Identifier to:
  • extended-validation 2.23.140.1.1
  • domain-validated 2.23.140.1.2.1
  • organization-validated 2.23.140.1.2.2
  • individual-validated 2.23.140.1.2.3
  • extended-validation-codesigning 2.23.140.1.3
  • codesigning-requirements codesigning 2.23.140.1.4.1
  • onion-EV 2.23.140.1.31
• Modify the CA/B Forum Certificate Policy Identifier tooltip to say “CA/Browser Forum Certificate Policy Identifiers included in certificates below this root.”
• Change the current "Available" values for TLS Certificate Domain Validation Method to:
  • 3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact
  • 3.2.2.4.4 Constructed Email to Domain Contact
  • 3.2.2.4.7 DNS Change
  • 3.2.2.4.8 IP Address
  • 3.2.2.4.12 Validating Applicant as a Domain Contact
  • 3.2.2.4.13 Email to DNS CAA Contact
  • 3.2.2.4.14 Email to DNS TXT Contact
  • 3.2.2.4.15 Phone Contact with Domain Contact
  • 3.2.2.4.16 Phone Contact with DNS TXT Record Phone Contact
  • 3.2.2.4.17 Phone Contact with DNS CAA Phone Contact
  • 3.2.2.4.18 Agreed-Upon Change to Website v2
  • 3.2.2.4.19 Agreed-Upon Change to Website - ACME
  • 3.2.2.4.20 TLS Using ALPN
• Add a tooltip for TLS Certificate Domain Validation Method to say “Select all of the TLS certificate validation methods that are available for use for certificates below this root.”

Comment 9

[Poonam Bhargava]

Thanks for updating your notes. Please provide me a list of mandatory fields for Root Info tab. For the such fields, a highlighted warning will be displayed at the top of the section.

Comment 10

[Chris Clements]

(In reply to Poonam Bhargava from comment #9)

Thanks for updating your notes. Please provide me a list of mandatory fields for Root Info tab. For the such fields, a highlighted warning will be displayed at the top of the section.

Propose we:

• Add "N/A - non-TLS CA" as an additional Available value for TLS Certificate Domain Validation Method selection.
• Then make all fields mandatory except for Other Certificate Policy Identifiers.

Comment 11

[Chris Clements]

Some additional tooltip suggestions for ROOT INFORMATION:

• Modify the Cross-Signed by another Root Cert? tooltip to say “Select this box if this root CA certificate is cross-signed by another root CA.”
• Modify the Has Externally Operated SubCAs? tooltip to say “Select this box if there are externally operated subordinate CAs below this root.”
• Modify the CP/CPS allows Ext Operated SubCAs? tooltip to say “Select this box if the CP/CPS for this root documents the allowance of subordinate CAs to be operated by an external entity.”
• Modify the Has External Registration Authorities? tooltip to say “Select this box if there are external Registration Authorities below this root.”
• Modify the CP/CPS allows External RAs? tooltip to say “Select this box if the CP/CPS describes the allowance of external Registration Authority operations.”
• Modify the Description of PKI Hierarchy tooltip to say “Describe or point to a URL that describes the hierarchy under this root. Detail the use cases and communities served by this hierarchy.”

Comment 15

[Kathleen Wilson]

I created Bug #1791425 to cover the very significant amount of work that was done in Q3 2022 to create the "Add/Update Root Request" case type as described in comments 2 through 11 of this bug.

Comment 16

[Kathleen Wilson]

Went live on December 22.