Review of Digidentity's Certificate Policy & Certificate Practice Statement, v. 2020-v2, 9-9-2020
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 firstname.lastname@example.org 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)
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 126.96.36.199 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 188.8.131.52.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 184.108.40.206 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 220.127.116.11 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 18.104.22.168.4, CP/CPS section 22.214.171.124.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 126.96.36.199 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 188.8.131.52 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 184.108.40.206 and 220.127.116.11, 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 18.104.22.168 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 22.214.171.124 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 126.96.36.199 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 188.8.131.52 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 184.108.40.206 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 220.127.116.11 of the CP/CPS, but they do not appear in section 18.104.22.168 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 22.214.171.124 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 126.96.36.199.
Section 188.8.131.52 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 184.108.40.206 and 220.127.116.11 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."