Certigna BR Review
Adding onto Nick’s suggestions, here are some notes from my review of this
application request:
Noteworthy good aspects:
- The supplied PKI diagrams are clear and useful for understanding the
hierarchy and purpose of each CA. Thank you for providing this.
- CPs are in RFC 3647 format
Comments and Questions:
“CP and terms and conditions are publicly available in a read‐only manner. The
CPS on specific request to CA.”
- Please provide the CPS documents for all CAs in this hierarchy. The
requirement is that all of these documents be published and publicly available,
not merely delivered upon individual requests
-
(https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/)
Section 10, Appendix 1 (by reference, satisfying the requirements of Section
6.2) does not define compliance with the required cryptographic module security
evaluation
- Please provide information whether the CA cryptographic modules in use meet
the required qualifications and which validation levels obtained:
- “The CA SHALL protect its Private Key in a system or device that has been
validated as meeting at least FIPS 140 level 3 or an appropriate Common
Criteria Protection Profile or Security Target, EAL 4 (or higher), which
includes requirements to protect the Private Key and other assets against known
threats.”
CA CRL (ARL) Issuance Frequency:
- CP States: “The ARL is updated at **most** once every year, and at each new
revocation.”
- Requirements state: “The CA SHALL update and reissue CRLs at **least** (i)
once every twelve months and (ii) within 24 hours after revoking a Subordinate
CA Certificate, and the value of the nextUpdate field MUST NOT be more than
twelve months beyond the value of the thisUpdate field.”
5.1.2
CP States: “In addition, any person (external service provider, etc.) entering
in this physically secure area can not be left for a significant period,
without the supervision of an authorized person.”
- What constitutes “a significant period” and why are unauthorized persons
permitted at all?
Section 6.2:
- 6.2.1, 6.2.2, 6.2.3 headings are improperly reused. I believe they should be
6.2.{10, 11, 12}
6.2.1 (The improperly labeled one) is referring to the intentional
de-activation of CA key material, not protection against an external attacker.
Recommend answering based on description of this section:
- From RFC 3647: “Who can deactivate the private key and how? Examples of
methods of deactivating private keys include logging out, turning the power
off, removing the token/key, automatic deactivation, and time expiration.”
6.2.1 (The correctly labeled 6.2.1) uses the same language in the Root CA CP as
the Sub CA CP:
- “These devices are resources exclusively available for CA’s servers through
a dedicated VLAN.”
- Can you confirm whether the Root CA is connected to the network? Is the Root
CA connected to the same network as the Sub CA (separated by a VLAN)?
The CA Certificate Profiles in Section 2.2.2 contain AIA caIssuers that point
to old CA Certificates, that is, those issued by “Certigna” and not “Certigna
Root CA". Will the URL contents be updated or the AIA pointers changed to new
URLs?
The redefinition of standardized terms (as outlined in the BRs, ETSI) makes
clear understanding of the documents more difficult. Examples:
- Relying Party → Certificate User
- Subscriber → Certificate Manager
- DTP (in the context of RA functions) → DRA
4.2.2:
“The certificate request is made, to reminder, in two separate stages: -
Sending electronic request (CSR); - Acquisition of the request (receipt signed
request files or their possibly dematerialized version).”
- It’s unclear to me what is a “dematerialized” version, as applicable to CSRs
Cert Profile:
Certificate Serial Numbers: Unique serial number greater than 128 bits and
output from a
CSPRNG (Cryptographically secure pseudorandom number generator)
- Due to the wording, it’s not entirely clear if 128 bits of entropy are
coming from the CSPRNG, but that does need to be true. Also, the policy should
limit serials to <=160 bits in length.
- Note: All serials I was able to find seem to suggest the proper rules are
being followed in practice.
CA and Leaf Certificate profiles validity don’t specify values or maximum
permissible ranges, they just restate what a validity period is
- “Validity: Dates and times of activation and expiry of the certificate”
- Using the information from Section 6.3.2 would be helpful
Similar to what Nick has observed, throughout the documents not just the BR
Self Assessment, AFNIC is cited as the sole registrar relied upon for all
verification activities.
- If more than just AFNIC will be used, recommend changing to “registrar (e.g.
AFNIC)” or something similar.
Typos:
1.5.1:
“Server authentication from other servers, as part of establishing secure
sessions, such as SSL / TLS or IPsec to establish a symmetric session k
