Here are my findings after a brief review of the KIR CPS.
Review of v. 1.14 of the Certification Practice Statement of KIR for Trusted Non-Qualified Certificates (“CPS”), dated April 30, 2021.
General notes: “Foreward” should be replaced with “Foreword”. Also, KIR should start replacing references to “SSL” with the more modern term, “TLS”.
CP/CPS structured in accordance with RFC 3647 with no blank sections (MRSP § 3.3.5) (BR § 2.2)
Needs to be fixed – The CPS does not follow RFC 3647 throughout. This is especially true for CPS section numbers 1.3.3, 1.5.1, 1.5.2, 4.9.12, and sections 7.1.1 through 7.1.6. See comments below regarding section 1.3.3 (Registration authorities should be section 1.3.2), 1.5.2 (should be Contact person where KIR needs to state a means for third parties to submit certificate problem reports and revocation requests), 4.9.12 (should be revocation for key compromise) and section 7.1.4 (should be Name forms).
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)”
Adequate – Section 9.5 of the CPS states, “Copyright to this document is held by Krajowa Izba Rozliczeniowa It may be used solely for the purposes of using certificates. Any other uses, including the entire or part of the document shall require a written consent of Krajowa Izba Rozliczeniowa, provided that KIR expresses its consent to copying and publishing this document in its entirety.” Nothing appears to contradict the license required by Mozilla, but a more permissive license for the use of the CPS would be better.
Statement of adherence to BRs/EVGs and their precedence (MRSP § 2.3) (BR § 2.2 / EVG 8.3)
“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.”
Section 8.3 of the EV Guidelines contains a similar provision – “In the event of any inconsistency between this document and those Guidelines, those Guidelines take precedence over this document.”
Should be fixed – Section 1.1 of the CPS states, “KIR provides trust services in compliance with the requirements of the current version of the Baseline Requirements Certification Policy for the Issuance and Management of Publicly- Trusted Certificates published at www.cabforum.org. In the event of any discrepancies between the CSP and the said document, the document shall prevail over the CSP.” “CSP” is a typo. The last sentence would be better worded, “In the event of any discrepancies between the CPS and the Baseline Requirements, said document shall prevail over the CPS.”
Separate, EKU-constrained issuing CAs (MRSP § 5.3) (BR § 22.214.171.124.g.)
Intermediate CAs must have an EKU, not the anyEKU EKU, and not both serverAuth and an emailProtection, codesigning, or timeStamping EKU.
Should be clarified – Section 7.1 lists the types of EKUs and what they are for: “clientAuthentication – verification of the customer’s certificate, serverAuthentication – verification of the server’s certificate, codeSigning – for signing the application code, emailProtection – for electronic mail protection”, but I did not see separate certificate profiles for EKUs for issuing CAs. Section 7.1 does say, “In case of SSL certificates extension extendedKeyUsage includes the following values: serverAuthentication and clientAuthentication.” However, this requirement only applies to intermediate CAs created after January 1, 2019. A review of the SZAFIR Trusted CA2 created in 2015 shows that these EKUs are not in the Issuing CA that is currently in use.
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.”
OK – Sections 1 and 2 of the CPS mention the Szafir Root CA and the Szafir Root CA2 and subordinate 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.
Should be fixed – Section 9.12.1 of the CPS should be revised to state something to the effect that “KIR updates the CPS on at least an annual basis, even if there are no other changes, and implements the latest version of the CA/Browser Forum Baseline Requirements.”
Statement of Non-Delegation for Domain Validation (BR § 1.3.2)
“With the exception of sections 126.96.36.199 and 188.8.131.52, 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.”
Should be fixed – Section 1.3.3 of the CPS (this should be section 1.3.2, according to RFC 3647), should explicitly say that KIR does not delegate domain validation to any third parties, e.g. “Tasks of registration authorities are carried out only by organisational units of KIR, and no third parties are delegated responsibility to perform domain validation.” (Because the email trust bit is enabled for KIR, this applies to the domain part of an email address (see below), too, in the event that KIR is deploying email certificates through an enterprise RA.)
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.”
Needs to be fixed – Section 1.5.2 of the CPS needs to tell subscribers and third parties where and how they can report “suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates.”
Naming compliant with X.500, RFC5280, and Baseline Requirements
The structure and use of names in certificates must comply with the Baseline Requirements, and other standards such as X.500 and RFC 5280.
Should be fixed – Sections 3.1, 3.2.2, 7.1.2 and 7.1.3 of the CPS adequately discuss naming for end entity certificates but do not reference KIR’s compliance with X.500, RFC 5280 and the Baseline Requirements. Section 3.1 or 7.1.4. of the CPS should contain KIR’s commitment to comply with naming schemes required by X.500, RFC 5280 and the Baseline Requirements.
No internal names or reserved IP addresses (BR § 184.108.40.206.1)
“CAs SHALL NOT issue certificates with a subjectAltName extension or subject:commonName field containing a Reserved IP Address or Internal Name.”
Good – Section 7.1.3 of the CPS says, “SSL certificates may not contain IP addresses in the subject and subjectAltName fields. Additionally, certificates in the subject and subjectAltName fields may not contain domain names that are not registered in the DNS system.” So Reserved IP Addresses and internal host names in certificates should not be a problem. The CPS also contains several other instances where Fully Qualified Domain Names are specified. E.g. CPS Section 3.1 says, “Name of the internet domain interested in the internet DNS system for which the certificate has been issued”. Section 3.1.1. says, “In particular, the subscriber's distinguished name for an SSL certificate should contain a Fully Qualified Domain Name (FQDN).” And section 1.4.1 says, “Certificates of that type may be issued only for servers that operate in public networks and have a non-ambiguous domain name defining location of a specific node in the DNS system (FQDN - Fully Qualified Domain Name)”
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 §§ 220.127.116.11 and 18.104.22.168 (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 by a man-in-the-middle to facilitate surreptitious interception by third parties (except with the domain registrant's permission).]
Needs to be fixed – Please make reference to the specific subsections in section 22.214.171.124 of the CA/Brower Forum’s Baseline Requirements for validation steps taken to verify an FQDN. CPS Section 3.2.2 states:
• confirming control over the requested Domain Name by placing indicated by KIR random data in file kirdv.txt under the "/.well-known/pki-validation" directory, or another path registered with IANA for the purpose of Domain Validation. The file with random data has to be accessible by KIR via HTTP or HTTPS over an Authorized Port. Random data in file is unique for every certificate request, does not appear in the request and data is not older than 30 days.;
• the alternative way of checking the control over the requested Domain Name is placing the random data given by KIR in DNS record TXT, CAA or CNAME type. Random data sent by KIR are unique for each validation and they are not older than 30 days, and CAA record checked not earlier than 8 hours before certificate generation;
In other words, the CPS should additionally state that KIR complies with BR section 126.96.36.199.18 Agreed-Upon Change to Website v2 and 188.8.131.52.7 DNS Change.
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.”
Needs to be fixed – The CPS needs to say that KIR performs a challenge-response verification for email addresses included in SMIME certificates (or at least it will validate the domain part for email addresses included in SMIME certificates issued in the context of an enterprise RA). See https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Email_Challenge-Response and https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Verifying_Email_Address_Control
Data sources need to be accurate (BR § 184.108.40.206)
“[For a] Reliable Data Source, the CA SHALL evaluate the source for its reliability, accuracy, and resistance to alteration or falsification.”
Needs to be fixed – CPS sections 3.1.4, 3.2, and 3.2.2 discuss reliable information sources. However, KIR needs to disclose its process for determining that a third-party data source is reliable. Section 220.127.116.11 of the Baseline Requirements says, “The CA SHOULD consider the following during its evaluation:
\1. The age of the information provided,
\2. The frequency of updates to the information source,
\3. The data provider and purpose of the data collection,
\4. The public accessibility of the data availability, and
\5. The relative difficulty in falsifying or altering the data.”
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.”
Needs to be fixed – Section 3.2.4 of the CPS should state, “All information in the certificate is verified.”
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.”
Needs clarification – CPS section 6.3.2 states, “The maximum validity period of SSL certificates is 398 days from the date of certificate generation.” However, it is unclear whether KIR uses any information collected from previous certificate requests. Section 3.3 of the CPS says, “Verification of the agreement validity and data included in the agreement and in the order shall be done in accordance with Clause 3.2.” This implies that all information is collected and verification is re-performed for every single renewed certificate. KIR needs to state more clearly whether it reuses any data.
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 – Section 4.2.4 of the CPS says, “Before generating the certificate, KIR checks Certification Authorities Authorization (CAA) records, authorizing certificate authorities to issue certificates for given domains. If the CAA record is present, then KIR generates the certificate only if the CAA records include the following name: elektronicznypodpis.pl.”
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”.
Needs to be fixed – I could not find the phrase “multi-factor authentication” in conjunction with “accounts capable of 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.”
Should be fixed – Pre-issuance linting does not appear to be mentioned in the CPS.
Revocation in accordance with BR section 4.9.1 (MRSP § 6.1) (BR §§ 18.104.22.168 and 22.214.171.124)
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 – Please refer to sections 126.96.36.199 and 188.8.131.52 of the Baseline Requirements. There are two parts to BR section 184.108.40.206, including mandatory 24-hour revocation for the five reasons set forth therein. E.g., “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”. KIR should carefully review both section 220.127.116.11 and section 18.104.22.168 of the Baseline Requirements and ensure that it has adequately addressed the revocation reasons and timeframes from the BRs.
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 … [e.g. MRSP § 6.2, ”5. the CA receives notice or otherwise becomes aware of any circumstance indicating that use of the email address in the certificate is no longer legally permitted;”]
Needs to be fixed – KIR should review MRSP section 6.2 and make sure it has covered the revocation reasons for SMIME certificates.
CRLs at least every 7 days w/ nextUpdate not more than 10 days (MRSP § 6)
Adequate –Section 4.9.7 of the CPS says, “CRLs for certificates issued by the operational certification authority Szafir Trusted CA shall be published always after certificate suspension or revocation, however, not less frequently than every 24 hours.” (KIR should ensure that the nextUpdate for CRLs is less than 10 days.)
Clearly specify methods to demonstrate private key compromise (MRSP § 6)
Needs to be fixed - Mozilla now requires that Section 4.9.12 of the CP/CPS describes the method by which any party can demonstrate private key compromise to KIR. KIR needs to renumber this section so that section 4.9.13 is suspension. See next.
CA must not allow certificate suspension (BR § 4.9.13)
Needs to be fixed. Section 4.9.12 of the CPS appears to allow certificate suspension. This is prohibited for TLS server certificates.
OCSP updates every 4 days w/ max. expiration of 10 days (MRSP § 6)
Needs to be fixed – Section 4.9.9 does not disclose how often KIR updates OCSP responses and their validity period.
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.”
Needs to be fixed – KIR needs to ensure that its disaster recovery and key compromise plans require that someone immediately notify Mozilla and other root stores that have trusted the KIR PKI hierarchy. This requirement on KIR should be made clear in the CPS.
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.”
Needs to be fixed – Section 6.1.1 of the CPS says “Keys for subscribers may also be generated by the Szafir Trusted CA both in the cryptographic cards or in the form of files. Keys generated in files are password protected.” However, it should say that KIR never generates key pairs for server certificates.
Must meet RSA key requirements (MRSP § 5.1)
Could be improved – CPS section 6.1.5 says, “SSL Certificates shall be issued for RSA keys having the length at least of 2048 bits and SHA-256 hash functions.” However, sections 6.1.5 and 6.1.6 could be improved after a review of https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#511-rsa, etc. and corresponding sections of the Baseline Requirements. Pre-issuance linting may also provide KIR with additional safeguards that protect KIR from mis-issuing server certificates.
Must meet ECC key requirements (MRSP § 5.1)
Could be improved – It appears from section 7.1.1 of the CPS that ECC is not supported, however, the quality of any submitted ECC key needs to be ensured. Sections 6.1.5 and 6.1.6 could be improved with reference to
and corresponding sections of the Baseline Requirements. Pre-issuance linting may also provide KIR with additional safeguards that protect KIR from mis-issuing server certificates.
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 – CPS section 6.3.2 states, “The maximum validity period of SSL certificates is 398 days from the date of certificate generation.”
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”.
Needs to be fixed – Section 6.7 of the CPS states, “Access to the communication and IT system in which trust services are provided shall be protected at the level specified in the law for qualified trust services. Supervision over security of the computer networks of KIR is exercised by qualified staff.” Compliance with the CA/Browser Forum’s Network and Certificate System Security Requirements should be ensured with incorporation of it, in its entirety, by reference. See https://cabforum.org/network-security-requirements/ .
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.”
Needs to be fixed – Section 7.1 of the CPS concerning serial numbers does not recite this specification.
EKUs required in certificates issued after 7-1-2020 (MRSP § 5.2) (BR § 22.214.171.124.f)
Good – The EKUs of end entity server certificates can contain both serverAuth and clientAuth but the anyExtendedKeyUsage EKU cannot be present. Section 7.1 says, “In case of SSL certificates extension extendedKeyUsage includes the following values: serverAuthentication and clientAuthentication.”
Use of SHA-1 prohibited (MRSP § 5.1.3) (BR § 126.96.36.199.1)
Good – Section 7.1.1 of the CPS states, “SSL Certificates shall be issued for RSA keys having the length at least of 2048 bits and SHA-256 hash functions.”
Any CN must also be in a SAN (BR § 188.8.131.52.2.a)
Needs to be fixed – The CPS should state that any commonName field in the certificate Subject DN has to be one of the FQDN SANs that has been validated pursuant to one of the allowed methods in BR section 184.108.40.206.