<a class="header-button" href="https://bugzilla.mozilla.org/home" title="Go to home page"> Bugzilla

Assignee

Updated

•

4 years ago

Flags: needinfo?(bwilson)

Reporter

Comment 10

•

4 years ago

DigitalSign is pleased to inform that has concluded, in 2021-05-03, a complete audit (within ninety days of issuing the first Publicly-Trusted Certificate), according to 8.1 of the CA/Browser Forum Baseline Requirements.

The attestation letter can be consulted at: https://www.csqa.it/getattachment/Sicurezza-ICT/Documenti/Attestazione-di-Audit-secondo-i-requisiti-ETSI/2021-04-21-CSQA-Attestation-DigitalSign-2021-8012-signed.pdf.aspx?lang=it-IT

Assignee

Comment 11

•

4 years ago

The date on the audit letter is wrong.

It should NOT have a "th" on May 12.

Also, it says 2020 - it should say 2021.

Assignee

Comment 12

•

4 years ago

Also, this needs to be a period-of-time audit with a beginning and end of covering more than 60 days. It appears to be still a point-in-time audit, and not a period-of-time audit.

Flags: needinfo?(bwilson)

Assignee

Comment 13

•

4 years ago

Section 3.2.2 of the CPS says, "DigitalSign verifies an organization’s right to use or control an email address to be contained in a certificate by sending an email message containing Random Information to the email address to be used in the certificate. This Random Information is required to complete the certificate issuance process."
Section 3.2.3 of the CPS says, DigitalSign verifies an individual’s right to use or control an email address to be contained in a certificate by sending an email message containing Random Information to the email address to be used in the certificate. This Random Information is required to complete the certificate issuance process."
It is unclear whether DigitalSign uses any methods from section 3.2.2.4 of the CA/Browser Forum's Baseline Requirements to verify just the organization's control over the domain portion of the email address (for enterprise-based issuance). See e.g. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#22-validation-practices

Reporter

Comment 14

•

4 years ago

(In reply to Ben Wilson from comment #13)

Section 3.2.2 of the CPS says, "DigitalSign verifies an organization’s right to use or control an email address to be contained in a certificate by sending an email message containing Random Information to the email address to be used in the certificate. This Random Information is required to complete the certificate issuance process."
Section 3.2.3 of the CPS says, DigitalSign verifies an individual’s right to use or control an email address to be contained in a certificate by sending an email message containing Random Information to the email address to be used in the certificate. This Random Information is required to complete the certificate issuance process."
It is unclear whether DigitalSign uses any methods from section 3.2.2.4 of the CA/Browser Forum's Baseline Requirements to verify just the organization's control over the domain portion of the email address (for enterprise-based issuance). See e.g. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#22-validation-practices

Dear Ben,
DigitalSign clarifies that the issued certificates under current CP/CPS are requested by the subscriber (natural or legal persons), and all included information in the DN is validated by DigitalSign, including the right to use or control an email address to be contained in a certificate, by the means described on CPS sections 3.2.2 and 3.2.3.
Enterprise-based issuance is not supported, i.e., DigitalSign does not allow an organization to issue/request certificates on behalf of the subscriber/end-user.
SSL certificates or device certificates are not issued under current CP/CPS, so domain name / FQDN validation also does not apply.
Best Regards,

Reporter

Comment 15

•

3 years ago

(In reply to Ben Wilson from comment #11)

The date on the audit letter is wrong.

It should NOT have a "th" on May 12.

Also, it says 2020 - it should say 2021.

Dear Ben,
DigitalSign has sucessfuly updated the Standard Audit Statement link at CCADB, and the current Status is now showing "PASS".
Please find ou latest audit attestation letter here: https://www.csqa.it/getattachment/Sicurezza-ICT/Documenti/Attestazione-di-Audit-secondo-i-requisiti-ETSI/Certificadora-Digital-S-A-Attestation-DigitalSign-2021-8012-Rev-02-signed.pdf.aspx?lang=it-IT

Assignee

Updated

•

3 years ago

Whiteboard: [ca-verifying] → [ca-cps-review] BW 2021-06-21

Assignee

Comment 16

•

3 years ago

According to sections 3.2.2 and 3.2.3 of the DigitalSign CPS (https://pki.digitalsign.pt/ROOT%20CA%20-%20CPS_V1.4.pdf), "DigitalSign verifies an organization’s right to use or control an email address to be contained in a certificate by sending an email message containing Random Information to the email address to be used in the certificate. This Random Information is required to complete the certificate issuance process."
I'll now take a look at the other parts of the CPS to ensure conformity with Mozilla requirements.

Assignee

Comment 17

•

3 years ago

Page 2 says, “It is strictly prohibited the reproduction, total or partial, of the contents of this document without prior written permission issued by DigitalSign.” However, Mozilla Policy requires that CP/CPS documents submitted to us must be available on a Creative Commons basis. See https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#3-documentation - Should be fixed

Compliance with RFC 3647 – Good

Sections 1.1 (Overview), 6.5, and 6.7 should also list the CA/Browser Forum’s Network and Certificate System Security Requirements as an applicable standard, which DigitalSign implements – Should fix

Section 1.1.1.2 of the CPS says, “DigitalSign does not use Intermediate Certification Authorities.” (Section 1.1.1.3 discusses Issuing CAs, which DigitalSign does use.) The use of the term “Intermediate Certification Authorities” by DigitalSign is different from that use by a majority of CA operators, browsers/root stores, and others and may lead to confusion. – Section 1.1.1.2 should be fixed to remove/delete the statement “DigitalSign does not use Intermediate Certification Authorities”.

Section 1.4.1 – Given that section 1.1.1.3 says that Issuing CAs can be issued directly by the Root CAs, then the second bullet should be fixed to include “Issuing CAs” – “Certificates for Intermediate CAs / Issuing CAs and cross-certificates;” – Should fix

Section 1.5.2 should say that in the event that a private key has been compromised, that anyone can make a revocation request to DigitalSign at suporte@digitalsign.pt. – Should fix (Could also reference provisions in sections 4.9.2, 4.9.3, and 4.9.12, mentioned below.)

Section 2.2 – DigitalSign should state that its CPS is available over https, not http – (i.e. https://pki.digitalsign.pt/) – Should fix

Section 3.2.4 – “All the information included in the DN is checked and authenticated by the validation services.” – Good

Section 4.9.1 - Please compare your revocation reasons and make sure your CPS complies with Mozilla's revocation requirements for SMIME certificates set forth here: https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#62-smime – Please review

Section 4.9.2 – A Certificate revocation can be requested by: a third party that presents proof that the private key has been compromised – Should fix

Sections 4.9.3 and 4.9.12 – It appears that DigitalSign offers a method by a third party to prove key compromise by digitally signing a CSR as a request to revoke the certificate using the private key – Should consider referencing section 4.9.12 in section 4.93

Sections 4.9.12 and 5.7.3 – “DigitalSign will use all commercially reasonable efforts to notify potential relying parties, if it discovers, or have reason to believe that the private key of its own CA is compromised.” And “If it is necessary the revocation of the CA certificate, it is set the following procedure: • It is communicated to the relying parties the revocation status of the certificate through the repository, according to this CPS. • There will be made commercially reasonable efforts to provide additional notification about the revocation to all affected DigitalSign Certification Hierarchy participants.” As a root store operator, Mozilla should be similarly notified. These two sections could state that DigitalSign will also notify all root store operators that have accepted DigitalSign certificate hierarchies in their root stores as trust anchors, or some language to that effect. DigitalSign should also make sure that the mechanisms to contact root stores are listed in the security policy or in disaster recovery plans – Should fix

Section 5.8 - In the event it is necessary to cease operations of the CA or any of the RAs, DigitalSign shall make commercially reasonable effort to notify in advance the end-users, relying parties and other entities affected by such termination**, such as root stores that have included DigitalSign’s certificates in their root stores**. – Should fix

Section 10 – Appendix A Acronyms - Section 6.4.1 contains the acronym “PUK”, which is not listed in the list of acronyms in Appendix A. - Should fix

Assignee

Updated

•

3 years ago

Whiteboard: [ca-cps-review] BW 2021-06-21 → [ca-cps-review] BW 2022-04-18 Comment 17

Reporter

Comment 18

•

3 years ago

(In reply to Ben Wilson from comment #17)

Page 2 says, “It is strictly prohibited the reproduction, total or partial, of the contents of this document without prior written permission issued by DigitalSign.” However, Mozilla Policy requires that CP/CPS documents submitted to us must be available on a Creative Commons basis. See https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#3-documentation - Should be fixed

Compliance with RFC 3647 – Good

Sections 1.1 (Overview), 6.5, and 6.7 should also list the CA/Browser Forum’s Network and Certificate System Security Requirements as an applicable standard, which DigitalSign implements – Should fix

Section 1.1.1.2 of the CPS says, “DigitalSign does not use Intermediate Certification Authorities.” (Section 1.1.1.3 discusses Issuing CAs, which DigitalSign does use.) The use of the term “Intermediate Certification Authorities” by DigitalSign is different from that use by a majority of CA operators, browsers/root stores, and others and may lead to confusion. – Section 1.1.1.2 should be fixed to remove/delete the statement “DigitalSign does not use Intermediate Certification Authorities”.

Section 1.4.1 – Given that section 1.1.1.3 says that Issuing CAs can be issued directly by the Root CAs, then the second bullet should be fixed to include “Issuing CAs” – “Certificates for Intermediate CAs / Issuing CAs and cross-certificates;” – Should fix

Section 1.5.2 should say that in the event that a private key has been compromised, that anyone can make a revocation request to DigitalSign at suporte@digitalsign.pt. – Should fix (Could also reference provisions in sections 4.9.2, 4.9.3, and 4.9.12, mentioned below.)

Section 2.2 – DigitalSign should state that its CPS is available over https, not http – (i.e. https://pki.digitalsign.pt/) – Should fix

Section 3.2.4 – “All the information included in the DN is checked and authenticated by the validation services.” – Good

Section 4.9.1 - Please compare your revocation reasons and make sure your CPS complies with Mozilla's revocation requirements for SMIME certificates set forth here: https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#62-smime – Please review

Section 4.9.2 – A Certificate revocation can be requested by: a third party that presents proof that the private key has been compromised – Should fix

Sections 4.9.3 and 4.9.12 – It appears that DigitalSign offers a method by a third party to prove key compromise by digitally signing a CSR as a request to revoke the certificate using the private key – Should consider referencing section 4.9.12 in section 4.93

Sections 4.9.12 and 5.7.3 – “DigitalSign will use all commercially reasonable efforts to notify potential relying parties, if it discovers, or have reason to believe that the private key of its own CA is compromised.” And “If it is necessary the revocation of the CA certificate, it is set the following procedure: • It is communicated to the relying parties the revocation status of the certificate through the repository, according to this CPS. • There will be made commercially reasonable efforts to provide additional notification about the revocation to all affected DigitalSign Certification Hierarchy participants.” As a root store operator, Mozilla should be similarly notified. These two sections could state that DigitalSign will also notify all root store operators that have accepted DigitalSign certificate hierarchies in their root stores as trust anchors, or some language to that effect. DigitalSign should also make sure that the mechanisms to contact root stores are listed in the security policy or in disaster recovery plans – Should fix

Section 5.8 - In the event it is necessary to cease operations of the CA or any of the RAs, DigitalSign shall make commercially reasonable effort to notify in advance the end-users, relying parties and other entities affected by such termination**, such as root stores that have included DigitalSign’s certificates in their root stores**. – Should fix

Section 10 – Appendix A Acronyms - Section 6.4.1 contains the acronym “PUK”, which is not listed in the list of acronyms in Appendix A. - Should fix

Hello dear Ben Wilson. Here are the changes we've made according to your observations:

Page 2 says, “It is strictly prohibited the reproduction, total or partial, of the contents of this document without prior written permission issued by DigitalSign.” However, Mozilla Policy requires that CP/CPS documents submitted to us must be available on a Creative Commons basis. See https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#3-documentation - Should be fixed
[DigitalSign] Limitations removed

Compliance with RFC 3647 – Good
[DigitalSign] OK

Sections 1.1 (Overview), 6.5, and 6.7 should also list the CA/Browser Forum’s Network and Certificate System Security Requirements as an applicable standard, which DigitalSign implements – Should fix
[DigitalSign] CA/Browser Forum, Network and Certificate System Security Requirements referred in sections 1.1, 6.5 and 6.7.

Section 1.1.1.2 of the CPS says, “DigitalSign does not use Intermediate Certification Authorities.” (Section 1.1.1.3 discusses Issuing CAs, which DigitalSign does use.) The use of the term “Intermediate Certification Authorities” by DigitalSign is different from that use by a majority of CA operators, browsers/root stores, and others and may lead to confusion. – Section 1.1.1.2 should be fixed to remove/delete the statement “DigitalSign does not use Intermediate Certification Authorities”.
[DigitalSign] We intend to differentiate ‘issuing CAs’ (that issue end-user certificates) from ‘Intermediate CAs’ (that issue subsequent level CAs) – Nevertheless, we’ve removed the referred statement.

Section 1.4.1 – Given that section 1.1.1.3 says that Issuing CAs can be issued directly by the Root CAs, then the second bullet should be fixed to include “Issuing CAs” – “Certificates for Intermediate CAs / Issuing CAs and cross-certificates;” – Should fix
[DigitalSign] Fixed.

Section 1.5.2 should say that in the event that a private key has been compromised, that anyone can make a revocation request to DigitalSign at suporte@digitalsign.pt. – Should fix (Could also reference provisions in sections 4.9.2, 4.9.3, and 4.9.12, mentioned below.)
[DigitalSign] Additional information has been added to this section.

Section 2.2 – DigitalSign should state that its CPS is available over https, not http – (i.e. https://pki.digitalsign.pt/) – Should fix
[DigitalSign] Fixed. Also fixed in section 1.2.

Section 3.2.4 – “All the information included in the DN is checked and authenticated by the validation services.” – Good
[DigitalSign] OK

Section 4.9.1 - Please compare your revocation reasons and make sure your CPS complies with Mozilla's revocation requirements for SMIME certificates set forth here: https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#62-smime – Please review
[DigitalSign] Included all Mozilla’s revocation requirements and also additional requirements.

Section 4.9.2 – A Certificate revocation can be requested by: a third party that presents proof that the private key has been compromised – Should fix
[DigitalSign] Fixed.

Sections 4.9.3 and 4.9.12 – It appears that DigitalSign offers a method by a third party to prove key compromise by digitally signing a CSR as a request to revoke the certificate using the private key – Should consider referencing section 4.9.12 in section 4.93
[DigitalSign] Reference to section 4.9.12 in section 4.9.3 added.

Sections 4.9.12 and 5.7.3 – “DigitalSign will use all commercially reasonable efforts to notify potential relying parties, if it discovers, or have reason to believe that the private key of its own CA is compromised.” And “If it is necessary the revocation of the CA certificate, it is set the following procedure: • It is communicated to the relying parties the revocation status of the certificate through the repository, according to this CPS. • There will be made commercially reasonable efforts to provide additional notification about the revocation to all affected DigitalSign Certification Hierarchy participants.” As a root store operator, Mozilla should be similarly notified. These two sections could state that DigitalSign will also notify all root store operators that have accepted DigitalSign certificate hierarchies in their root stores as trust anchors, or some language to that effect. DigitalSign should also make sure that the mechanisms to contact root stores are listed in the security policy or in disaster recovery plans – Should fix
[DigitalSign] Information added to sections 4.9.12 and 5.7.3. Also included the additional procedure in our Business Continuity Plan and Cessation of Activity Plan.

Section 5.8 - In the event it is necessary to cease operations of the CA or any of the RAs, DigitalSign shall make commercially reasonable effort to notify in advance the end-users, relying parties and other entities affected by such termination**, such as root stores that have included DigitalSign’s certificates in their root stores**. – Should fix
[DigitalSign] Fixed.

Section 10 – Appendix A Acronyms - Section 6.4.1 contains the acronym “PUK”, which is not listed in the list of acronyms in Appendix A. - Should fix
[DigitalSign] Fixed.

[DigitalSign] Some additional minor fixes were applied:
• Section 5.5.2: retention period to 7 years, as per law alteration;
• Section 6.2.1: include requirement related to monitorization of QSCD certification status;
• Section 10: added some missing acronyms.

New CPS version attached to this bug.

Reporter

Comment 19

•

3 years ago

Attached file CPS_V1.5_EN_ORG.pdf — Details

Assignee

Comment 20

•

3 years ago

Thanks. I will move this into the queue for public discussion.

Whiteboard: [ca-cps-review] BW 2022-04-18 Comment 17 → [ca-ready-for-discussion 2022-05-06]

Reporter

Comment 21

•

3 years ago

The attached pdf is merely a draft version of our cps with the required modifications. Our updated CPS (V1.5) is currently awainting internal approve. Once the CPS is published, it will also be announced here and the official url will be posted here and updated at CCADB.

Assignee

Comment 22

•

3 years ago

I've reviewed version 1.5 of the CPS, and it appears that the requested changes have been made. I am now asking that DigitalSign submit a Value Justification - see https://wiki.mozilla.org/CA/Quantifying_Value.

Reporter

Comment 23

•

2 years ago

(In reply to Ben Wilson from comment #22)

I've reviewed version 1.5 of the CPS, and it appears that the requested changes have been made. I am now asking that DigitalSign submit a Value Justification - see https://wiki.mozilla.org/CA/Quantifying_Value.

Hello dear Ben,
I've attached our Value Justification to this thread.

Reporter

Comment 24

•

2 years ago

Attached file Quantifying Value - DigitalSign.pdf — Details

Assignee

Updated

•

2 years ago

Whiteboard: [ca-ready-for-discussion 2022-05-06] → [ca-in-discussion] 2022-07-21

Assignee

Comment 25

•

2 years ago

Public discussion started with an anticipated closing in 3 weeks on 12-Aug-2022. https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/Ajm_a5GKHCU/m/LO961rHVAAAJ

Assignee

Comment 26

•

2 years ago

Public discussion closed today without comment, and we started the 7-day period for any last-call objections. I am recommending that this request from DigitalSign be approved. https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/Ajm_a5GKHCU/m/FE-ffi9CAQAJ

Flags: needinfo?(kwilson)

Assignee

Updated

•

2 years ago

Priority: P3 → P1

Assignee

Comment 27

•

2 years ago

The 7-day last-call period has passed without objection or comment.

Whiteboard: [ca-in-discussion] 2022-07-21 → [ca-pending-approval] 2022-08-23

Comment 28

•

2 years ago

On behalf of Mozilla I approve this request from DigitalSign - Certificadora Digital, S.A. to include the following root certificates:

** DIGITALSIGN GLOBAL ROOT RSA CA (Email)
** DIGITALSIGN GLOBAL ROOT ECDSA CA (Email)

I will file the NSS bug for the approved changes.

Flags: needinfo?(kwilson)

Whiteboard: [ca-pending-approval] 2022-08-23 → [ca-approved] - pending NSS code changes

Updated

•

2 years ago

Depends on: 1787075

Comment 29

•

2 years ago

I have filed bug #1787075 against NSS for the actual changes.