I reviewed SSLCOM Group’s CPS, v. 1.3, dated July 2019
Downloaded here https://bugzilla.mozilla.org/attachment.cgi?id=9079230 and from https://www.sslcomgroup.com/repository here: https://c9881787-42f4-4380-9be9-86127682c182.filesusr.com/ugd/e6d025_bc04855d3d454d52a86f95b0fb044a34.pdf
My initial comments and observations are as follows:
1.2. Document Name and Identification
Document is titled, “SSL Certificate Practice Statement” but then in section 1.3.1 is referred to as a “Certificate Policy”. If this a combined CP/CPS, then it should so state.
CPS complies with RFC 3647 framework – good
The CPS provides that “In the event of any inconsistency between this CPS and the Baseline Requirements, the Baseline Requirements take precedence over this CPS.” That is good.
1.3.2. Registration Authority
Mozilla Policy disallows delegation of domain name and IP address validation. This section states, “No Delegated third parties are allowed.” That is good.
1.4.2. Prohibited Usage
While not currently required by Mozilla Policy, this section does not say anything about prohibiting use of SSL/TLS certificates for traffic interception / MITM.
1.5.1 Organization administrating the document
Revision history indicates that the CPS was last edited July 13, 2019, which is shorter than a year, so that is good.
1.5.2. Contact person
As required by section 4.9.3 of the Baseline Requirements, this section is required to provide clear problem reporting and revocation request instructions through a readily available means. This section needs to be modified to do that.
1.6. Definitions and Acronyms
Definitions for Root CA and Online CA are identical: “The top level Certification Authority whose Root Certificate is distributed by Application Software Suppliers and that issues Subordinate CA Certificates.”
2.1. Legal Document Repositories
States that the CPS shall be reviewed annually for any updates and changes. However, Mozilla Policy requires that the CPS also be re-versioned, even if there are no updates or changes. Please make this correction to your language.
Somewhere in section 3.1 or one of its subsections in the CPS, you should acknowledge that internal names and reserved IP addresses are prohibited. (See BR Section 126.96.36.199.1)
3.1.1. Types of Names and 3.1.4 Rules of Interpretation
Not only must naming comply with X.500, but it must also comply with RFC 5280 and the CA/Browser Forum’s Baseline Requirements.
3.1.2. Meaning of Names
For SSL/TLS certificates, the CN is allowed (optional), but it can only contain information that is in one of the subjectAlternativeNames. The CPS should state this somewhere.
3.2.1. Private Key Possession and 188.8.131.52. Subscriber Key Pair Generation
Section 3.2.1 states “the private key will at no point in time be in the possession of the SSLCOM CA.” Section 184.108.40.206 states, “SSLCOM is not involved in the generation of subscriber keys.” That is good - these provisions meet Mozilla requirements that the CA does not generate the private key pairs of subscribers.
220.127.116.11. CAA Verification
Is this a method of domain validation? It seems confusing and doesn’t have a corresponding cross-reference to the Baseline Requirements.
3.2.3. Personal Identification
This section is confusing because the following methods appear to establish the identity of an organization more than they do a natural person:
- A government agency in the jurisdiction of the Applicant’s legal creation, existence, or recognition; OR
- A third party database that is periodically updated and considered a Reliable Data Source; OR
- A site visit by the CA or a third party who is acting as an agent for the CA; OR
- An Attestation Letter.
3.2.4. Non Verified Subscriber Information
This section should be re-written to state something similar to: “The SSLCOM CA shall not include any non-verified individual or organizational information in the certificate.”
3.3. Identification and Authentication for Re-key Requests
There are a couple of unclear sentences: (1) “: A CSR shall be submitted. original, valid key.” (2) “Upon validation, a new Certificate key will be issued.”
4.2.2. CAA Record Processing
RFC 6844 has been replaced by RFC 8659.
4.3.2. Notification to Subscriber of Certificate issuance
This sentence has a few errors, including a wrong cross-reference. “Following verification of all required details in Application Request, the RA shall send a confirmation email to the Applicant, including a Random Value generated coded, as specified is section 3.2.4 above.”
4.6. Certificate Renewal
Section 4.2.1 of the Baseline Requirements allows SSLCOM to re-use verification information for renewal, but that use is limited to 825 days (“provided that the CA obtained the data or document from a source specified under Section 3.2 or completed the validation itself no more than 825 days prior to issuing the Certificate”). (That period will likely be shortened in the future.)
4.7 Certificate Re-key
This section says, “Certificate Re-key is not supported.” But section 3.3 describes how to perform a re-key. This causes confusion.
18.104.22.168. Subscriber Certificate Revocation
Section 22.214.171.124 of the Baseline Requirements requires revocation within 24 hours and does not allow a generally worded delay in the 24-hour requirement for “confirming the Subscriber identity.” The Baseline Requirements also list 15 reasons to revoke a Subscriber’s certificate, but the CPS only lists 10. Also, in the Baseline Requirements, there are 9 reasons listed to revoke a subordinate CA, but the CPS only lists 5.
4.9.2. Who Can Request Revocation
The CPS should acknowledge that third Parties are entitled to submit a Certificate Problem Report under section 4.9.2 of the Baseline Requirements, and then additional information should be located in section 1.5.2 of the CPS.
This section needs to be made compliance with Section 4.9.5 of the Baseline Requirements, which states, “The period from receipt of the Certificate Problem Report or revocation-related notice to published revocation MUST NOT exceed the time frame set forth in Section 126.96.36.199.” That is, for the 4 listed reasons, revocation must occur within 24 hours, and 5 days are allowed for the other 11 reasons.
4.9.9. On-line Revocation Availability and/or 4.10.1. Operational characteristics
One of these sections should state that OCSP responses are updated at least every 4 days with a maximum lifetime of 10 days. (Mozilla Root Store Policy, Section 6). https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#6-revocation
5.7. Compromise and Disaster Recovery or 5.8. CA or RA Termination
The listing of components of the Business Continuity Plan is good.
However, in the event of a compromise or business termination, Mozilla and the other root store operators must be notified immediately. That should be added to your incident response procedures.
188.8.131.52. RA key Pair Generation
This section is blank. Blank sections are not allowed. See Item 5 in Mozilla Root Store Policy, Section 3.3. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses
6.3.2. Key Usage Periods
SSLCOM should consider amending the maximum certificate validity period for Subscribers to 397 days (in line with requirements coming into effect on 1-Sept-2020).
6.5.1. Specific computer security technical requirements
This section states that multi-factor authentication method is enforced for all accounts directly involved with certificate issuance. This is good.
6.7. Network Security Controls
SSLCOM should consider attesting to its compliance with the CA/Browser Forum’s Network and Certificate System Security Requirements, https://cabforum.org/network-security-requirements/.
7.1.1. ROOT CA Certificate Profile and 7.1.2. ONLINE CA Certificate Profile:
The encoding for the issuer DN and the subject DN should be identical.
It appears that SSLCOM uses PrintableString and UTF8String (and not TeletexString).
The profile should also acknowledge that the CAs include the basicConstraints field, marked critical, where CA is TRUE.
7.1.3. Web Server Subscriber DV Certificate Profile
DV certificates are not allowed to have “surname and given-name” or “EmpNo. or ID No. or Passport No.”
The serverAuth EKU is required (not the Smartcard Logon EKU).
Note: No OV certificate profile was provided, only a DV certificate profile.
9.5. Intellectual Property Rights
According to section 3.3 of the Mozilla Root Store Policy, a Creative Commons License (Attribution-NoDerivs) is granted to the CPS. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses
The items above should be corrected by SSLCOM and then I will perform a second and more thorough review.