1695487 - Add HARICA 2021 TLS Root CA Certificates to Mozilla Root store program

Status: RESOLVED FIXED

(CA Program :: CA Certificate Root Program, task, P1)

Description

[Dimitris Zacharopoulos]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:86.0) Gecko/20100101 Firefox/86.0

Comment 1

[Dimitris Zacharopoulos]

HARICA would like to request the addition of two Root CA Certificates to NSS and the Mozilla root store, enable the Web Sites trust bit and EV treatment. These roots are intended to be used for TLS Server authentication.

All HARICA TLS certificates will eventually be migrated to be issued from subCAs chaining to these roots.

We will start working on a new CCADB case to add information about these two root certificates. We expect these new roots to be included in the audit attestation of our current audit cycle ending 2021-03-29.

Comment 2

[Dimitris Zacharopoulos]

Attachment: HARICA's BR Self [e-mail]

Comment 3

[Dimitris Zacharopoulos]

Attachment: RKGC 2021 Attestation Letter

Comment 4

[Dimitris Zacharopoulos]

The AAL is also available through from our auditor's web site https://www.qmscert.com/share/040321-01-KG-AAL.pdf.

Comment 5

[Ben Wilson]

The auditor's attestation (AAL) regarding key generation and the BR self assessment have been reviewed and look fine.

Comment 6

[Ben Wilson]

CPS Review of HARICA CPS v. 4.4 (May 5, 2021)

https://repo.harica.gr/documents/CPS-EN.pdf

CP/CPS structured in accordance with RFC 3647 with no blank sections (MRSP § 3.3.5) (BR § 2.2)

Good – CPS follows RFC 3647 without blank sections.

---

CP/CPS made available under a Creative Commons License (MRSP § 3.3.3)

“CPs and CPSes are made available to Mozilla under one of the following Creative Commons licenses (or later versions)”

OK – CPS is silent on copyright, reproduction, use, etc.

---

Statement of adherence to BRs and their precedence (MRSP § 2.3) (BR § 2.2)

“The CA SHALL publicly give effect to these Requirements and represent that it will adhere to the latest published version”, including a statement such as “in the event of any inconsistency between this CP/CPS and those Requirements, those Requirements take precedence.”

Good – Addressed in CPS section 1.2.

---

Separate, EKU-constrained issuing CAs (MRSP § 5.3) (BR § 7.1.2.2.g.)

Intermediate CAs must have an EKU, not the anyEKU EKU, and not both serverAuth and an emailProtection, codesigning, or timeStamping EKU.

Good – Section 7.1.2 provides, “A single Issuing CA MUST NOT be used to issue certificates that blend the id-kp-serverAuth [RFC5280], the id-kp-emailProtection [RFC5280], the id-kp-codeSigning [RFC5280] and the id-kp-timeStamping [RFC5280] values in the EKU extension. New Issuing CAs must separate Server Authentication, S/MIME, Code Signing and Time Stamping Extended Key Usages.”

---

Clear identification of CAs covered by CP/CPS (MRSP § 3.3.6)

“CAs must provide a way to clearly determine which CP and CPS applies to each of its root and intermediate certificates.”

Good – Annex C of the CPS identifies root CAs and intermediate CAs.

---

Explicit annual revision of CP/CPS w/ table of changes (MRSP § 3.3.4) (BR § 2.3)

“CPs and CPSes MUST be reviewed and updated as necessary at least once every year, as required by the Baseline Requirements. CAs MUST indicate that this has happened by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document.” Also, a version history table provides evidence of compliance and good change management practices.

Good – the CPS contains a Version Control table.

---

Statement of Non-Delegation for Domain Validation (BR § 1.3.2)

“With the exception of sections 3.2.2.4 and 3.2.2.5, the CA MAY delegate the performance of all, or any part, of Section 3.2 requirements to a Delegated Third Party, provided that the process as a whole fulfills all of the requirements of Section 3.2.”

Good – Section 1.3.2 of the CPS states, “HARICA SHALL NOT delegate validation of the domain portion of an email address and the performance of validation actions of sections 3.2.2.4 and 3.2.2.5 to a Delegated Third Party.”

---

Clear problem reporting instructions in section 1.5.2 (BR § 4.9.3)

“The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means and in section 1.5.2 of their CPS.”

Good – Section 1.5.2 of the CPS specifies email addresses for filing certificate problem reports.

---

Naming compliant with X.500, RFC5280 and BRs

The structure and use of names in certificates must comply with the Baseline Requirements (and EV Guidelines, if applicable), and other standards.

Good – Sections 3.1.1, 7.1.4, and 7.1.4.8 adequately discuss naming compliant with X.500, RFC 5280 and the CA/Browser Forum Baseline Requirements.

---

No internal names or reserved IP addresses (BR § 7.1.4.2.1)

“CAs SHALL NOT issue certificates with a subjectAltName extension or subject:commonName field containing a Reserved IP Address or Internal Name.”

Good - CPS section 3.1.1 states “HARICA does not issue certificates containing internal server names and/or reserved IP addresses.”

---

ALL certificates must meet Mozilla/BR validation requirements

CPS must specifically explain validation methods and validation steps taken to verify certificate requests in accordance with BR §§ 3.2.2.4 and 3.2.2.5 (MRSP § 2.2.3 and MRSP § 3.3.1)

CP/CPS must be sufficient “for Mozilla to determine whether and how the CA complies with this policy, including a description of the steps taken by the CA to verify certificate requests”.

[Note: It is also recommended that CAs ensure that the domain name registrant has approved or authorized a certificate request such that the certificate cannot be used to facilitate surreptitious interception by third parties (except with the domain registrant's permission).]

Good – Section 3.2.2.4 of the CPS specifies that HARICA uses methods consistent with Baseline Requirements sections 3.2.2.4.2, 3.2.2.4.4, 3.2.2.4.7, 3.2.2.4.8, 3.2.2.4.12, 3.2.2.4.13, 3.2.2.4.14, 3.2.2.4.15, 3.2.2.4.16, 3.2.2.4.17, 3.2.2.4.18, and 3.2.2.4.19 which are all currently allowed domain validation methods.

Section 1.4.2 also states, “TLS Server Certificates shall not be used for man-in-the-middle (MITM) or traffic management of domain names or IPs that the certificate holder does not legitimately own or control. Such certificate usage is explicitly prohibited.”

---

CA validates domain part of all e-mail addresses (MRSP § 2.2.2)

“For a certificate capable of being used for digitally signing or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder’s behalf. The CA SHALL NOT delegate validation of the domain portion of an email address.”

Good – Section 1.3.2 of the CPS states, “HARICA SHALL NOT delegate validation of the domain portion of an email address and the performance of validation actions of sections 3.2.2.4 and 3.2.2.5 to a Delegated Third Party.”

---

Data sources need to be accurate (BR § 3.2.2.7)

“[For a] Reliable Data Source, the CA SHALL evaluate the source for its reliability, accuracy, and resistance to alteration or falsification.”

Good – CPS Section 3.2.2.7 contains the criteria that HARICA uses to ensure that data sources are reliable.

---

All information in a certificate must be verified (MRSP § 2.2.1)

“All information that is supplied by the certificate subscriber MUST be verified by using an independent source of information or an alternative communication channel before it is included in the certificate.”

Good – CPS section 3.2.4 states, “The certificates that are issued do not include non-verified subscriber information.”

---

Data reuse (certificate renewal) limited to 398 and 825 days (MRSP § 2.1.5) (BR § 4.2.1)

CAs must “verify that all of the information that is included in SSL certificates remains current and correct at time intervals of 825 days or less”, and “for server certificates issued on or after October 1, 2021, each dNSName or IPAddress in a SAN or commonName MUST have been validated in accordance with section 3.2.2 of the CA/Browser Forum's Baseline Requirements within the prior 398 days.”

Good – Section 4.2.1 of HARICA’s CPS limits reuse of validation of Domain Names and IP Addresses to 397 days and other validation to 825 days.

---

CAA record checking and recognized domain names in section 4.2 (BR § 2.2)

“Section 4.2 of a CA’s Certificate Policy and/or Certification Practice Statement SHALL state the CA’s policy or practice on processing CAA Records for Fully Qualified Domain Names; that policy shall be consistent with these Requirements.”

Good – Sections 3.2.2.8 and 4.2.4 of the CPS state HARICA’s CAA checking practices.

---

Accounts capable of certificate issuance must have multi-factor authentication (MRSP § 2.1.3)

CAs must “enforce multi-factor authentication for all accounts capable of causing certificate issuance or performing Registration Authority or Delegated Third Party functions, or implement technical controls operated by the CA to restrict certificate issuance through the account to a limited set of pre-approved domains or email addresses”.

Good – Section 6.5.1 states, “HARICA enforces multi-factor authentication for all accounts capable of directly causing certificate issuance.”

---

Pre-issuance linting (Recommended Practices)

“It is strongly recommended that CAs integrate such tools …. Because BR or RFC violations are generally considered by Mozilla to be misissuance, such integration will reduce the number of misissuance events a CA experiences.”

Good – Section 4.3.1 states, “Pre-issuance linting checks shall take place to verify compliance with applicable standards according to each certificate type.”

---

Revocation in accordance with BR section 4.9.1 (MRSP § 6.1) (BR §§ 4.9.1.1 and 4.9.1.2)

24-hour revocation for reasons (1)-(5); 5 days for reasons (1)-(11) and 7 days for Intermediate CAs reasons (1) – (9)

Needs to be fixed – In section 4.9.1.1, HARICA needs to move part of subsection 15 to the mandatory 24-hour revocation part of that section to match BR section 4.9.1.1, subsection 4, which requires 24-hour revocation if “The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber’s Private Key based on the Public Key in the Certificate (such as a Debian weak key, see https://wiki.debian.org/SSLkeys)”.

---

SMIME Reasons for Revocation (MRSP § 6.2)

“For any certificate in a hierarchy capable of being used for S/MIME, CAs MUST revoke certificates upon the occurrence of any of the following events …”

Good – Section 4.9.1.1 of the HARICA CPS contains a section on revocation reasons for S/MIME.

---

CRLs at least every 7 days w/ nextUpdate not more than 10 days (MRSP § 6)

Good – Section 4.9.7 specifies a 7-day maximum frequency for CRL publication.

---

Clearly specify methods to demonstrate private key compromise (MRSP § 6)

Good - Section 4.9.12 of the CPS describes the method by which a party can demonstrate private key compromise to HARICA.

---

CA must not allow certificate suspension (BR § 4.9.13)

OK. Section 4.9.13 of the CPS is silent on server certificates, while allowing it for other kinds of certificates.

---

OCSP updates every 4 days w/ max. expiration of 10 days (MRSP § 6)

Good – CPS section 4.9.10 contains the required language.

---

Provide Mozilla notice immediately upon private CA key compromise (MRSP § 7)

“Changes that are motivated by a security concern such as certificate misissuance or a root or intermediate compromise MUST be treated as a security-sensitive, and a secure bug filed in Bugzilla.”

OK – Section 5.7.1 (incident handling procedures) states, “This procedure includes steps for the disclosure of security-related incidents to Application Software Suppliers.” Similar language could be added to section 5.7.3 (Private key compromise procedures). For instance, it currently states, “In case a Private Key, associated with a Subordinate CA Certificate, is compromised, all Subscribers of the corresponding Subordinate CA are notified.”

---

CA must not generate Subscriber key pairs (MRSP § 5.2)

“CAs MUST NOT generate the key pairs for end-entity certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage.”

Good – Section 6.1.2 of the CPS states, “HARICA SHALL NOT generate a Key Pair on behalf of a Subscriber for Keys that are to be associated with SSL/TLS server Certificates, ….”

---

Must meet RSA key requirements (MRSP § 5.1)

Good – These are addressed in CPS sections 6.1.5 and 6.1.6.

---

Must meet ECC key requirements, P-256 or P-384 (MRSP § 5.1)

Good – These are addressed in CPS sections 6.1.5 and 6.1.6.

---

Certificate lifetimes limited to 398 days (BR § 6.3.2)

“Subscriber Certificates … SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days.”

Good – Section 6.3.2 states that the validity period is three hundred ninety seven (397) days for SSL/TLS Certificates”

---

Network Security (MRSP § 2.1.2)

CAs must “follow industry best practice for securing their networks, for example by conforming to the CAB Forum Network Security Guidelines or a successor document”.

OK – Section 6.6.2 of the CPS states, “In addition, HARICA follows the security guidelines of “Network and Certificate System Security Requirements” of the CA/Browser Forum.” Language in section 6.7 (Network security controls) could be improved with reference to the CABF’s NCSSRs.

---

Serial numbers greater than 64 bits generated by a CSPRNG (MRSP § 5.2)

“all new certificates MUST have a serial number greater than zero, containing at least 64 bits of output from a CSPRNG.”

Good – Section 7.1.4.1 states, “Issuing CAs shall generate non-sequential Certificate serial numbers greater than zero (0) containing at least sixty-four (64) bits of entropy from a CSPRNG.”

---

EKUs required in certificates issued after 7-1-2020 (MRSP § 5.2) (BR § 7.1.2.3.f)

Good – Annex B (Certificate Profiles) indicates that SSL/TLS server certificates contain the TLS Web Client Authentication and TLS Web Server Authentication EKUs.

---

Use of SHA-1 prohibited (MRSP § 5.1.3) (BR § 7.1.3.2.1)

Good – CPS Section 7.1.3.2.1 contains language from the Baseline Requirements regarding allowed use of the SHA1 algorithm.

---

Any CN must also be in a SAN (BR § 7.1.4.2.2.a)

Good – CPS section 7.1.4.7 states, “This is the Subject’s Common Name. If present for SSL/TLS certificates, this field MUST contain an FQDN or an IP Address that is one of the values contained in the Certificate’s subjectAltName extension.”

Comment 7

[Ben Wilson]

Public discussion on this request was announced here - https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/UAmBtcVvBKw/m/o5cYt-dFAAAJ. The public discussion period is scheduled to close on 11-June-2021.

Comment 8

[Dimitris Zacharopoulos]

Thank you very much for the thorough review.

Needs to be fixed – In section 4.9.1.1, HARICA needs to move part of subsection 15 to the mandatory 24-hour revocation part of that section to match BR section 4.9.1.1, subsection 4, which requires 24-hour revocation if “The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber’s Private Key based on the Public Key in the Certificate (such as a Debian weak key, see https://wiki.debian.org/SSLkeys)”.

This was an oversight that will be fixed at the next revision. In practice HARICA has always considered that such keys are Compromised and any certificate associated with them shall be revoked in the 24-hour time-frame.

Comment 9

[Ben Wilson]

The 3-week public discussion period has now passed and there were no objections to this inclusion request. See https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/UAmBtcVvBKw/m/5nZlAMk7BAAJ in which I indicated that it is Mozilla’s intent to approve HARICA’s requests for EV enablement/inclusion and started the 7-day “last call” period (through June 22, 2021) for any final objections.

Comment 10

[Kathleen Wilson]

As per Comment #9, and on behalf of Mozilla I approve this request from HARICA to include the following root certificates:

** HARICA TLS RSA Root CA 2021 (Websites); EV
** HARICA TLS ECC Root CA 2021 (Websites); EV

I will file the NSS and PSM bugs for the approved changes.

Comment 11

[Kathleen Wilson]

I have filed bug #1717707 against NSS and bug #1717711 against PSM for the actual changes.