Certigna Root Renewal Request

[a...@mozilla.com]

This request from the Dhimyotis/Certigna is to include the SHA-256 ‘Certigna Root CA’ certificate and turn on the Websites and Email trust bits. This root certificate will eventually replace the SHA-1 ‘Certigna’ root certificate that was included via Bugzilla #393166.

Dhimyotis, t e name of the company, is a commercial CA and Certigna is the brand for their certificates.

The new ‘Certigna Root CA’ has 7 internally operated subordinated CAs :
- Identity CA : encipherment, authentication and/or digitally-signed email
- Identity Plus CA : authentication and/or digitally-signed email
- Entity CA : seal (EKU : emailProtection or timeStamping)
- Entity Code signing CA : seal (EKU : codeSigning)
- Services CA : SSL (EKU : authServer or authClient)
- Wild CA : SSL (EKU : authServer and authClient)
- FR03 : Seal

The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1265683

BR Self Assessment is here:
https://bugzilla.mozilla.org/attachment.cgi?id=8861810

Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=8862251

* Root Certificate Download URL:
http://autorite.dhimyotis.com/certignarootca.der

* The CP documents are in French and translated into English.

Document Repository: https://www.certigna.fr/autorites/index.xhtml
CP - Root CA: http://politique.certigna.fr/en/PCcertignarootca.pdf
CP - Services CA: http://politique.certigna.fr/en/PCcertignaservicesca.pdf
CP - Wild CA: http://politique.certigna.fr/en/PCcertignawildca.pdf

* CA Hierarchy
Certificate Hierarchy Diagram : https://www.certigna.fr/autorites/index.xhtml

* The request is to enable the Websites and Email trust bits

** Section 4.2.1 of CP - Services CA and CP - Wild CA : "The verification of the FQDN and the entity holding it is achieved using "WHOIS"websites and of the AFNIC website if applicable. A legal representative of the entity which hold the domain must formally designate the RC and its entity in a domain authorization document signed by that representative (request form or specific form provided by the CA)."
*** This corresponds to BR section 3.2.2.4.5 Domain Authorization Document

* EV Policy OID: Not Requesting EV treatment

* Test Websites
Valid certificate : https://valid.servicesca.dhimyotis.com
Expired certificate: https://expired.servicesca.dhimyotis.com
Revoked certificate: https://revoked.servicesca.dhimyotis.com

* CRL URLs:
Root CAs: http://crl.certigna.fr/certignarootca.crl
Subordinated CAs : https://www.certigna.fr/autorites/index.xhtml
Frequency of updating CRL is described in chapters 2.3 and 4.9.6 of the CP/CPS

* OCSP URLs:
URI for SSL certificates : http://servicesca.ocsp.certigna.fr/
Frequency of updating OCSP is described in chapter 4.9.6 of the CP/CPS.
The maximum time elapsing from the revocation of an end entity or CA certificate until OCSP responders are updated to reflect that revocation : 1 hour

* Audit: Annual audits are performed by LSTI according to the ETSI TS 102 042 / 101 456 criteria.
https://bug1265683.bmoattachments.org/attachment.cgi?id=8856978

* Potentially Problematic Practices : None Noted
(https://wiki.mozilla.org/CA:Problematic_Practices)

This begins the discussion of the request from Dhimyotis/Certigna to include the SHA-256 ‘Certigna Root CA’ certificate and turn on the Websites and Email trust bits.

Aaron

[Aaron Wu]

All,

I will greatly appreciate your help in reviewing and commenting on this root inclusion request from Certigna.

Thanks,
Aaron

[josselin....@gmail.com]

The ticket is open since 3 months. This seems to be correct for everyone.
Is it possible to close it now ?

[Kathleen Wilson]

> This request from the Dhimyotis/Certigna is to include the
> SHA-256 ‘Certigna Root CA’ certificate and turn on the
> Websites and Email trust bits. This root certificate will
> eventually replace the SHA-1 ‘Certigna’ root certificate
> that was included via Bugzilla #393166.

> ...

> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1265683

This CA has provided an updated BR Self Assessment:
https://bugzilla.mozilla.org/show_bug.cgi?id=1265683#c25

I will greatly appreciate constructive feedback on this CA's root renewal request.

Thanks,
Kathleen

[Nick Lamb]

Thanks Kathleen,

I have briefly inspected this BR Self Assessment document. Nothing terrifying leaped out at me that would lead me to ask that Mozilla deny the renewal, however I did find things worth mentioning here.

The only listed 3.2.2.4 method is 3.2.2.4.5, Domain Authorization Document. This explains why Certigna has chosen to outsource the validation to an RA, the documents for 3.2.2.4.5 might require local expertise to obtain and interpret, as distinct from technical and automatable methods like 3.2.2.4.10. Nevertheless, involvement of human agents is always a weak point in security systems, we saw with Symantec that problems can arise if the CA outsources this work but doesn't make the effort to inspect what is being done on their behalf. So we need to keep a particular eye on the results.

AFNIC is mentioned by name. I understand that Certigna specialises in particular in French-speaking locales (maybe mostly ex-French colonies?) but it's not obvious to me in these documents whether Certigna by policy doesn't issue certificates for names that aren't under AFNIC's control. If not, why call them out particularly?


For 3.2.2.6 Wildcard Domain Validation the submission responds with a lot of content about validation of identities. Section 3.2.2.6 actually concerns special considerations for the dnsName wildcard, such as verifying whether the requested wildcard is for a Public Suffix or Registry-controlled Label. It is important that the CA has some procedure to avoid issuing, for example, *.co.uk or other wildcards that must not exist and this procedure should be in their policy documents AND the relevant sections highlighted in the assessment. Is this an error by Certigna? Or do I misunderstand the requirement here?

For 4.2.1 Mozilla's document specifically requests information about the CA's policy for High Risk Certificate Requests. Nothing is indicated about this. [ Kathleen: Consider *bolding* the relevant text for emphasis so that it stands out from cells which are just repeating the relevant RFC section header name? ]

For 4.9.{2,3} We need clarity on how Relying Parties, including but not limited to people who read m.d.s.policy can report a problem with a certificate despite not being the subscriber or a representative of the subscriber. This isn't listed - but maybe it is actually documented somewhere? I think previous m.d.s.policy discussions found that the most appropriate thing is to supply an email address to which such problems can be reported.

[J. Allemandou]

Thank you very much Nick for this analysis and the time past on our request.

You will find below additional information. The publication of the updated CP / CPS will be immediate, as soon as you confirm that the level of detail is sufficient for you.

Thank you in advance for your help and your reply.

- Afnic control

For each TLS/SSL certificate request, controls through “Whois” websites are systematically performed by RA operator with a screen-shot add to validation proofs. For French websites, as recommended by the "RGS" French standard, the operator performs an additional control through the AFNIC website, that why we mentioned explicitly this website.

- Wildcard Domain Validation

Indeed, the process is not formally described in the CP on this subject. An automatic process is implemented, when ordering a wildcard SSL certificate, to verify that the requested domain name is made up as "*.domain.tld". To consolidate this check, TLDs validated by ICANN are everyday automatically retrieved through the list on the https://publicsuffix.org website.
In addition, the verification of the domain name owner performed by the RA will in all cases lead to a rejection of the application as it is impossible to identify the owner of a domain name of type "*.tld". Applications with an invalid TLD or non-domain (E.g. *.co.uk) will therefore be systematically rejected.

- High Risk

Our CP/CPS have been updated with a chapter named “3.2.6 Verification of Certain Information Sources” which integrate the following description of our practices about this:

“High risk status
The CA develops, maintains, and implements documented procedures that identify and require additional verification activity for High Risk Certificate Requests prior to the Certificate’s approval, as reasonably necessary to ensure that such requests are properly verified under these Requirements.
In particular, the RA is carried out controls with databases of domain names that are suspected to be used for phishing activities (sources related to “APWG” and “Phishing initiative”) and with CA’s internal databases of revoked certificates for compromising reason or request of certificates which are suspected to be used for phishing activities.”

- Contact

Terms and conditions (chapter 20) indicate the email address con...@certigna.fr for every request.

This information will be added to CP/CPS at chapter 1.6.2.

Terms and conditions (chapter 21) indicate that a form is available on Certigna website for reporting a malicious and dangerous certificate. Other requests can be performed through this form.

This information will be added to CP/CPS at chapter 2.2.4.

Terms and conditions: http://cgu.certigna.fr/en/CGU_CERTIGNA_SERVICES_CA.pdf
CP: http://politique.certigna.fr/en/PCcertignaservicesca.pdf
Form: https://www.certigna.fr/contact.xhtml

Thank you in advance for your help and your reply.

Best regards

[asymm...@chromium.org]

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.

[josselin....@gmail.com]

Thank you very much for this analysis and the time past on our request.

You will find below additional information following your comments


-----------------------------------------------------------------------

> “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/)

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.

[josselin....@gmail.com]

Just to let you know that CPSs for certificates that are not used for website authentication will be available by January 15, 2018. CPS for SSL / TLS certificates are already available in French and English versions.

Best regards

[josselin....@gmail.com]

In order to finalize our integration request, I would like to inform you of new information:
- We have published all our CPs and CPSs updated on 25/01/2017 in French and English version : https://www.certigna.fr/autorites/index.xhtml
- We have updated our integration ticket (https://bugzilla.mozilla.org/show_bug.cgi?id=1265683), because under this authority, we now issue QCP-w/EV qualified certificates. We have updated the Attestation letter and the document "Initial Information Gathering Document"

Could you ensure that the Certigna Root CA integration can enable EV recognition for this root authority.

We remain at your disposal for any further information.

Thanking you in advance for your help.

Best regards

[josselin....@gmail.com]

We hope to have provided all the expected answers and documentation. Could you please tell us if the processing of our integration request will progress.

Thank you for your reply.

Best regards.

[josselin....@gmail.com]

[westm...@gmail.com]

Hello,
This request will be rejected or will be pending?

Enjoy,
Andrew.

[asymm...@chromium.org]

Hello,

Based on the updated documentation, I've compiled the following questions for clarification:

------------

CPS Section 1.4.2 states "Unless stated otherwise, in this document, “RA” covers the Registration Authority and Delegate Registration Authorities."
CPS Section 3.2 calls out DRAs ability to perform initial identity validation steps and uses the phrasing “RA (RA or DRA)” at the beginning of the section.
CPS Section 4.2.1 states that during the identification and request validation process, that a DRA forwards the steps undertaken (including validation of domain control), and the RA "ensures that the request corresponds to the mandate of the DRA operator"

Due to the language in 1.4.2 stating that unless stated otherwise, “RA” refers to both Registration Authorities and Delegated Registration Authorities, can you direct me to where in the CP/CPS it calls out that DRAs, Certificate Managers, and Certificate Agents (as defined in Section 1.4.5) are specifically unable to perform the validation checks of 3.2.2.4 and 3.2.2.5? Additionally, what does it mean for an RA to “ensure that the request corresponds to the mandate of the DRA operator”?

------------
CPS Section 4.2.1: If the request is valid and allows to obtain with accuracy the authorization to issue the certificate by a legal representative of the entity which is owner of the domain names, the CA authorizes itself to issue the certificate even if the CA is not present in the list of authorized CA.

This appears to directly contravene BR Section 3.2.2.8, which specifies the following 3 scenarios in which a CA can issue a certificate despite not appearing in the CAA record:
• CAA checking is optional for certificates for which a Certificate Transparency pre-certificate was created and logged in at least two public logs, and for which CAA was checked. Forum Guideline Baseline Requirements, v. 1.6.0 21
• CAA checking is optional for certificates issued by a Technically Constrained Subordinate CA Certificate as set out in Baseline Requirements section 7.1.5, where the lack of CAA checking is an explicit contractual provision in the contract with the Applicant.
• CAA checking is optional if the CA or an Affiliate of the CA is the DNS Operator (as defined in RFC 7719) of the domain's DNS.

------------
CPS Section 3.2.7 calls out special actions taken for “High Risk Certification Requests”. It says the procedures for determining high risk as well as additional vetting requirements are documented, however, I do not see this documentation anywhere.

On what basis is a certification request deemed “high risk” and in what way, specifically, does this impact a subscriber’s ability to obtain a certificate?

------------
Root CA CP Section 4.3.2: The delivery of certificate is achieved during the key ceremony, to a CA administrator authorized by CA and in charge of its exploitation and diffusion.

Can you please explain what these sentences mean? This sub-section is cited as the response to BR Section 4.3.1 CA Actions during Certificate Issuance in the latest version of the BR self-assessment, but does not appear to speak to this requirement.

------------

[josselin....@gmail.com]

Thank you very much Devon for this analysis and the time past on our request.

You will find below additional information. Sorry for the delay, I was on vacation. The publication of the updated CP / CPS will be immediate, as soon as you confirm that the level of detail is sufficient for you.

Thank you in advance for your help and your reply.

----------------------------------------------------------------------------

CPS Section 1.4.2 states "Unless stated otherwise, in this document, “RA” covers the Registration Authority and Delegate Registration Authorities."
CPS Section 3.2 calls out DRAs ability to perform initial identity validation steps and uses the phrasing “RA (RA or DRA)” at the beginning of the section.
CPS Section 4.2.1 states that during the identification and request validation process, that a DRA forwards the steps undertaken (including validation of domain control), and the RA "ensures that the request corresponds to the mandate of the DRA operator"
Due to the language in 1.4.2 stating that unless stated otherwise, “RA” refers to both Registration Authorities and Delegated Registration Authorities, can you direct me to where in the CP/CPS it calls out that DRAs, Certificate Managers, and Certificate Agents (as defined in Section 1.4.5) are specifically unable to perform the validation checks of 3.2.2.4 and 3.2.2.5? Additionally, what does it mean for an RA to “ensure that the request corresponds to the mandate of the DRA operator”?

-> In the CPS, the term RA is mainly used for the registration authority, which rely on the DRA for some of its operations, such as collecting or issuing information to the certificate manager. However, we have made the choice for the moment that the majority of the verifications are currently carried out by our internal RA, and not the DRAs however some controls such as face to face can be ensure to the DRA.

Paragraph 4.2.1 was added in particular to address this case where the face-to-face was in particular carried out by a DRA, however the other controls, in particular that concerning the control of the domain is well realized by the Certigna internal RA through technical means put in place by our services and not those of our DRAs. We can, if you wish, specify in our CP / CPS that these checks are carried out by the RA and not the DRA.

For clarification, the control of the DRA operator mandate is to verify that the person who sends a proof (eg attestation of face to face) is among the authorized persons of the DRA and that the signature (handwritten or electronic) of the document comes from this person.

----------------------------------------------------------------------------

CPS Section 4.2.1: If the request is valid and allows to obtain with accuracy the authorization to issue the certificate by a legal representative of the entity which is owner of the domain names, the CA authorizes itself to issue the certificate even if the CA is not present in the list of authorized CA.
This appears to directly contravene BR Section 3.2.2.8, which specifies the following 3 scenarios in which a CA can issue a certificate despite not appearing in the CAA record:
• CAA checking is optional for certificates for which a Certificate Transparency pre-certificate was created and logged in at least two public logs, and for which CAA was checked. Forum Guideline Baseline Requirements, v. 1.6.0 21

• CAA checking is optional for certificates issued by a Technically Constrained Subordinate CA Certificate as set out in Baseline Requirements section 7.1.5, where the lack of CAA checking is an explicit contractual provision in the contract with the Applicant.

• CAA checking is optional if the CA or an Affiliate of the CA is the DNS Operator (as defined in RFC 7719) of the domain's DNS.

-> Indeed, we were operating up to now a control with an alert and a notification to the applicant (pointing on this page https://www.certigna.fr/dns-caa.xhtml) to add us in the field CAA if that It is present, but it was not blocking for the request because we considered that having a signed authorization of the legal representative was sufficient even if the applicant not having updated the CAA registration.

Now, our control processes foresee that the certificate request is blocked notably in the following cases:
- The CAA DNS field is present, it contains an "issue" or "issuewild" tag and it does not list Certigna as an authorized CA.
- The CAA DNS field is present, designed as critical and the tag used is not supported by the CA (so if it is not an "issue" or "issuewild").

We will be releasing the CP / CPS update to clarify these practices being implemented now. If this is enough for you, we will immediately publish the documents.

----------------------------------------------------------------------------

CPS Section 3.2.7 calls out special actions taken for “High Risk Certification Requests”. It says the procedures for determining high risk as well as additional vetting requirements are documented, however, I do not see this documentation anywhere.
On what basis is a certification request deemed “high risk” and in what way, specifically, does this impact a subscriber’s ability to obtain a certificate?

-> For each certificate request, we automatically perform a check via the Google Safe Browsing API and we also think about using the base of the organization "phishing initiative". If a URL goes back at risk by these databases, the certificate request is automatically rejected and the applicant is notified by email.

We can specify these practices in more detail in our CPS if you wish, but we did not want to explain to much our procedures and the databases used because we felt that disclosing too much in detail our security practices to the public can help malicious people to adapt their request to try to circumvent our control devices.


----------------------------------------------------------------------------

Root CA CP Section 4.3.2: The delivery of certificate is achieved during the key ceremony, to a CA administrator authorized by CA and in charge of its exploitation and diffusion.

Can you please explain what these sentences mean? This sub-section is cited as the response to BR Section 4.3.1 CA Actions during Certificate Issuance in the latest version of the BR self-assessment, but does not appear to speak to this requirement.

-> Indeed, it is a problem of interpretation from us, we thought that it covered the delivery of the certificate of the root authority and not the issue of the end-entities certificates. The answer is available in the following chapter:
"4.3.1. Actions of the CA concerning the delivery of the certificate
After validation by the RA, the CA initiates the certificate generation process for the Certificate Manager.
4.3.2. Notification by the CA of the certificate to the certificate manager
Complete and accurate certificate is made available to the Certificate Manager (on the customer area). The Certificate Manager authenticates to the customer area to accept the certificate or complete a paper form. "
The document "BR assessment" has been updated to take into account all the evolutions mentioned above as well as this one. Do you want additional information on this point ?

----------------------------------------------------------------------------

As mentioned above, the publication of the updated CP / CPS will be immediate, as soon as you confirm that the level of detail is sufficient for you.

Thank you in advance for your help and your reply.

[josselin....@gmail.com]

Just in addition, because the point was raised to us, we also take into account the problem related to DNSSEC with the case where the zone is validly DNSSEC-signed and our CAA query times out.

[Wayne Thayer]

This response implies that Certigna has misissued certificates that failed
CAA validation. I have opened a bug [1] asking Certigna to identify and
remediate these certificates, and to file an incident report.

>

> Now, our control processes foresee that the certificate request is blocked
> notably in the following cases:
> - The CAA DNS field is present, it contains an "issue" or "issuewild" tag
> and it does not list Certigna as an authorized CA.
> - The CAA DNS field is present, designed as critical and the tag used is
> not supported by the CA (so if it is not an "issue" or "issuewild").
>
> We will be releasing the CP / CPS update to clarify these practices being
> implemented now. If this is enough for you, we will immediately publish the
> documents.
>

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1485413

[josselin....@gmail.com]

We confirm that no, this is not the case. This is what we said in the CP / CPS because we thought that these constraints could be regularly encountered and that it could be bad for the business, but as I said in our answer, the controls to report the blocking cases were positioned since the beginning of the application of the requirements about CAA records, but we have failed to update the documents.

Requests are processed not only automatically but also involving human validation by our Registration Authority and in particular, our Registration Officiers are systematically warned in case of alert on a CAA record. We confirm to you, despite what has not been updated in the CP / CPS that we block request well in accordance with the requirements expressed.

We wanted to wait for your feedback on the other points before updating our CP / CPS, but we can update them before the end of the week if necessary.

We hope that it meets yours expectation and remain at your disposal for further information.

Best regards

[josselin....@gmail.com]

And just to clarify, when we specified this in the CP / CPS, we thought that the document signed by a legal representative at the time of the certificate request could be sufficient in terms of consent, and that despite our requests, the applicant have not wished to update their CAA registration in addition to providing the document. So that's what was specified in the CP / CPS but we still set up the controls and monitor these points since to block the applications concerned. We only failed to regularize the point in the CP / CPS.

[Wayne Thayer]

Thank you for your response.

On Wed, Aug 22, 2018 at 11:51 AM josselin.allemandou--- via
dev-security-policy <dev-secur...@lists.mozilla.org> wrote:

> We confirm that no, this is not the case. This is what we said in the CP /
> CPS because we thought that these constraints could be regularly
> encountered and that it could be bad for the business, but as I said in our
> answer, the controls to report the blocking cases were positioned since the
> beginning of the application of the requirements about CAA records, but we
> have failed to update the documents.
>
> >

You are stating that your system has, since 8-September 2017, checked CAA
records in compliance with the BRs, and whenever a CAA record indicated
that you did not have permission to issue the certificate, the system
alerted your RA Officers who then rejected the request. Is this correct?

>

> Requests are processed not only automatically but also involving human
> validation by our Registration Authority and in particular, our
> Registration Officiers are systematically warned in case of alert on a CAA
> record. We confirm to you, despite what has not been updated in the CP /
> CPS that we block request well in accordance with the requirements
> expressed.
>
> >

What evidence do you have that all requests that failed CAA validation were
indeed denied? How many requests failed the CAA check and then were
manually rejected by an RA Officer?

>

> We wanted to wait for your feedback on the other points before updating
> our CP / CPS, but we can update them before the end of the week if
> necessary.
>
> >

I would recommend that you go ahead and make the CPS changes that you have
proposed rather than waiting for Devon's reply, but do not rush to complete
them this week.

[asymm...@chromium.org]

On Wednesday, August 22, 2018 at 2:10:06 AM UTC-7, josselin....@gmail.com wrote:
> Thank you very much Devon for this analysis and the time past on our request.
>
> You will find below additional information. Sorry for the delay, I was on vacation. The publication of the updated CP / CPS will be immediate, as soon as you confirm that the level of detail is sufficient for you.
>
> Thank you in advance for your help and your reply.
>
> ----------------------------------------------------------------------------
>
> CPS Section 1.4.2 states "Unless stated otherwise, in this document, “RA” covers the Registration Authority and Delegate Registration Authorities."
> CPS Section 3.2 calls out DRAs ability to perform initial identity validation steps and uses the phrasing “RA (RA or DRA)” at the beginning of the section.
> CPS Section 4.2.1 states that during the identification and request validation process, that a DRA forwards the steps undertaken (including validation of domain control), and the RA "ensures that the request corresponds to the mandate of the DRA operator"
> Due to the language in 1.4.2 stating that unless stated otherwise, “RA” refers to both Registration Authorities and Delegated Registration Authorities, can you direct me to where in the CP/CPS it calls out that DRAs, Certificate Managers, and Certificate Agents (as defined in Section 1.4.5) are specifically unable to perform the validation checks of 3.2.2.4 and 3.2.2.5? Additionally, what does it mean for an RA to “ensure that the request corresponds to the mandate of the DRA operator”?
>
> -> In the CPS, the term RA is mainly used for the registration authority, which rely on the DRA for some of its operations, such as collecting or issuing information to the certificate manager. However, we have made the choice for the moment that the majority of the verifications are currently carried out by our internal RA, and not the DRAs however some controls such as face to face can be ensure to the DRA.
>
> Paragraph 4.2.1 was added in particular to address this case where the face-to-face was in particular carried out by a DRA, however the other controls, in particular that concerning the control of the domain is well realized by the Certigna internal RA through technical means put in place by our services and not those of our DRAs. We can, if you wish, specify in our CP / CPS that these checks are carried out by the RA and not the DRA.

This would be a very good change, and it would address my concern.

>
> For clarification, the control of the DRA operator mandate is to verify that the person who sends a proof (eg attestation of face to face) is among the authorized persons of the DRA and that the signature (handwritten or electronic) of the document comes from this person.
>
> ----------------------------------------------------------------------------
> CPS Section 4.2.1: If the request is valid and allows to obtain with accuracy the authorization to issue the certificate by a legal representative of the entity which is owner of the domain names, the CA authorizes itself to issue the certificate even if the CA is not present in the list of authorized CA.
> This appears to directly contravene BR Section 3.2.2.8, which specifies the following 3 scenarios in which a CA can issue a certificate despite not appearing in the CAA record:
> • CAA checking is optional for certificates for which a Certificate Transparency pre-certificate was created and logged in at least two public logs, and for which CAA was checked. Forum Guideline Baseline Requirements, v. 1.6.0 21
>
> • CAA checking is optional for certificates issued by a Technically Constrained Subordinate CA Certificate as set out in Baseline Requirements section 7.1.5, where the lack of CAA checking is an explicit contractual provision in the contract with the Applicant.
>
> • CAA checking is optional if the CA or an Affiliate of the CA is the DNS Operator (as defined in RFC 7719) of the domain's DNS.
>
> -> Indeed, we were operating up to now a control with an alert and a notification to the applicant (pointing on this page https://www.certigna.fr/dns-caa.xhtml) to add us in the field CAA if that It is present, but it was not blocking for the request because we considered that having a signed authorization of the legal representative was sufficient even if the applicant not having updated the CAA registration.
>
> Now, our control processes foresee that the certificate request is blocked notably in the following cases:
> - The CAA DNS field is present, it contains an "issue" or "issuewild" tag and it does not list Certigna as an authorized CA.
> - The CAA DNS field is present, designed as critical and the tag used is not supported by the CA (so if it is not an "issue" or "issuewild").
>
> We will be releasing the CP / CPS update to clarify these practices being implemented now. If this is enough for you, we will immediately publish the documents.

I support these updates. Modulo addressing Wayne's concerns about past CAA practices, I'm comfortable with this language.

>
> ----------------------------------------------------------------------------
> CPS Section 3.2.7 calls out special actions taken for “High Risk Certification Requests”. It says the procedures for determining high risk as well as additional vetting requirements are documented, however, I do not see this documentation anywhere.
> On what basis is a certification request deemed “high risk” and in what way, specifically, does this impact a subscriber’s ability to obtain a certificate?
>
> -> For each certificate request, we automatically perform a check via the Google Safe Browsing API and we also think about using the base of the organization "phishing initiative". If a URL goes back at risk by these databases, the certificate request is automatically rejected and the applicant is notified by email.
>
> We can specify these practices in more detail in our CPS if you wish, but we did not want to explain to much our procedures and the databases used because we felt that disclosing too much in detail our security practices to the public can help malicious people to adapt their request to try to circumvent our control devices.

I don't think that will be necessary at this point; I just felt it would be beneficial to the public review of the application to define what actions are taken based on this risk assessment.

>
>
> ----------------------------------------------------------------------------
> Root CA CP Section 4.3.2: The delivery of certificate is achieved during the key ceremony, to a CA administrator authorized by CA and in charge of its exploitation and diffusion.
>
> Can you please explain what these sentences mean? This sub-section is cited as the response to BR Section 4.3.1 CA Actions during Certificate Issuance in the latest version of the BR self-assessment, but does not appear to speak to this requirement.
>
> -> Indeed, it is a problem of interpretation from us, we thought that it covered the delivery of the certificate of the root authority and not the issue of the end-entities certificates. The answer is available in the following chapter:
> "4.3.1. Actions of the CA concerning the delivery of the certificate
> After validation by the RA, the CA initiates the certificate generation process for the Certificate Manager.
> 4.3.2. Notification by the CA of the certificate to the certificate manager
> Complete and accurate certificate is made available to the Certificate Manager (on the customer area). The Certificate Manager authenticates to the customer area to accept the certificate or complete a paper form. "
> The document "BR assessment" has been updated to take into account all the evolutions mentioned above as well as this one. Do you want additional information on this point ?

My read here is that BR Section 4.3.1 stipulates a requirement on the issuance of certificates by the Root CA, while I feel the answer provided speaks to the issuance controls over leaf certificates from a subordinate CA, as I believe that under your terminology, a Certificate Manager is not involved in the issuance of CAs from a Root.

I definitely appreciate the information about the issuance process for the leafs, but I believe the reason this section is included in the Self-assessment is to speak to controls around certificate issuance from the Root CA.

[josselin....@gmail.com]

Hello,

Thanks Wayne and Devon for your reply.

We took the time to respond because we wanted to verify through an audit that the SSL certificate requests processed since September 8th were in compliance with the CA/B Forum requirements for DNS CAA record checks.

In general, this has been the case, because we have only one case, where the request was authorized by a Registration Officer, despite the alert that had been raised on this subject.

We checked the logs of the controls carried out and re-rolled these controls on all the SSL certificates issued since September 8th and confirm that only this certificate was the object of a failure. We have created an incident as required (see URL: https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/mVD1QoGXBOQ) for this certificate which has not yet been deployed and used by the applicant. I confirm that we proceeded to the revocation of this certificate which is now included in our CRL with the following serial number: 476abeb2bc78d588ef4b8f27dbd25f6a (see http://crl.certigna.fr/servicesca.crl).

Note that this incident will not be able to happen again by means of our new practices that automatically block and without possible bypass by the RA, any certificate request for which the DNS CAA record controls induce that the CA is not allowed to issue. These practices are described in the latest updated versions of our CP/CPS.

We have updated our CPs and CPSs to address the different points reported by Devon:
- We clarified the roles and controls performed by the RA and the DRAs;
- We updated the practices implemented for the control of DNS CAA records;
- We have specified the conditions of generation and signature of certificates by the root CA. As a reminder, these certificates are exclusively reserved for the intermediary authorities of our organization and are handled through Key Ceremonies involving several trusted roles knowing that our root CAs are Offline, and are not intended for customers request.

Could you tell us if you would like additional information and if these provided to CP/CPS are sufficient for you?

Thanking you in advance for your help and your reply.

Best regards

[Wayne Thayer]

On Tue, Sep 11, 2018 at 12:37 AM josselin.allemandou--- via
dev-security-policy <dev-secur...@lists.mozilla.org> wrote:

> Hello,
>
> Thanks Wayne and Devon for your reply.
>
> We took the time to respond because we wanted to verify through an audit
> that the SSL certificate requests processed since September 8th were in
> compliance with the CA/B Forum requirements for DNS CAA record checks.
>
> >

Excellent!

>

> In general, this has been the case, because we have only one case, where
> the request was authorized by a Registration Officer, despite the alert
> that had been raised on this subject.
>
> We checked the logs of the controls carried out and re-rolled these
> controls on all the SSL certificates issued since September 8th and confirm
> that only this certificate was the object of a failure. We have created an
> incident as required (see URL:
> https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/mVD1QoGXBOQ)
> for this certificate which has not yet been deployed and used by the
> applicant. I confirm that we proceeded to the revocation of this
> certificate which is now included in our CRL with the following serial
> number: 476abeb2bc78d588ef4b8f27dbd25f6a (see
> http://crl.certigna.fr/servicesca.crl).
>
> Note that this incident will not be able to happen again by means of our
> new practices that automatically block and without possible bypass by the
> RA, any certificate request for which the DNS CAA record controls induce
> that the CA is not allowed to issue. These practices are described in the
> latest updated versions of our CP/CPS.
>
> >

I will respond to this in the separate thread for the incident report.

>

> We have updated our CPs and CPSs to address the different points reported
> by Devon:
> - We clarified the roles and controls performed by the RA and the
> DRAs;
> - We updated the practices implemented for the control of DNS CAA
> records;
> - We have specified the conditions of generation and signature of
> certificates by the root CA. As a reminder, these certificates are
> exclusively reserved for the intermediary authorities of our organization
> and are handled through Key Ceremonies involving several trusted roles
> knowing that our root CAs are Offline, and are not intended for customers
> request.
>
> Could you tell us if you would like additional information and if these
> provided to CP/CPS are sufficient for you?
>
> >

Devon confirmed to me that he is satisfied with these updates.

[Wayne Thayer]

I believe that the discussion over Certigna's reported CAA misissuance
[1][2] has reached an end, even though some questions remain unanswered. If
anyone has additional comments or concerns about this inclusion request,
please respond by Friday 26-October. This request [3] has been in
discussion since April 2017 and I would like to bring it to a conclusion
soon.

- Wayne

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/mVD1QoGXBOQ/EkYklywRBAAJ
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1485413
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1265683

[David E. Ross]

On 10/23/2018 11:45 AM, Wayne Thayer wrote:
> I believe that the discussion over Certigna's reported CAA misissuance
> [1][2] has reached an end, even though some questions remain unanswered. If
> anyone has additional comments or concerns about this inclusion request,
> please respond by Friday 26-October. This request [3] has been in
> discussion since April 2017 and I would like to bring it to a conclusion
> soon.
>
> - Wayne
>
> [1]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/mVD1QoGXBOQ/EkYklywRBAAJ
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1485413
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1265683
>

If there remain unresolved issues, should not approval be withheld?

--
David E. Ross
<http://www.rossde.com>

Too often, Twitter is a source of verbal vomit. Examples include Donald
Trump, Roseanne Barr, and Elon Musk.

[Wayne Thayer]

On Tue, Oct 23, 2018 at 1:46 PM David E. Ross via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 10/23/2018 11:45 AM, Wayne Thayer wrote:

> > I believe that the discussion over Certigna's reported CAA misissuance
> > [1][2] has reached an end, even though some questions remain unanswered.
> If
> > anyone has additional comments or concerns about this inclusion request,
> > please respond by Friday 26-October. This request [3] has been in
> > discussion since April 2017 and I would like to bring it to a conclusion
> > soon.
> >
> > - Wayne
> >
> > [1]
> >
> https://groups.google.com/d/msg/mozilla.dev.security.policy/mVD1QoGXBOQ/EkYklywRBAAJ
> > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1485413
> > [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1265683
> >
>

> If there remain unresolved issues, should not approval be withheld?
>

> Certigna has completed their remediation, but a large number of questions
were asked during the discussion of the misissuance. I think it is fair to
say that Certigna was unwilling or unable to answer many of them, and when
this became apparent, I asked for the questioning to stop. Therefore, I
consider the issue to be resolved, but not necessarily resolved to our
satisfaction.

[David E. Ross]

If Mozilla is not satisfied with how the misissuance was resolved, why
would the root be included in Mozilla's NSS?

[Wayne Thayer]

On Wed, Oct 24, 2018 at 3:02 PM David E. Ross via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 10/24/2018 1:07 PM, Wayne Thayer wrote:

> If Mozilla is not satisfied with how the misissuance was resolved, why
> would the root be included in Mozilla's NSS?
>

> It's fairly common for a CA to fail to meet our expectations for root
cause analysis, and I suspect that we would tolerate this one if it had
been discovered, say, a year ago rather than during the inclusion
discussion. I'm not arguing for ignoring it, but when I consider the
entirety of the evidence presented, it's not obvious to me that this should
be rejected either. That's part of the reason why I asked for additional
comments.

[Wayne Thayer]

Having received no further comments, I am recommending approval of
Certigna's inclusion request.

I would first like to thank Certigna for their patience as this request
spent a long time waiting on Mozilla.

The disregard for CAB Forum requirements shown by Certigna's CAA exception
process is a very serious issue, as is the incomplete response we received
from Certigna. If not for the fact that few other issues were identified,
and that the CAA requirement is relatively new and apparently not well
understood, I may not have recommended approval. Certigna should be aware
that any future policy violations will be judged more severely than they
might seem given the existence of this CAA misissuance.

- Wayne

On Wed, Oct 24, 2018 at 4:56 PM Wayne Thayer <wth...@mozilla.com> wrote:

> On Wed, Oct 24, 2018 at 3:02 PM David E. Ross via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> On 10/24/2018 1:07 PM, Wayne Thayer wrote: