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 key key to encrypted the exchanges in this session.” Certificate profiles (7.2): Incomplete entries: “Authority Key Identifier No ID of the public key of “ “Serie of characters with a random value for uniqueness” “Liste of SCT” 6.2.1. “Private key desactivation method” 4.10.1 “CRL/LAR” There are still some text blocks in French in the English CP translations E.g. “Protection des données d'activation correspondant à la clé privée de l'AC” The document seems to weave between LCR and CRL interchangeably. Recommend changing the instances of LCR to CRL or defining their equivalence in the next regular update of the document. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
