Closed Bug 1558450 Opened 2 years ago Closed 10 days ago

Add Digidentity Service Root Certificate

Categories

(NSS :: CA Certificate Root Program, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: sander.remmerswaal, Assigned: bwilson)

Details

(Whiteboard: [ca-cps-review] - BW 2020-10-08 Comment #17)

Attachments

(4 files, 2 obsolete files)

1.89 KB, application/x-x509-ca-cert
Details
41.28 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Details
783.15 KB, application/pdf
Details
1.59 MB, application/pdf
Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1.1 Safari/605.1.15

Steps to reproduce:

N/A

Actual results:

N/A

Expected results:

N/A

Type: defect → enhancement
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

Conformity Assessment Report for ETSI EN 319 411-1 including Point in Time audit for Digidentity Services Root CA. Period in Time audit will be performed in week of 8th July 2019.

The link below shows the CA information that has been verified. Search in the page for the word "NEED" to see where further clarification is requested.

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

In particular:

  1. Please add a comment to this bug when the audit statement URL and dates have been added to the Case.

  2. The "Digidentity Service Root CA" link on https://www.digidentity.eu/en/documentation/ appears to have the wrong URL in it.

Type: enhancement → task
Whiteboard: [ca-verifying] - KW 2019-06-17 - Comment #3

The field for the audit statement URL are locked. Statement can be found at: https://www.digidentity.eu/assets/files/terms/ETS043.pdf

The current audit statement is the Point in Time audit for the initial audit. The first period in time audit (after 90 days) will be performed on 8 July 2019. For the Point in Time, no audit start date not end date is available as this is the Point in Time.

The Digidentity Services Root CA link on the documentation page is updated to the correct certificate.

(In reply to Sander from comment #4)

Statement can be found at: https://www.digidentity.eu/assets/files/terms/ETS043.pdf
The current audit statement is the Point in Time audit for the initial audit. The first period in time audit (after 90 days) will be performed on 8 July 2019.
The Digidentity Services Root CA link on the documentation page is updated to the correct certificate.

Thanks!

Please add a comment to this bug when the period of time audit statements are available.

Whiteboard: [ca-verifying] - KW 2019-06-17 - Comment #3 → [ca-verifying] - KW 2019-06-18 - Comment #5

Updated certificate for ETS 043 including a period of time audit from 30 March 2019 until 5 July 2019.

(In reply to Kathleen Wilson from comment #5)

(In reply to Sander from comment #4)

Statement can be found at: https://www.digidentity.eu/assets/files/terms/ETS043.pdf
The current audit statement is the Point in Time audit for the initial audit. The first period in time audit (after 90 days) will be performed on 8 July 2019.
The Digidentity Services Root CA link on the documentation page is updated to the correct certificate.

Thanks!

Please add a comment to this bug when the period of time audit statements are available.

Added comment #6 with new Audit Statement containing Period of Time.

The information for this root inclusion request is available at the following URL.

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

This root inclusion request is ready for the Detailed CP/CPS Review phase, step 3 of
https://wiki.mozilla.org/CA/Application_Process#Process_Overview
so assigning this bug to Wayne.

There is a queue waiting for detailed CP/CPS reviews:
https://wiki.mozilla.org/CA/Dashboard#Detailed_CP.2FCPS_Review

It takes significant time and concentration to do a detailed CP/CPS review, so please be patient. In the meantime, I recommend looking at the results of the detailed CP/CPS reviews that have been previously completed.
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Documents_will_be_Reviewed.21

Assignee: kwilson → wthayer
Whiteboard: [ca-verifying] - KW 2019-06-18 - Comment #5 → [ca-cps-review] - KW 2019-09-18

Updated CPS on 6 December 2019. Latest CP/CP available on https://www.digidentity.eu/assets/files/terms/cp_cps_ddy.pdf

Change link to CP/CPS to reflect changes in filename of CP/CPS to comply to requirements of CCADB.

https://www.digidentity.eu/assets/files/terms/2019v4-CPCPS-DDY.pdf

New audit report is available: https://www.digidentity.eu/assets/files/terms/20200123-ETS043-411-1.pdf

Also created Audit Update case in CCADB: case number 546

Assignee: wthayer → bwilson

CAB updated ETSI certificate as incorrect SHA-2 FP was included in the previous certificate.

Attachment #9071244 - Attachment is obsolete: true
Attachment #9079529 - Attachment is obsolete: true

Digidentity has monitored the discussions on Incorrect OCSP Delegated Responder Certificates on the Forum. We investigated the certificate profiles of our SSL CA and Secure Email CA which are part of our Digidentity Services Root CA.

Both Issuing CA certificate have the OCSPsigning EKU but no id-pkix-ocsp-nocheck extension. We included the EKU for certificate validation as required by Microsoft. We omitted the nocheck extension based on the incorrect assumption that the Issuing CA is not a OSCP Responder as we configured two separate OCSP responders that have both OCSPsigning EKU and the id-pkix-ocsp-nocheck extension.

Digidentity acknowledges the security risk and has taken action to eliminate the security risk.

We have revoked the two Issuing CA and plan a key ceremony to create two new Issuing CA without the EKU. We will also perform a key destruction ceremony and formally document the key destruction process.

As the application for inclusion of the Digidentity Services Root CA to the Root Program is still in review, no certificates have been issued to customers from these CA. Certificates issued for audit purposes and internal use have been revoked. Digidentity has separated TLS and non-TLS roots so only our TLS issuing CA are affected.

Digidentity will submit the new Issuing CA to this ticket and update the CPS to reflect all changes as soon as possible.

https://crt.sh/?id=1566672109 revoked at 13.48 UTC on 8 July 2020
https://crt.sh/?id=1849145009 revoked at 13.48 UTC on 8 July 2020

Thanks for sharing this! I want to remark that it is very encouraging to see a pending CA proactively monitoring the discussions and taking appropriate steps. While this is expected, few CAs actually deliver on that, and so I want to acknowledge and explicitly call it out.

Attached file 2020-v2-CPCPS-DDY.pdf

Updated CP/CPS for Digidentity.

Review of Digidentity's Certificate Policy & Certificate Practice Statement, v. 2020-v2, 9-9-2020
https://www.digidentity.eu/assets/files/cps_en_pds/2020-v2-CPCPS-DDY.pdf

General Structure - Good

The CP/CPS contains a table of revisions and Appendix B provides Revision Details.

The CP/CPS structure is clear with CP provisions separated out by text boxes.

The CP/CPS follows the outline set forth in RFC 3647. There are no apparent blank spaces or misuse of the RFC 3647 outline.

Applicability of the Baseline Requirements - Good

Digidentity states that it conforms to the current version of the CA/Browser Forum’s Baseline Requirements and that in the event of any inconsistency between the CP/CPS, those Baseline Requirements take precedence over the CP/CPS.

PKI Hierarchy Disclosure - Good

The CP/CPS also makes clear which CAs are covered by it. E.g. Digidentity TLS CA and Digidentity Secure Mail CA under the Digidentity Services Root CA. Section 1.1.2 also provides a hierarchy diagram. The two issuing CAs are separate for publicly trusted SSL/TLS and SMIME.

Private Key Compromise and Problem Reporting - Good

Sections 1.5.2, 4.9.2, 4.9.3 and 4.9.5

These sections adequately specify that for private key compromises, people may contact Digidentity through email sent to security@digidentity.com and that Digidentity maintains a continuous 24x7 ability to accept and respond to revocation requests and Certificate Problem Reports. Section 4.9.2 states, “Subscribers, Relying Parties, Application Software Suppliers, and other third parties may submit Certificate Problem Reports informing the issuing CA of reasonable cause to revoke the certificate.” And section 4.9.5 states, “Within 24 hours after receiving a Certificate Problem Report, Digidentity will investigate the facts and circumstances related to a Certificate Problem Report and provide a preliminary report on its findings to both the Subscriber and the entity who filed the Certificate Problem Report. The maximum delay between receipt of a revocation request and the decision to change its status information being available to all relying parties shall be at most 24 hours.”

Test Certificates - Good

Digidentity hosts webpages with Subscriber test certificates. (CP/CPS 2.2)

Valid https://valid.services.digidentity-pki.com

Revoked https://revoked.services.digidentity-pki.com

Expired https://expired.services.digidentity-pki.com

Private Key Generation by Subscribers Only - Good

Mozilla Root Store Policy, section 5.2, prohibits CAs from generating private keys for TLS server certificates. Section 3.2.1 states, “For server, email, … certificates, applicants or Subscriber generate their own private key …” Also, section 6.1.1.3 of the CP/CPS provides, “For server certificates and email certificates, the Subscriber generates a new key pair for each certificate and is required to keep the private key secret as defined in the applicable Terms & Conditions.”

Naming, Domain Name Verification and Validation - Good

CP/CPS section 4.2.2 provides that CAs may not issue certificates to internal domains. The CP/CPS states, “Server certificates can be used for securing the connection between a specific client and a website which are related to a Fully Qualified Domain Name (FQDN).”

Naming practices should be compliant not only with X.500, but also with RFC 5280 and CA/Browser Forum Baseline Requirements. Digidentity may want to add language to this effect. Section 3.1 of the CP/CPS states that Digidentity recognises and interprets names per x.500 name standard to define the assignment of certificates, where a distinguished name (DN) is specified in each certificate issued, including a 64-character common name (CN) containing the “Fully Qualified Domain Name to which the certificate and key pair are assigned”.

In BR section 7.1.4.2.2.a., there is a requirement that if the CN is present in the subject DN, then the CN must contain a Fully-Qualified Domain Name that is one of the values contained in the Certificate’s subjectAltName extension. This should be made more clear in the CP/CPS.

Section 3.2.2 of the CP states that domain names included in a publicly trusted SSL/TLS Certificate must be verified in accordance with Section 3.2.2.4 of the Baseline Requirements.

If a Publicly-Trusted SSL/TLS Certificate will contain an organisation’s name, then the CA shall verify the data about the organisation and its legal existence in accordance with Section 3.2.2.1 of the Baseline Requirements using reliable third party and government databases or through other direct means of communication with the entity or jurisdiction governing the organisation’s legal creation, existence, or recognition.

In accordance with CA/Browser Forum Baseline Requirements’ section 3.2.2.4.4, CP/CPS section 3.2.2.4.4 provides that Digidentity confirms the Applicant's control over the domain name or Fully Qualified Domain Name (FQDN) by:

(i) sending an email to one or more addresses created by using 'admin', 'administrator', 'webmaster', 'hostmaster', or 'postmaster' as the local part, followed by the at- sign ("@"), followed by a Domain Name,

(ii) including a random confirmation code in the email, and

(iii) receiving a confirming response utilizing the random confirmation code.

Application Data Reuse - Good

Sections 3.2.2.7 and 4.2.1

Digidentity sets forth that for server certificate applications, documentation used in applications “should never be” older than 395 days, which is good because in the future, Mozilla will reduce the reuse period for domain validation information to that timeframe. However, this appears to conflict with section 4.2.1 of the CP/CPS which states that a CA can use documents and data provided in Section 3.2 to verify certificate information, or may reuse previous validations themselves, provided that the previous completed validation is no more than 825 days old prior to issuing the certificate. The 825-day period is consistent with subsection 5 of MRSP 2.1.

Email Verification - Good

Subsection 2 of Mozilla Root Store Policy section 2.2 requires that CAs adequately explain their email verification procedures. Digidentity has done this in section 3.2.3.2 of the CP/CPS. The CP requires the CA to take reasonable measures to verify that the entity submitting the request for a certificate to be used to sign or encrypt email controls the email account associated with the email address referenced in the certificate or has been authorised by the email account holder to act on the account holder’s behalf. In the CPS, Digidentity states that it verifies the email address by sending a confirmation code to the (requested) email address. The Applicant enters the confirmation code to confirm control over the email address. If this confirmation code is not entered, or entered incorrectly, registration will not proceed. The confirmation code is a generated as Random Value, and it is valid for seven (7) days.

OCSP - Good

Section 4.9.9 of the CP/CPS states, “The Digidentity Services Root CA, Digidentity TLS CA, and Digidentity Secure Mail CA all have a separate OCSP responder that signs OCSP responses.” So OCSP responses will not be signed directly by the CA.

Section 4.9.10 states that the OCSP responders will not respond with a "good" status for unused serial numbers. Instead, OCSP Responders under Digidentity’s control will respond to a request for the status of a certificate serial number that is “unused” with an "unknown" status.

Note: the headings for sections 7.3.3, 7.3.4 and 7.3.5 should probably say “OCSP responder certificate” etc., not Root CA, TLS CA or Secure Mail CA.

Special Requirements Related to Key Compromise - Good

Sections 4.9.12 and 5.7.1

Mozilla needs to be notified immediately whenever there is CA private key compromise. According to section 4.9.12, Digidentity has implemented measures to notify relying parties if there is discovery or suspicion that a CA’s private key has been compromised. (It is unclear why reference is made to section 4.9.1. for more information.) Section 5.7.1 also contains a representation that “Digidentity has an Incident Response Plan and a Disaster Recovery Plan. Digidentity documents a business continuity and disaster recovery procedure designed to notify and reasonably protect Application Software Suppliers, Subscribers, and Relying Parties in the event of a disaster, security compromise, or business failure.”

Certificate Suspension - Good

Digidentity does not perform suspension of certificates.

Linters and Key Validators - Good

These provisions concerning linting are very good. Digidentity has implemented CABLint, CertLint and ZLint linters verify compliance to X.509 RFCs, CA/Browser Forum Baseline Requirements, root store policies, and ETSI standards.

Section 6.1.6 of the CP/CPS has a problem with the supra font used to express the public exponent for RSA in a couple of places. It should read, “the public exponent SHOULD be in the range between 2 ^16 +1 and 2 ^256 -1” and for the RSA Key validator – “the public exponent is in the range between 2 ^16 +1 and 2 ^256 -1”. (Even here in Bugzilla it's hard to express it the right way.)

Certificate Validity Period - Good

According to section 6.3.2, TLS Certificates are valid for [no more than] 395 days. This is compliant with recent changes to the Baseline Requirements.

Network Security Controls - Good

In section 8, Digidentity represents that it is compliant with the CA/Browser Forum’s Network and Certificate System Security Requirements. In section 6.7 it states further,

Digidentity performs all technical actions, described in this document, using secure networking measures to prevent unauthorised and malicious activity. All access to systems is under the conditions of strict access controls. Digidentity protects data by using encryption and digital signatures. The controls are preventive, detective, repressive and corrective in nature. Controls include regular (at least monthly) vulnerability scans and (at least annually) a penetration test.

Certificate Serial Numbers - Good

According to section 7.1, CAs generate non-sequential Certificate serial numbers greater than zero (0) containing at least 64 bits of output from a CSPRNG, and Digidentity generates non-sequential certificate serial number using 128 bits resulting in serial numbers that have at least 64 bits of output.

SHA1 not used - Good

Digidentity does not use SHA1, it only uses RSA encryption with SHA-2 algorithm. (CP/CPS 7.1.3.)

Audits - Good

Digidentity represents that the period during which the CA issues Certificates is divided into an unbroken sequence of audit periods not exceeding one year in duration. (CP/CPS 8.1)

In section 8.5, Digidentity commits to address nonconformities registered by the auditor with a Corrective Action Plan (CAP).

Digidentity represents in section 8.6 of the CP/CPS that all Conformity Assessment Reports satisfy the Baseline Requirements and are available in the repository https://cps.digidentity-pki.com/.

Note: Digidentity should be aware that Mozilla requires that Conformity Assessment Reports be provided directly from the auditor's web site. Also, any known incidents must be disclosed to Digidentity’s auditors and mentioned in the Conformity Assessment Report. This includes all Bugzilla incidents that occurred or were open at any time during the audit period.

------------------------------------------------------------------------------

Annual CP/CPS Updating - Meh

Section 1.5.3 states that the CP/CPS is subject to a “review” at least once a year. However, it is not entirely clear that Baseline Requirement section 2.3 and Mozilla Root Store Policy section 3.3.4 are enforced, which require CAs to annually increment the version number and adding a dated changelog entry, even if no other changes are made to the document. The CP/CPS should be made more clear in this regard.

Delegation of Domain Validation to Third Parties - Meh

Mozilla does not allow CAs to delegate the performance of domain validation to third parties. See https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Delegation_of_Domain_.2F_Email_Validation_to_Third_Parties. Section 3.2 of the CP states, “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 fulfils all of the requirements of Section 3.2.” Section 1.3.2 of the Digidentity CP/CPS states that the applicable Registration Authority for all issued certificates is Digidentity. There may still be some confusion on the extent to which Digidentity engages with third party registration authorities. A very clear statement that Digidentity does not delegate domain validation to any third parties would be helpful.

CAA Record Processing - Meh

Section 3.2.2.8 states that “as specified in RFC 6844, as amended by Errata 5065 (Appendix A)”, Digidentity only issues server certificates if the CAA identifier contains "digidentity.com" for the domain requested or if there is no CAA identifier. Note that RFC 6844 has been replaced by RFC 8659.

Section 4.2 of the CP cross-references section 3.2. This is sub-optimal because the Baseline Requirements and section 4.2 of the CP say that “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.” More details about CAA review and processing in section 4.2 would help here.

Revocation Requests – Meh

Section 3.4.3 is confusing because it says that “Digidentity does not accept revocation requests via email or other means.” Then it also states that it cannot guarantee if the revocation request is not performed according to one of three procedures described.

Section 4.9.1.1 of the CA/B Forum’s Baseline Requirements contains 15 reasons for revoking an end entity certificate. (One of the reasons is if a Wildcard Certificate is used to authenticate a fraudulently misleading subordinate Fully-Qualified Domain Name. However, in section 3.2.2.6 of the Digidentity CP/CPS, it states that “Wildcard Domain Validation” is not used. Presumably this means that Digidentity does not issue wildcard certificates.) There are two other BR subsections (4 and 11) that are not clearly listed by Digidentity: “4. The CA obtains evidence that the validation of domain authorization or control for any Fully-Qualified Domain Name or IP address in the Certificate should not be relied upon” and “11. The CA is made aware of a demonstrated or proven method that exposes the Subscriber's Private Key to compromise, methods have been developed that can easily calculate it based on the Public Key (such as a Debian weak key, see http://wiki.debian.org/SSLkeys), or if there is clear evidence that the specific method used to generate the Private Key was flawed.” There is, however, a similar provision in the CP/CPS, “(11) Technical content or format of the certificate presents an unacceptable risk to Subscribers, Relying Parties and third parties (e.g. that a deprecated cryptographic/signature algorithm or key size presents an unacceptable risk and that such Certificates should be revoked and replaced within a given period of time)”.

Also, note that subsection (10) of section 4.9.1.1 of the CP/CPS states revocation is required if required "by the CA’s CP or CPS". Since this is the CA's CP/CPS, then this should say “if otherwise required by this CP/CPS”.

Section 4.9.1.2 of the CA/B Forum’s Baseline Requirements contains 9 reasons for revoking a subordinate CA certificate. Some of these reasons are repeats of those listed under section 4.9.1.1 of the CP/CPS, but they do not appear in section 4.9.1.2 of the CP/CPS. For instance, “2. The Subordinate CA notifies [Digidentity] that the original certificate request was not authorized and does not retroactively grant authorization;” “4. [Digidentity] obtains evidence that the Certificate was misused;” “5. [Digidentity] is made aware that the Certificate was not issued in accordance with or that Subordinate CA has not complied with [the Baseline Requirements] or [this] Certificate Policy [/] Certification Practice Statement;” and “6. [Digidentity] determines that any of the information appearing in the Certificate is inaccurate or misleading.” Subsection (5) of section 4.9.1.2 of the CP/CPS does, however, provide for revocation of a subordinate CA if “(5) Technical content or format of the certificate presents an unacceptable risk.” Maybe Digidentity can provide these additional reasons for revocation and/or expound on the concept of content/format presenting unacceptable risks?

Note: Section 6.2 of the Mozilla Root Store Policy also lists revocation reasons for SMIME certificates.

Multi-Factor Authentication for Systems Causing Certificate Issuance – Meh

Mozilla Root Store Policy section 2.1, subsection 3, requires CAs to “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.” Multi-factor authentication is referenced with regard to physical security in CP/CPS section 5.1.2, and section 6.5.1 states that all computer systems have “Multifactor authentication on systems” and “Multifactor authentication for online portals/interfaces,” but other than that, the CP/CPS does not specifically state that systems capable of causing certificate issuance are adequately protected with multi-factor authentication or other technical controls. It would be good if Digidentity added language to that effect.

Policy OIDs - Meh

Section 7.1.6 says that “All policy object identifiers are described in section 1.2”, but the CA/Browser Forum OIDs are not found in that section. They are listed, however, in section 7.1.10.2.

Section 7.1.6.4 provides that end entity certificates must contain a certificatePolicies extension and that the extension must contain one or more policy identifiers that indicate adherence to and compliance with these Requirements. CAs MUST either use a CA/Browser Forum identifier reserved for this purpose or MUST use a policy identifier documented by the CA in its Certificate Policy and/or Certification Practice Statement to indicate the Certificate's compliance with these Requirements.

Digidentity should be aware that now the CA/Browser Forum and Mozilla require the presence of the CA/B Forum OIDs in all TLS certificates and newly created subordinate CAs. See sections 7.1.6.3 and 7.1.6.4 of the Baseline Requirements, version 1.7.1.

Warranties - Meh

Section 9.6.1 of the CP/CPS says that Digidentity warrants to “All Application Software Suppliers with whom the Root CA has entered into a contract for inclusion of its Root Certificate in software distributed by such Application Software Supplier” that “(1) at the time of issuance Digidentity has followed the procedures in this CPS and verified that the Subscriber has the right to use or has control of the Domain Name described in the certificate.” However, Mozilla does not enter into “a contract [with Digidentity] for inclusion of its Root Certificate.” So, this provision is of less value to Mozilla if we "agree" to include the Digidentity root CA in the root store. It would be good to remove the word "contract" from this provision and replace it with the phrase "All Application Software Suppliers who have agreed to include the Root Certificate in software distributed by such Application Software Supplier."

Whiteboard: [ca-cps-review] - KW 2019-09-18 → [ca-cps-review] - BW 2020-10-08 Comment #17

Thanks Ben for your comments on the CPS. We will process your suggestions and improvements in a new version of the CPS. As we have two CPS (one CPS for Digidentity and one CPS for our participation in PKIoverheid), we will update both CPS.

Dear Ben, Digidentity has made a business decision to retract the Root CA inclusion request described in the ticket. Please close this ticket as we will no longer require our root CA to be included in the root stores.

Closing per comment #19.

Status: ASSIGNED → RESOLVED
Closed: 10 days ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.