Thank you very much for this analysis and the time past on our request.
You will find below additional information following your comments
-----------------------------------------------------------------------
The public CPS for our CA that issued SSL/TSL certificates (Certigna Services CA and Certigna Wild CA) are already available at the following links :
- All CP/CPS:
https://www.certigna.fr/autorites/index.xhtml
- CPS of Certigna Services CA:
http://politique.certigna.fr/en/DPCcertignaservicesca.pdf
- CPS of Certigna Wild CA:
http://politique.certigna.fr/en/DPCcertignawildca.pdf
CPS for the other CAs will be published soon.
-----------------------------------------------------------------------
> 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.”
>
The cryptographic module used by the CA is certified CC EAL4+ and FIPS 140-2 Level 3 and is qualified at “Reinforced” level according the process described by the French standard “RGS”. To obtain this qualification by ANSSI, the module has to be EAL4+ certified at the minimum, that is why we have just used this requirement.
The new versions of our CP/CPS integrate explicitly these requirements (EAL4+ or FIPS 140-2 Level 3) at chapter 10.2.
-----------------------------------------------------------------------
> 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.”
>
We have replaced “At most” by “At least” in the associated sentence.
-----------------------------------------------------------------------
> 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?
>
This is a requirement from the French standard (RGS). We have deleted this ambiguous precision, because, in facts, the authorized person always supervises the other persons in a secured area and never let them alone.
-----------------------------------------------------------------------
> 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.”
>
Following information about deactivation of CA private key have been added to this chapter 6.2.1.
“The deactivation of a CA private key that must no longer be operational is performed by destructing this key in the cryptographic module. In the case where the cryptographic module is dedicated to this key, the module can then be turned off in order to deactivate this key.”
-----------------------------------------------------------------------
> 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 keys of our Root CAs are off line and not stored inside the cryptographic module with the keys of our intermediate CAs.
-----------------------------------------------------------------------
> 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?
>
We are waiting for the inclusion of our new root CA before replacing these URLs with those of the new Certigna Root CA.
-----------------------------------------------------------------------
> 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
>
We are sorry about this, but these terms come from our national standard (RGS), and the roles and responsibilities are clearly not always the same with BRs and ESTI standards. The majority of our customers being actually concerned by the RGS, so we are using this terms for their good comprehension. But we will try in the future versions of our CP/CPS to migrate to the terms used by BRs and ETSI standards.
>
> 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
>
Signed request files are not the CSR in this sentence but all the documentation required for the application (e.g. Official identity documents, application form, …). The process allows the applicant to send these documents through a digital way. We have updated the new versions of our CP/CPS to replace “Signed request files or their possibly dematerialized version” by “the forms and evidences”.
>
> 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.
>
Indeed, we apply these requirements, and we have not identified the necessity to defined that the serialNumber field is limited to 160 bits in length. We have updated the new versions of our CP/CPS at chapter 7 to explicitly defined it.
>
> 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
>
We have updated the new versions of our CP at chapter 7 to explicitly defined the maximum permissible range in validity field for each end-user certificate profile.
> 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.
>
>
We have updated the new versions of our CP/CPS on this point with your recommendation.
>
> 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.
We have updated the new versions of our CP/CPS to correct these mistakes.
We hope that these elements meet your expectations and remain at your disposal for any further information.