1592138 - Add Macao Post eSignTrust root certificate

Status: ASSIGNED

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

Description

[Kathleen Wilson]

A representative of Macao Post created a Root Inclusion Case here:

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000396

The Case was created on 2/28/2019, but I did not ever see a corresponding Bugzilla Bug about it, so creating one now.
(reference: https://wiki.mozilla.org/CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request)

The request is to include the following root certificate:
CN=eSignTrust Root Certification Authority (G03); O=Macao Post and Telecommunications Bureau; C=MO
SHA-256 Fingerprint: 0E30D04A94DCC423E26FDC4C24AFCF4923BD80D83B661B06A2F5856361560407
Serial Number: 3CFB7DF47EA4B4C672A03FC3D25C7CC6
Valid From: 1/1/2017
Valid To: 12/31/2041

The "Macao Post eSignTrust Root Certification Authority (G02)" root certificate is currently in Microsoft's program, with the Client Authentication trust bit enabled.

Audit Statement for period 2/1/2017 - 2/28/2018:
https://www.cpacanada.ca/generichandlers/aptifyattachmenthandler.ashx?attachmentid=221255

Audit Statement for period 3/1/2018 - 2/28/2019:
https://www.cpacanada.ca/generichandlers/aptifyattachmenthandler.ashx?attachmentid=229895

Comment 1

[Kathleen Wilson]

The link below shows the information that has been verified for this root inclusion request. Search in the page for the word "NEED" to see where further clarification is requested. Please add a comment to this bug when you have provided all of the requested information.

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000396

In particular, please provide the following:

1. Version table or changelog in the CPS.
   https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Revision_Table

2. Check usage of "No stipulation" throughout CPS.
   https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Structured_According_to_RFC_3647
   The words "No Stipulation" mean that the particular document imposes no requirements related to that section.

3. CPS section that describes how the CA must verify the email address to be included in the certificate.
   https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Verifying_Email_Address_Control

4. A public URL through which the CA certificate can be directly downloaded.

5. Add records for the existing intermediate certs to the CCADB as described here: https://ccadb.org/cas/intermediates#adding-intermediate-certificate-data

Comment 2

[Ben Wilson]

Updated audit and CPS info and re-ran checks. Need to review email verification practices.

Comment 3

[Ben Wilson]

Today I reviewed this application for the inclusion of the eSignTrust Root Certification Authority (G03) (for email trust bit).

Here are some things we still need:

1 - The CPS needs to explain the email verification process in greater detail. It currently does not meet Mozilla requirements. 
2 - We need the full CA hierarchy under the Root.  Macao Post needs to add records for all existing intermediate certificates into the CCADB
3 - The CPS needs a Revision Table or Changelog, updated annually. 
4 - The CCADB application indicates that External Third Party CAs and RAs are allowed under the PKI hierarchy, therefore we need to have written assurances in the CPS that the domain part of verification will not be delegated to any third party.  ("The CA SHALL NOT delegate validation of the domain portion of an email address. The CA MAY rely on validation the CA has performed for an Authorization Domain Name (as specified in the Baseline Requirements) as being valid for subdomains of that Authorization Domain Name. The CA's CP/CPS must clearly specify the procedure(s) that the CA employs to perform this verification."  Mozilla Root Store Policy section 2.2.) We'll also need more explanation of how delegated third party CAs will be chosen, authorized, and overseen. (When an external third party is provided a CA certificate, there is the potential to lose control over certification practices, etc. Yet, Mozilla will still hold the root operator fully responsible, and the negligence of a third party CA can result in the revocation of trust of the Root CA.

Comment 4

[Ben Wilson]

(In reply to Ben Wilson from comment #3)
CA responded by email to me on 15-Aug-2020 indicating as follows:

1 - The CPS needs to explain the email verification process in greater detail. It currently does not meet Mozilla requirements. 
[pi] We will check.
2 - We need the full CA hierarchy under the Root.  Macao Post needs to add records for all existing intermediate certificates into the CCADB
[pi] We will add the records accordingly.
3 - The CPS needs a Revision Table or Changelog, updated annually. 
[pi] We will follow accordingly.
4 - The CCADB application indicates that External Third Party CAs and RAs are allowed under the PKI hierarchy, therefore we need to have written assurances in the CPS that the domain part of verification will not be delegated to any third party.  ("The CA SHALL NOT delegate validation of the domain portion of an email address. The CA MAY rely on validation the CA has performed for an Authorization Domain Name (as specified in the Baseline Requirements) as being valid for subdomains of that Authorization Domain Name. The CA's CP/CPS must clearly specify the procedure(s) that the CA employs to perform this verification."  Mozilla Root Store Policy section 2.2.) We'll also need more explanation of how delegated third party CAs will be chosen, authorized, and overseen. (When an external third party is provided a CA certificate, there is the potential to lose control over certification practices, etc. Yet, Mozilla will still hold the root operator fully responsible, and the negligence of a third party CA can result in the revocation of trust of the Root CA.
[pi] I just want to clarify that there is not any SSL certs to be issued under the PKI hierarchy of Macao Post and Telecommunications Bureau. At present, we do not have any plans to have External Thirty Part CAs. We have appointed other government entities to perform I&A of the applicants.

Comment 5

[Ben Wilson]

New CPS is posted here - https://www.esigntrust.com/en/repos_cps.html

Comment 6

[CTT eSignTrust]

CPS revisions are done according to the NEED requirements. New CPS is posted here: https://www.esigntrust.com/en/repos_cps.html

Audit Statement for period 2/1/2020 - 1/31/2021:
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=251572

Please continue to process this case.

Comment 7

[Ben Wilson]

In reviewing your CA records for subordinate CAs in the CCADB, I don't think you have marked them "Audit same as parent" and "CP/CPS same as parent." Is there a reason why? Also, do you know why the CCADB would indicate that there is an "Audit Gap"? In other words, is it possible that an audit record wasn't submitted for 2018, or something like that, where maybe the audit period were off a bit?

Comment 8

[Ben Wilson]

Here is my review of the "Certification Practice Statement of Macao Post and Telecommunications eSignTrust Certification Services" version 8.0 dated January 1, 2022.

Generally, there is a good resource for reviewing the CPS of emerging S/MIME certificate issues, which is here: https://github.com/cabforum/smime/blob/preSBR/SBR.md (the “pre-SBRs”).

Section 1.3.3 of the eSignTrust CPS states,

RA functions are normally performed by eSignTrust. However, nothing in this eSignTrust CPS prohibits eSignTrust from authorising third party to perform RA functions and may delegate the performance of all or certain RA functions to third party, subject to the provisions of this eSignTrust CPS, the applicable PKI documents, and such other requirements as eSignTrust may establish. Refer to CPS Section 9.6.2 for Registration Authority representations and warranties.

For SMIME certificates, the domain part of the email address cannot be delegated to an external, third-party RA. eSignTrust is required to ensure that the full email address is verified through a challenge-response function, or that the domain part is validated, if email address verification is delegated to an Enterprise RA. See item #2 here https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#22-validation-practices, which says,

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. The CA MAY rely on validation the CA has performed for an Authorization Domain Name (as specified in the Baseline Requirements) as being valid for subdomains of that Authorization Domain Name. The CA's CP/CPS must clearly specify the procedure(s) that the CA employs to perform this verification.

Section 1.5.2 of the eSignTrust CPS contains contact information of “Email: [e-mail]”. It should also include contact information for filing certificate problem reports, notices of key compromise, security issues, etc. The pre-SBRs says, “In this section of a CA’s CPS, the CA SHALL provide a link to a web page or an email address for contacting the person or persons responsible for operation of the CA, including contact information for entities wishing to submit a Certificate Problem Report or revocation request.”

Section 2.3 of the eSignTrust CPS does not state the frequency for publishing revisions to the CPS. However, section 9.12.1 states, “This eSignTrust CPS is reviewed annually. Amendments are made by posting an updated version of the CPS to the online repository.” Mozilla requires that a new CPS be published at least every 365 days, even if there are no changes other than a new version number and a new publication date. One of these two sections should be amended to state that eSignTrust reviews and revises the CPS at least on an annual basis. See item #4 at https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses stating,

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.

Section 3.2.3 of the eSignTrust CPS states,

When an email address is to be included in the Certificate, the Applicant is required to demonstrate control of the email. eSignTrust verifies an individual’s or organization’s right to use or control an email address to be contained in the Certificate through one of the following processes, appropriately determined by eSignTrust:

a) By sending an email message containing a Random Value to the email address to be included in the Certificate and receiving a confirming response through use of the Random Value to indicate that the Applicant and/or Organization owns or controls that same email address,

b) Through any suitable challenge response mechanism that will indicate that the Applicant and/or Organization owns or controls the email address to be included in the Certificate.

c) Through any trusted third-party data source or service that indicates the Applicant and/or Organization owns or controls the email address to be included in the Certificate.

While there is a slight concern that b) and c) allow too much discretion because “any suitable challenge response mechanism” and “any trusted third-party data source” could be subject to interpretation, this is satisfactory language provided that eSignTrust and its auditor commit to evaluate how these phrases are actually interpreted and used. It is recommended that this language in the CPS be modified to be more specific as to what is actually used in practice.

Section 3.2.6 – eSignTrust should be aware of the Mozilla approval process in case it ever intends to cross-sign an externally operated third-party CA to issue S/MIME certificates. https://wiki.mozilla.org/CA/External_Sub_CAs

Sections 4.9.1.1 and 4.9.1.2 of the eSignTrust CPS need to address all of Mozilla’s S/MIME certificate revocation reasons stated here: https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#62-smime.

Section 4.9.2 of the eSignTrust CPS should allow the initiation of a certificate revocation request by any person who satisfactorily proves possession of the corresponding private key.

Section 4.9.12 of the eSignTrust CPS must “clearly specify the methods that parties may use to demonstrate private key compromise.” See https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#6-revocation.

Section 5.7.3 of the eSignTrust CPS states, “[eSignTrust will] Notify all RAs, Subscribers, Sponsoring Organisation, and Relying Parties of the new Issuance of certificates.” eSignTrust also needs to notify all Application Software Suppliers who have agreed to add the CA certificate to their root stores about the CA key compromise (not just about the issuance of a new replacement certificate). See https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#41-additional-requirements – “If the revocation of an intermediate certificate chaining up to a root in Mozilla’s root program is due to a security concern, as well as performing the actions defined in the CCADB Policy, a [security bug must be filed in Bugzilla](https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA Certificate Compliance&groups=crypto-core-security).”

Section 5.7.5 of the eSignTrust CPS states, “When it is necessary to terminate the CA operations of eSignTrust, the following procedures will be carried out to minimise disruption to subscribers and relying parties: Providing a minimum of ninety (90) days of reasonable notice to all RAs, certificate holders, Sponsoring Organisations, and Relying Parties; ….” Mozilla and other root stores also need to be given advance notice of the termination of CA services.

Sections 6.5 and 6.7 of the eSignTrust CPS should incorporate by reference and assert compliance with the CA/Browser Forum’s Network and Certificate Systems Security Requirements. See Item #2 in https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#21-ca-operations and also https://cabforum.org/network-security-requirements/.

Section 7.1.3 of the eSignTrust CPS states that eSignTrust supports “RSA 1024” and “SHA-1” – these are being or have been deprecated and should be removed from the CPS as options because they should no longer be made available. MD5 should be removed, too. eSignTrust should review and update this section, generally.

Section 10, Appendix A, of the eSignTrust CPS does not contain any certificate profile for an S/MIME certificate where the EKU contains emailProtection. This needs to be fixed.

Also, the CA any issues or will issue S/MIME certificates must also have the emailProtection EKU. This is according to section 5.3 of the MRSP, https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#53-intermediate-certificates:
Intermediate certificates created after January 1, 2019, with the exception of cross-certificates that share a private key with a corresponding root certificate:
MUST contain an EKU extension; and,
MUST NOT include the anyExtendedKeyUsage KeyPurposeId; and,
MUST NOT include both the id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds in the same certificate.

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:kwilson, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 10

[Ben Wilson]

Applicant needs to provide Value Statement (https://wiki.mozilla.org/CA/Quantifying_Value), root key generation information and compliance self-assessment (for those parts applicable to SMIME issuance).