MOVED mozilla.dev.security.policy to dev-security-policy

[Kathleen Wilson via dev-security-policy]

All,

This mozilla.dev.security.policy group has been moved to 
dev-security-policy in Mozilla’s Google Workspace (formerly GSuite).


New Access Points:
- Mailing List: dev-security-pol...@mozilla.org
   -- dev-security-policy@lists.mozilla.org will automatically forward 
to the new mailing list

- Group Name: dev-security-policy
- Web: https://groups.google.com/a/mozilla.org/g/dev-security-policy
Note: Newsgroup access is deprecated and will no longer be an access point.

This mozilla.dev.security.policy group is being archived and no more 
posts will be accepted in this old group. Google has stated that data in 
this old group and the URLs to messages within this old group will 
remain as-is. Messages sent to dev-security-policy@lists.mozilla.org 
will be automatically forwarded to dev-security-pol...@mozilla.org.


We pre-populated the new group’s members list with the active users who 
subscribed to mozilla.dev.security.policy via lists.mozilla.org. If you 
have already been added to the new group as a member, then you should 
have received a message from the group. You can update your user 
settings and frequency of email messages via groups.google.com, or send 
an email to me and Ben.


If you have not received a message from the new dev-security-policy 
group, you may request to subscribe to the group by sending an email to 
dev-security-policy+subscr...@mozilla.org or to me or Ben. This new 
group is also public-facing via the web interface, so you only need to 
join the group if you intend to post messages or if you want to receive 
group conversations via email.


Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: MOVING mozilla.dev.security.policy to dev-security-policy in Mozilla’s Google Workspace (formerly GSuite)

[Kathleen Wilson via dev-security-policy]

All,

I posted the first message to the new group, with subject "WELCOME to 
dev-security-policy".


If you do not receive the welcome message to the new group, you can 
subscribe to it by sending an email to 
dev-security-policy+subscr...@mozilla.org or to me or Ben.


You can update your user settings and frequency of email messages via 
groups.google.com, or you can send an email to me and Ben to request 
that we update your settings in this new group.


Thanks,
Kathleen


On 3/25/21 9:55 AM, Kathleen Wilson wrote:

All,

This mozilla.dev.security.policy mailing list has been running on 
ancient custom-patched mailman software since the early Mozilla days. As 
many of you are aware, there are limitations and sometimes loss of data 
with the old configuration, so we are migrating this list to be hosted 
as a well-supported email-based Google Group under Mozilla's Google 
Workspace (formerly GSuite) account.


Currently this forum is accessed as follows:
  - Mailing List: dev-security-policy@lists.mozilla.org
  - Newsgroup: mozilla.dev.security.policy
  - Web: https://groups.google.com/g/mozilla.dev.security.policy
This list will be archived and changed to read-only on April 3, after 
which we will continue our conversations in the new list.


After the move, the access points will change to:
  - Mailing List: dev-security-pol...@mozilla.org
   -- dev-security-policy@lists.mozilla.org will automatically forward 
to the new mailing list

  - Group Name: dev-security-policy
  - Web: https://groups.google.com/a/mozilla.org/g/dev-security-policy
Note: Newsgroup access is deprecated and will no longer be an access point.

In the next week we will pre-populate the new group’s members list with 
the active users who subscribed to mozilla.dev.security.policy via 
lists.mozilla.org, and you will begin to receive email from the new 
dev-security-policy group as soon as messages are posted to it. You will 
then be able to update your user settings and frequency of email 
messages via groups.google.com, or you can send an email to me and Ben 
to request that we update your settings in this new group.


For mozilla.dev.security.policy we do not have visibility into 
subscribers from NNTP or Google Groups, so if you do not receive 
notifications from the new group, you may subscribe by sending email to 
dev-security-policy+subscr...@mozilla.org or to me or Ben. This new 
group, dev-security-policy, is also public-facing via the web interface 
so you only need to subscribe to the new group if you intend to post 
messages or if you want to receive group conversations via email.


I will post another message here in mozilla.dev.security.policy when the 
new group is ready to use. At that point, we will archive this 
mozilla.dev.security.policy group such that no one will be able to post 
to this old group. Google has stated that data in this old group and the 
URLs to messages within this old group will remain as-is. From then on 
messages sent to dev-security-policy@lists.mozilla.org will be 
automatically forwarded to dev-security-pol...@mozilla.org.


Thanks,
Kathleen


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CCADB Update to Audit and Root Inclusion Cases March 25-29

[Kathleen Wilson via dev-security-policy]

All,

The CCADB update has been completed, and the "UNDER CONSTRUCTION" notice 
will be removed today.


There is still some cleanup that we will be doing, but you may proceed 
with using Audit Cases and Root Inclusion Cases now.


Please let me know if you run into any problems with the CCADB.

Thanks,
Kathleen


On 3/25/21 11:22 AM, Kathleen Wilson wrote:

All,

We will be applying updates to CCADB Audit Cases and Root Inclusion 
Cases starting tonight, March 25, and expected to be completed the 
afternoon of March 29.


We will post the following message on the CCADB home page while the 
updates are in progress.


--
UNDER CONSTRUCTION: Audit Cases and Root Inclusion Cases are being 
updated March 25 to March 29. Please avoid using them until this update 
had been completed. This message will be removed when the changes are done.

--

The goal of these updates is to extend Root Inclusion Cases to be usable 
by other root stores. After this update, both Apple and Mozilla will be 
able to use Root Inclusion Cases. There is a significant amount of code 
that is common to Audit Cases and Root Inclusion Cases, so Audit Cases 
will also be impacted during the update.


Please let me know if you have any questions about this, or run into 
other problems in the CCADB.


Thanks,
Kathleen



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

CCADB Update to Audit and Root Inclusion Cases March 25-29

[Kathleen Wilson via dev-security-policy]

All,

We will be applying updates to CCADB Audit Cases and Root Inclusion 
Cases starting tonight, March 25, and expected to be completed the 
afternoon of March 29.


We will post the following message on the CCADB home page while the 
updates are in progress.


--
UNDER CONSTRUCTION: Audit Cases and Root Inclusion Cases are being 
updated March 25 to March 29. Please avoid using them until this update 
had been completed. This message will be removed when the changes are done.

--

The goal of these updates is to extend Root Inclusion Cases to be usable 
by other root stores. After this update, both Apple and Mozilla will be 
able to use Root Inclusion Cases. There is a significant amount of code 
that is common to Audit Cases and Root Inclusion Cases, so Audit Cases 
will also be impacted during the update.


Please let me know if you have any questions about this, or run into 
other problems in the CCADB.


Thanks,
Kathleen

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

MOVING mozilla.dev.security.policy to dev-security-policy in Mozilla’s Google Workspace (formerly GSuite)

[Kathleen Wilson via dev-security-policy]

All,

This mozilla.dev.security.policy mailing list has been running on 
ancient custom-patched mailman software since the early Mozilla days. As 
many of you are aware, there are limitations and sometimes loss of data 
with the old configuration, so we are migrating this list to be hosted 
as a well-supported email-based Google Group under Mozilla's Google 
Workspace (formerly GSuite) account.


Currently this forum is accessed as follows:
  - Mailing List: dev-security-policy@lists.mozilla.org
  - Newsgroup: mozilla.dev.security.policy
  - Web: https://groups.google.com/g/mozilla.dev.security.policy
This list will be archived and changed to read-only on April 3, after 
which we will continue our conversations in the new list.


After the move, the access points will change to:
  - Mailing List: dev-security-pol...@mozilla.org
   -- dev-security-policy@lists.mozilla.org will automatically forward 
to the new mailing list

  - Group Name: dev-security-policy
  - Web: https://groups.google.com/a/mozilla.org/g/dev-security-policy
Note: Newsgroup access is deprecated and will no longer be an access point.

In the next week we will pre-populate the new group’s members list with 
the active users who subscribed to mozilla.dev.security.policy via 
lists.mozilla.org, and you will begin to receive email from the new 
dev-security-policy group as soon as messages are posted to it. You will 
then be able to update your user settings and frequency of email 
messages via groups.google.com, or you can send an email to me and Ben 
to request that we update your settings in this new group.


For mozilla.dev.security.policy we do not have visibility into 
subscribers from NNTP or Google Groups, so if you do not receive 
notifications from the new group, you may subscribe by sending email to 
dev-security-policy+subscr...@mozilla.org or to me or Ben. This new 
group, dev-security-policy, is also public-facing via the web interface 
so you only need to subscribe to the new group if you intend to post 
messages or if you want to receive group conversations via email.


I will post another message here in mozilla.dev.security.policy when the 
new group is ready to use. At that point, we will archive this 
mozilla.dev.security.policy group such that no one will be able to post 
to this old group. Google has stated that data in this old group and the 
URLs to messages within this old group will remain as-is. From then on 
messages sent to dev-security-policy@lists.mozilla.org will be 
automatically forwarded to dev-security-pol...@mozilla.org.


Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New intermediate certs and Audit Statements

[Kathleen Wilson via dev-security-policy]

On 3/24/21 5:32 AM, Rob Stradling wrote:

On 9th July 2019, Kathleen wrote:

I propose that to handle this situation, the CA may enter the

subordinate CA's current audit statements and use the Public Comment
field to indicate that the new certificate will be included in the next
audit statements.

Hi Kathleen.  CCADB now automatically shows the following message (when 
relevant) in red text at the top of each intermediate certificate page:

 "This certificate was created after the audit period of the current audit 
statement, so please make sure to include it in the CA's next periodic audit 
statement."

Do you still expect CAs to "use the Public Comment field to indicate that the new 
certificate will be included in the next audit statements"?
Or may we stop doing that now?

Thanks.



Rob, Thanks for bringing this up. I agree that it is not necessary to 
use the Public Comment field to indicate that the new certificate will 
be included in the next audit statements. CAs may stop doing that.


Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Audit Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of March 2021 Audit Reminder Emails
Date: Tue, 16 Mar 2021 19:02:12 + (GMT)

Mozilla: Audit Reminder
CA Owner: certSIGN
Root Certificates:
   certSIGN ROOT CA
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239757

Standard Audit Period End Date: 2020-02-07
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239758

BR Audit Period End Date: 2020-02-07
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Krajowa Izba Rozliczeniowa S.A. (KIR)
Root Certificates:
   SZAFIR ROOT CA2
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238854

Standard Audit Period End Date: 2019-12-18
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238855

BR Audit Period End Date: 2019-12-18
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Government of Hong Kong (SAR), Hongkong Post, Certizen
Root Certificates:
   Hongkong Post Root CA 3**
   Hongkong Post Root CA 1**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238797

Standard Audit Period End Date: 2019-12-31
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238798

BR Audit Period End Date: 2019-12-31
EV Audit: https://www.ecert.gov.hk/ev/Webtrust_EVSSL_2019.pdf
EV Audit Period End Date: 2019-11-30
CA Comments: null



Mozilla: Audit Reminder
CA Owner: QuoVadis
Root Certificates:
   QuoVadis Root CA 1 G3
   QuoVadis Root CA 2
   QuoVadis Root CA 2 G3
   QuoVadis Root CA 3
   QuoVadis Root CA 3 G3
   QuoVadis Root Certification Authority
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239021

Standard Audit Period End Date: 2019-12-31
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239022

BR Audit Period End Date: 2019-12-31
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239023

EV Audit Period End Date: 2019-12-31
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Government of Spain, Fábrica Nacional de Moneda y Timbre (FNMT)
Root Certificates:
   AC RAIZ FNMT-RCM SERVIDORES SEGUROS
   FNMT-RCM - SHA256
Standard Audit: 
https://www.aenor.com/Certificacion_Documentos/eiDas/2020%20AENOR%20Anexo%202%20ETSI%20319%20411-1%20PSC-2019-003%20-%20FNMT-v2.pdf

Standard Audit Period End Date: 2020-01-12
BR Audit: 
https://www.aenor.com/Certificacion_Documentos/eiDas/2020%20AENOR%20Anexo%201%20ETSI%20319%20411-2%20PSC-2019-003%20-%20FNMT-v2.pdf

BR Audit Period End Date: 2020-01-12
BR Audit: 
https://www.aenor.com/Certificacion_Documentos/eiDas/2020%20AENOR%20Anexo%202%20ETSI%20319%20411-1%20PSC-2019-003%20-%20FNMT-v2.pdf

BR Audit Period End Date: 2020-01-12
EV Audit: 
https://www.aenor.com/Certificacion_Documentos/eiDas/2020%20AENOR%20Anexo%201%20ETSI%20319%20411-2%20PSC-2019-003%20-%20FNMT-v2.pdf

EV Audit Period End Date: 2020-01-12
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Taiwan-CA Inc. (TWCA)
Root Certificates:
   TWCA Global Root CA**
   TWCA Root Certification Authority**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://www.cpacanada.ca/generichandlers/cpachandler.ashx?AttachmentID=238799

Standard Audit Period End Date: 2019-12-31
BR Audit: 
https://www.cpacanada.ca/generichandlers/cpachandler.ashx?AttachmentID=238800

BR Audit Period End Date: 2019-12-31
EV Audit: 
https://www.cpacanada.ca/generichandlers/cpachandler.ashx?AttachmentID=238801

EV Audit Period End Date: 2019-12-31
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Trustis
Root Certificates:
   Trustis Limited - Trustis FPS Root CA
Standard Audit: 
https://bug1360184.bmoattachments.org/attachment.cgi?id=9146189

Standard Audit Period End Date: 2020-01-15
BR Audit: https://bug1360184.bmoattachments.org/attachment.cgi?id=9146189
BR Audit Period End Date: 2020-01-15
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Asseco Data Systems S.A. (previously Unizeto Certum)
Root Certificates:
   Certum Trusted Network CA 2
   Certum CA
   Certum Trusted Network CA
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239794

Standard Audit Period End Date: 2020-02-10
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239795

BR Audit Period End Date: 2020-02-10
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239796

EV Audit Period End Date: 2020-02-10
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Government of The Netherlands, PKIoverheid (Logius)
Root Certificates:
   Staat der Nederlanden Root CA - G3
   Staat der Nederlanden EV Root CA
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmenti

Re: Audit Reminders for Intermediate Certs

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of March 2021 Outdated Audit Statements for 
Intermediate Certs

Date: Tue, 2 Mar 2021 15:00:24 + (GMT)


CA Owner: SECOM Trust Systems CO., LTD.
   - Certificate Name: JPRS Organization Validation Authority - G3
SHA-256 Fingerprint: 
21C066332D6B92DD9A253E2637684A5BC3E31357F863BED7A2F98C8459A33B62

Standard Audit Period End Date (mm/dd/): 10/29/2019
BR Audit Period End Date (mm/dd/): 10/29/2019

   - Certificate Name: JPRS Domain Validation Authority - G3
SHA-256 Fingerprint: 
659B7A518C6C9EB18AA1EB35AEBA7A0247817B898C1FA1840F97D2877D9A20E4

Standard Audit Period End Date (mm/dd/): 10/29/2019
BR Audit Period End Date (mm/dd/): 10/29/2019

Comments: https://bugzilla.mozilla.org/show_bug.cgi?id=1695993



CA Owner: AC Camerfirma, S.A.
   - Certificate Name: InfoCert Organization Validation CA 3
SHA-256 Fingerprint: 
247A6D807FF164031E0EB22CA85DE329A3A4E6603DBC6203F0C6E282A9C9EA84

Standard Audit Period End Date (mm/dd/): 11/27/2019
BR Audit Period End Date (mm/dd/): 11/27/2019

   - Certificate Name: Intesa Sanpaolo Organization Validation CA
SHA-256 Fingerprint: 
27CDD699DE15EE88A05BB10ED9DF2FC5E4CA25B5FDD42988963A38EC8940D55A

Standard Audit Period End Date (mm/dd/): 11/28/2019
BR Audit Period End Date (mm/dd/): 11/28/2019




___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

CCADB Proposal: Add field called JSON Array of Partitioned CRLs Issued By This CA

[Kathleen Wilson via dev-security-policy]

All,

As previously discussed, there is a section on root and intermediate 
certificate pages in the CCADB called ‘Pertaining to Certificates Issued 
by this CA’, and it currently has one field called 'Full CRL Issued By 
This CA'.


Proposal: Add field called 'JSON Array of Partitioned CRLs Issued By 
This CA'


Description of this proposed field:
When there is no full CRL for certificates issued by this CA, provide a 
JSON array whose elements are URLs of partitioned, DER-encoded CRLs that 
when combined are the equivalent of a full CRL. The JSON array may omit 
obsolete partitioned CRLs whose scopes only include expired certificates.


Example:

[
  "http://cdn.example/crl-1.crl";,
  "http://cdn.example/crl-2.crl";
]



Additionally, I propose adding a new section to 
https://www.ccadb.org/cas/fields called “Revocation Information”.


The proposed draft for this new section is here:
https://docs.google.com/document/d/1uVK0h4q5BSrFv6e86f2SwR5m2o9Kl1km74vG4HnkABw/edit?usp=sharing


I will appreciate your input on this proposal.

Thanks,
Kathleen


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Audit Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of February 2021 Audit Reminder Emails
Date: Tue, 16 Feb 2021 20:01:02 + (GMT)


Mozilla: Audit Reminder
CA Owner: Krajowa Izba Rozliczeniowa S.A. (KIR)
Root Certificates:
   SZAFIR ROOT CA2
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238854

Standard Audit Period End Date: 2019-12-18
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238855

BR Audit Period End Date: 2019-12-18
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Government of Hong Kong (SAR), Hongkong Post, Certizen
Root Certificates:
   Hongkong Post Root CA 3
   Hongkong Post Root CA 1
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238797

Standard Audit Period End Date: 2019-12-31
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238798

BR Audit Period End Date: 2019-12-31
EV Audit: https://www.ecert.gov.hk/ev/Webtrust_EVSSL_2019.pdf
EV Audit Period End Date: 2019-11-30
CA Comments: null



Mozilla: Audit Reminder
CA Owner: QuoVadis
Root Certificates:
   QuoVadis Root CA 1 G3
   QuoVadis Root CA 2
   QuoVadis Root CA 2 G3
   QuoVadis Root CA 3
   QuoVadis Root CA 3 G3
   QuoVadis Root Certification Authority
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239021

Standard Audit Period End Date: 2019-12-31
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239022

BR Audit Period End Date: 2019-12-31
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239023

EV Audit Period End Date: 2019-12-31
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Government of Spain, Fábrica Nacional de Moneda y Timbre (FNMT)
Root Certificates:
   FNMT-RCM - SHA256
Standard Audit: 
https://www.aenor.com/Certificacion_Documentos/eiDas/2020%20AENOR%20Anexo%202%20ETSI%20319%20411-1%20PSC-2019-003%20-%20FNMT-v2.pdf

Standard Audit Period End Date: 2020-01-12
BR Audit: 
https://www.aenor.com/Certificacion_Documentos/eiDas/2020%20AENOR%20Anexo%202%20ETSI%20319%20411-1%20PSC-2019-003%20-%20FNMT-v2.pdf

BR Audit Period End Date: 2020-01-12
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Taiwan-CA Inc. (TWCA)
Root Certificates:
   TWCA Global Root CA
   TWCA Root Certification Authority
Standard Audit: 
https://www.cpacanada.ca/generichandlers/cpachandler.ashx?AttachmentID=238799

Standard Audit Period End Date: 2019-12-31
BR Audit: 
https://www.cpacanada.ca/generichandlers/cpachandler.ashx?AttachmentID=238800

BR Audit Period End Date: 2019-12-31
EV Audit: 
https://www.cpacanada.ca/generichandlers/cpachandler.ashx?AttachmentID=238801

EV Audit Period End Date: 2019-12-31
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Trustis
Root Certificates:
   Trustis Limited - Trustis FPS Root CA
Standard Audit: 
https://bug1360184.bmoattachments.org/attachment.cgi?id=9146189

Standard Audit Period End Date: 2020-01-15
BR Audit: https://bug1360184.bmoattachments.org/attachment.cgi?id=9146189
BR Audit Period End Date: 2020-01-15
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Government of The Netherlands, PKIoverheid (Logius)
Root Certificates:
   Staat der Nederlanden Root CA - G3
   Staat der Nederlanden EV Root CA
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238851

Standard Audit Period End Date: 2019-12-31
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238852

BR Audit Period End Date: 2019-12-31
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238853

EV Audit Period End Date: 2019-12-31
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Amazon Trust Services
Root Certificates:
   Amazon Root CA 3
   Amazon Root CA 2
   Amazon Root CA 1
   Amazon Root CA 4
   Starfield Services Root Certificate Authority - G2
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239088

Standard Audit Period End Date: 2020-01-15
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239089

BR Audit Period End Date: 2020-01-15
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=239090

EV Audit Period End Date: 2020-01-15
CA Comments: null



Mozilla: Overdue Audit Statements
CA Owner: Buypass
Root Certificates:
   Buypass Class 2 Root CA**
   Buypass Class 3 Root CA**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://www.buypass.com/the-company/certification/_/attachment/download/413dca90-da68-483e-80e4-3978e33a8e98:76247c1b8cacd26f80531a2929c2a739db2b5159/ETS%20018.pdf

Standard Audit Period End Date: 2019-10-31
BR Audit: 
https://www.buypass.com/the-company/certification/_/attachment/download/413dca90-da68-483e-80e4-3978e33a8e98:76247c1b8cacd26f80531a2929c2a

Re: Action on Camerfirma Root CAs

[Kathleen Wilson via dev-security-policy]

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1692094 to turn off 
the Websites trust bit for the 2008 root certs, and to set the "Distrust 
for S/MIME After Date" for the older root certs.


Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Audit Reminders for Intermediate Certs

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of February 2021 Outdated Audit Statements for 
Intermediate Certs

Date: Tue, 2 Feb 2021 15:00:16 + (GMT)


CA Owner: SECOM Trust Systems CO., LTD.
   - Certificate Name: JPRS Organization Validation Authority - G3
SHA-256 Fingerprint: 
90EE548EBACACAB40207A61A378CE186B94D24AE7C55BFC83065EA96072E2B38

Standard Audit Period End Date (mm/dd/): 10/29/2019
BR Audit Period End Date (mm/dd/): 10/29/2019

   - Certificate Name: JPRS Domain Validation Authority - G3
SHA-256 Fingerprint: 
11A27671872265445CB7258EB2844EE614D14777B9F6F73BE9532122F21FAD0D

Standard Audit Period End Date (mm/dd/): 10/29/2019
BR Audit Period End Date (mm/dd/): 10/29/2019

   - Certificate Name: JPRS Organization Validation Authority - G3
SHA-256 Fingerprint: 
04C1871C68607515389FA3B0CFB83DBE6A4AF05E8C80E745702969F240606E36

Standard Audit Period End Date (mm/dd/): 10/29/2019
BR Audit Period End Date (mm/dd/): 10/29/2019

   - Certificate Name: JPRS Domain Validation Authority - G3
SHA-256 Fingerprint: 
927E9BFC0D75C3146070C3F3AFDD4A2C10F765289124997CC52CFD1209E763CB

Standard Audit Period End Date (mm/dd/): 10/29/2019
BR Audit Period End Date (mm/dd/): 10/29/2019

   - Certificate Name: JPRS Organization Validation Authority - G3
SHA-256 Fingerprint: 
21C066332D6B92DD9A253E2637684A5BC3E31357F863BED7A2F98C8459A33B62

Standard Audit Period End Date (mm/dd/): 10/29/2019
BR Audit Period End Date (mm/dd/): 10/29/2019

   - Certificate Name: JPRS Domain Validation Authority - G3
SHA-256 Fingerprint: 
659B7A518C6C9EB18AA1EB35AEBA7A0247817B898C1FA1840F97D2877D9A20E4

Standard Audit Period End Date (mm/dd/): 10/29/2019
BR Audit Period End Date (mm/dd/): 10/29/2019





CA Owner: Amazon Trust Services
   - Certificate Name: Amazon
SHA-256 Fingerprint: 
F55F9FFCB83C73453261601C7E044DB15A0F034B93C05830F28635EF889CF670

Standard Audit Period End Date (mm/dd/): 10/31/2019
BR Audit Period End Date (mm/dd/): 10/31/2019

   - Certificate Name: Amazon
SHA-256 Fingerprint: 
4A1FF6BBF481170D3B773CEC1F3A84DE3B5096575CDBF8B08432209318CA0FBD

Standard Audit Period End Date (mm/dd/): 10/31/2019
BR Audit Period End Date (mm/dd/): 10/31/2019






___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

CCADB Update: Extended ALV to EV SSL Audits on Intermediate Certs

[Kathleen Wilson via dev-security-policy]

CAs,

There are a couple updates to the CCADB that I would like to bring to 
your attention.


1) Added 'CCADB Release Notes' link to the CA home page.
It links to:
https://docs.google.com/document/d/1yMLYQFNH2JnOixVsByC99uoQd8fFfZcKlKBu-vgy3CU/edit#heading=h.6p4mru6ujyvl


2) Extended automated Audit Letter Validation (ALV) to EV SSL audits for 
intermediate certificates.
- Added ‘EV SSL Capable’ checkbox to the bottom of the ‘Certificate 
Data’ section on intermediate certificate records. 
[https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable]
- Added CA home page Task list item called ‘Intermediate Certs with 
Failed ALV Results for EV SSL’.
-- When it is non-zero, click on the ">" next to ‘Check failed Audit 
Letter Validation (ALV) results for EV SSL’, which is below the Summary 
section. Then click on the link in the 'Certificate Name' column.


Thanks,
Kathleen

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Audit Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of January 2021 Audit Reminder Emails
Date: Tue, 19 Jan 2021 20:00:30 + (GMT)

Mozilla: Audit Reminder
CA Owner: Krajowa Izba Rozliczeniowa S.A. (KIR)
Root Certificates:
   SZAFIR ROOT CA2
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238854

Standard Audit Period End Date: 2019-12-18
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238855

BR Audit Period End Date: 2019-12-18
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Government of Hong Kong (SAR), Hongkong Post, Certizen
Root Certificates:
   Hongkong Post Root CA 3
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238797

Standard Audit Period End Date: 2019-12-31
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238798

BR Audit Period End Date: 2019-12-31
EV Audit: https://www.ecert.gov.hk/ev/Webtrust_EVSSL_2019.pdf
EV Audit Period End Date: 2019-11-30
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Buypass
Root Certificates:
   Buypass Class 2 Root CA**
   Buypass Class 3 Root CA**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://www.buypass.com/the-company/certification/_/attachment/download/413dca90-da68-483e-80e4-3978e33a8e98:76247c1b8cacd26f80531a2929c2a739db2b5159/ETS%20018.pdf

Standard Audit Period End Date: 2019-10-31
BR Audit: 
https://www.buypass.com/the-company/certification/_/attachment/download/413dca90-da68-483e-80e4-3978e33a8e98:76247c1b8cacd26f80531a2929c2a739db2b5159/ETS%20018.pdf

BR Audit Period End Date: 2019-10-31
EV Audit: 
https://www.buypass.com/the-company/certification/_/attachment/download/413dca90-da68-483e-80e4-3978e33a8e98:76247c1b8cacd26f80531a2929c2a739db2b5159/ETS%20018.pdf

EV Audit Period End Date: 2019-10-31
CA Comments: null



Mozilla: Overdue Audit Statements
CA Owner: Dhimyotis / Certigna
Root Certificates:
   Certigna Root CA**
   Certigna**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://lsti-certification.fr/images/23_1377_AT_V10__LSTI_-_Attestation_letter_2020.pdf

Standard Audit Period End Date: 2019-10-18
BR Audit: 
https://lsti-certification.fr/images/23_1377_AT_V10__LSTI_-_Attestation_letter_2020.pdf

BR Audit Period End Date: 2019-10-18
CA Comments: null




___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CCADB Update to Salesforce Lightning Interface

[Kathleen Wilson via dev-security-policy]

All,

The new video about how to create an Audit Case in the CCADB is 
available here:

https://www.ccadb.org/cas/updates#instructions

Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Audit Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of December 2020 Audit Reminder Emails
Date: Tue, 15 Dec 2020 20:00:28 + (GMT)

Mozilla: Audit Reminder
CA Owner: DigiCert
Root Certificates:
   Symantec Class 2 Public Primary Certification Authority - G6
   Symantec Class 1 Public Primary Certification Authority - G6
   VeriSign Universal Root Certification Authority
   Baltimore CyberTrust Root
   Cybertrust Global Root
   DigiCert Assured ID Root CA
   DigiCert Assured ID Root G2
   GeoTrust Primary Certification Authority - G2
   DigiCert Trusted Root G4
   DigiCert Assured ID Root G3
   VeriSign Class 1 Public Primary Certification Authority - G3
   VeriSign Class 2 Public Primary Certification Authority - G3
Standard Audit: 
https://bug1458024.bmoattachments.org/attachment.cgi?id=9123453

Standard Audit Period End Date: 2019-10-31
Standard Audit: 
https://bug1458024.bmoattachments.org/attachment.cgi?id=9123443

Standard Audit Period End Date: 2019-10-31
Standard Audit: 
https://bug1458024.bmoattachments.org/attachment.cgi?id=9123448

Standard Audit Period End Date: 2019-10-31
BR Audit:
BR Audit Period End Date:
BR Audit: https://bug1458024.bmoattachments.org/attachment.cgi?id=9123452
BR Audit Period End Date: 2019-10-31
BR Audit: https://bug1458024.bmoattachments.org/attachment.cgi?id=9123442
BR Audit Period End Date: 2019-10-31
BR Audit: https://bug1458024.bmoattachments.org/attachment.cgi?id=9123447
BR Audit Period End Date: 2019-10-31
EV Audit:
EV Audit Period End Date:
EV Audit: https://bug1458024.bmoattachments.org/attachment.cgi?id=9123454
EV Audit Period End Date: 2019-10-31
EV Audit: https://bug1458024.bmoattachments.org/attachment.cgi?id=9123445
EV Audit Period End Date: 2019-10-31
CA Comments: null



Mozilla: Audit Reminder
CA Owner: D-TRUST
Root Certificates:
   D-TRUST Root CA 3 2013**
   D-TRUST Root Class 3 CA 2 2009**
   D-TRUST Root Class 3 CA 2 EV 2009**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2019120301_D-TRUST_Root_CA3_V1.0_s.pdf

Standard Audit Period End Date: 2019-10-07
Standard Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2019120302_D-TRUST_Root_Class_3_CA_2_2009_V1.0_s.pdf

Standard Audit Period End Date: 2019-10-07
Standard Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2019120303_D-TRUST_Root_Class3_CA2_EV_V1.0_s.pdf

Standard Audit Period End Date: 2019-10-07
BR Audit:
BR Audit Period End Date:
BR Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2019120302_D-TRUST_Root_Class_3_CA_2_2009_V1.0_s.pdf

BR Audit Period End Date: 2019-10-07
BR Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2019120303_D-TRUST_Root_Class3_CA2_EV_V1.0_s.pdf

BR Audit Period End Date: 2019-10-07
EV Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2019120303_D-TRUST_Root_Class3_CA2_EV_V1.0_s.pdf

EV Audit Period End Date: 2019-10-07
CA Comments: null



Mozilla: Audit Reminder
CA Owner: SwissSign AG
Root Certificates:
   SwissSign Gold CA - G2**
   SwissSign Platinum CA - G2**
   SwissSign Silver CA - G2**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://it-tuv.com/wp-content/uploads/2019/12/AA2019121902_Audit_Attestation_TA_CERT__SwissSign_Gold_G2.pdf

Standard Audit Period End Date: 2019-10-02
Standard Audit: 
https://it-tuv.com/wp-content/uploads/2020/01/AA2019121901_Audit_Attestation_TA_CERT__SwissSign_Platinum_G2.pdf

Standard Audit Period End Date: 2019-09-27
Standard Audit: 
https://it-tuv.com/wp-content/uploads/2020/01/AA2019121903_Audit_Attestation_TA_CERT__SwissSign_Silver_G2.pdf

Standard Audit Period End Date: 2019-09-27
BR Audit: 
https://it-tuv.com/wp-content/uploads/2019/12/AA2019121902_Audit_Attestation_TA_CERT__SwissSign_Gold_G2.pdf

BR Audit Period End Date: 2019-10-02
BR Audit:
BR Audit Period End Date:
BR Audit: 
https://it-tuv.com/wp-content/uploads/2020/01/AA2019121903_Audit_Attestation_TA_CERT__SwissSign_Silver_G2.pdf

BR Audit Period End Date: 2019-09-27
EV Audit: 
https://it-tuv.com/wp-content/uploads/2019/12/AA2019121902_Audit_Attestation_TA_CERT__SwissSign_Gold_G2.pdf

EV Audit Period End Date: 2019-10-02
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Buypass
Root Certificates:
   Buypass Class 2 Root CA
   Buypass Class 3 Root CA
Standard Audit: 
https://www.buypass.com/the-company/certification/_/attachment/download/413dca90-da68-483e-80e4-3978e33a8e98:76247c1b8cacd26f80531a2929c2a739db2b5159/ETS%20018.pdf

Standard Audit Period End Date: 2019-10-31
BR Audit: 
https://www.buypass.com/the-company/certification/_/attachment/download/413dca90-da68-483e-80e4-3978e33a8e98:76247c1b8cacd26f80531a2929c2a739db2b5159/ETS%20018.pdf

BR Audit Period End Date: 2019-10-31
EV Audit: 
https://www.buypass.com/the-company/certification/_/attachment/download/41

2H2020 Symantec Root Updates

[Kathleen Wilson via dev-security-policy]

All,

Continuing with the distrust of the old Symantec root certificates, 10 
root certificates were removed via bug 1670769 from NSS 3.60 and Firefox 
85.


1. GeoTrust Global CA
2. GeoTrust Primary Certification Authority
3. GeoTrust Primary Certification Authority - G3
4. thawte Primary Root CA
5. thawte Primary Root CA - G3
6. VeriSign Class 3 Public Primary Certification Authority - G4
7. VeriSign Class 3 Public Primary Certification Authority - G5
8. thawte Primary Root CA - G2
9. GeoTrust Universal CA
10. GeoTrust Universal CA 2

I also added this information to
https://wiki.mozilla.org/CA/Additional_Trust_Changes#Symantec

Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CCADB Update to Salesforce Lightning Interface

[Kathleen Wilson via dev-security-policy]

On 12/3/20 10:30 AM, Kathleen Wilson wrote:
On Thursday, December 3, we intend to migrate CCADB to Salesforce’s 
newer interface, called Lightning.


Here is a document explaining the changes:

https://docs.google.com/document/d/1RchT4pMUvzHkKpLPRYyzdhuIovVUKd88KwLyijzobT4/edit?usp=sharing 




The CCADB has been updated to the newer Lightning interface, and the 
instructions (https://www.ccadb.org/cas/) have been updated to match.
Please let me know if you run into any problems using the new CCADB 
interface.


Next week I plan to provide a new video showing how to create an Audit 
Case via the new CCADB interface.


Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CCADB Update to Salesforce Lightning Interface

[Kathleen Wilson via dev-security-policy]

On Thursday, December 3, we intend to migrate CCADB to Salesforce’s 
newer interface, called Lightning.


Here is a document explaining the changes:

https://docs.google.com/document/d/1RchT4pMUvzHkKpLPRYyzdhuIovVUKd88KwLyijzobT4/edit?usp=sharing 



The CCADB update to the newer Lightning interface is in progress. You 
may use CCADB during this update, but if you run into problems please 
try again later.


Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Announcing the Chrome Root Program

[Kathleen Wilson via dev-security-policy]

Thank you, Ryan, for providing this very helpful information.



## What does this mean for the CA Certificates Module?

Since 2015, I’ve been a Module Peer of the CA Certificates Module [1]. My
role has been to support Kathleen and Ben, and previously also Wayne and
Gerv, in performing detailed CP/CPS reviews, reviewing and responding to CA
incidents and reports, and working to collect and produce data to help
better inform the decisions of the Module Owner around adding and removing
CAs. 



I have greatly appreciated all of your support and efforts in this area.




However, the CA Certificates Module is also one of the small subset of
Modules that focuses on technical and policy direction for the product as a
whole. This has caused some confusion for folks that may not have much
experience with approaches to governance used by open source projects, and
who believe the Module Owners and Peers are absolute. Although this is not
the case, to avoid any confusion, I’ll be stepping down as Module Peer.



Understood. I will update the Peers list.



Although I’m stepping down from the title of Module Peer, there is no
functional change expected. I’ll be continuing in the same activities and
with the same goal of ensuring technical interoperability and user
security: helping examine incident reports, review CA information, and
making recommendations on how to balance the many complexities involved in
ensuring user security while minimizing compatibility issues, for users and
across browsers. 



So glad to hear that!




## What does this mean for CAs not yet in Mozilla’s program?

One area of possible divergence, however, is called out in how we’ve
prioritized inclusion requests within the Chrome Root Store. Our priority
is user security, and thus rather than operating on a “first come, first
serve” basis, we’ve captured a number of principles that we believe help
prioritize those user security interests. For example, existing CAs that
are replacing older roots with newer, modern hierarchies, greatly benefits
users, because it removes trust in the old hierarchy that may have had
incidents and misissuance, and thus risk to users, and moves to a new
hierarchy that is free of incidents. This is particularly important when
also considering that the Chrome Root Store prioritizes “single purpose”
hierarchies; that is, CA certificates which only ever issue a single type
of certificate, whether it be TLS or S/MIME or, looking broader, DV vs EV.



Perhaps it is time for Mozilla to update our approach too. Rather than 
operating on the "first come, first serve" basis, it makes sense to 
prioritize inclusion of root certificates that will improve security for 
users. Ben and I will discuss this, and propose something here in m.s.d.p.




Further diverging from Mozilla, we have prioritized attestation and
assurance engagements based on international standards, such as ISAE 3000
like those from WebTrust, over compliance-based engagements intended for
particular schemes, such as those from ETSI, due to the greater
transparency and accountability provided by those audits. The Chrome Root
Store will still continue to accept ETSI audits on a case-by-case basis,
but our priority will be towards audits that help us build a fuller picture
of the CA, its operations, and controls, such as provided by WebTrust.



Indeed, Mozilla does not currently have plans to change our policy in 
regards to ETSI audits. We would like to work with ETSI folks to try to 
resolve the concerns.




We
believe there’s a shared value in transparency, and that avoiding
fragmentation is beneficial. Even if Mozilla is not yet prepared to include
the CA, having the discussion for the Chrome Root Store easily available
helps improve the security for Mozilla users.



Agreed.


Thanks!

Kathleen

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Audit Reminders for Intermediate Certs

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of December 2020 Outdated Audit Statements for 
Intermediate Certs

Date: Tue, 1 Dec 2020 15:00:43 + (GMT)

CA Owner: Government of The Netherlands, PKIoverheid (Logius)
   - Certificate Name: UZI-register Medewerker niet op naam CA G3
SHA-256 Fingerprint: 
972957304031234ED17679FDCB97556D6173D5F2BF0E6E66D612680CA6E77685

Standard Audit Period End Date (mm/dd/): 08/31/2019

   - Certificate Name: UZI-register Medewerker op naam CA G3
SHA-256 Fingerprint: 
D28DB435E31212A3BDCCF87620F6544B99A9C02328BF983E882FD0627A1D130F

Standard Audit Period End Date (mm/dd/): 08/31/2019

   - Certificate Name: UZI-register Zorgverlener CA G3
SHA-256 Fingerprint: 
507DB60D263D3D09D283DE2E3AA435DFD8775E52BC335702E3832BBB57EC1CBD

Standard Audit Period End Date (mm/dd/): 08/31/2019

   - Certificate Name: UZI-register Medewerker op naam CA G3
SHA-256 Fingerprint: 
D8553A2880E96B7AA4C7413DD903AFD3D580504695DD26A168FD48CCE7B1474A

Standard Audit Period End Date (mm/dd/): 08/31/2019

   - Certificate Name: UZI-register Zorgverlener CA G3
SHA-256 Fingerprint: 
3EAD4F72F06F1054881D2728DE033A8E13FADE6BD165084018EB943C17378DAA

Standard Audit Period End Date (mm/dd/): 08/31/2019

   - Certificate Name: UZI-register Medewerker niet op naam CA G3
SHA-256 Fingerprint: 
38DED3FF6827579008AF4887EB9698A3CFA927FA8ED59F06BA090FB9A63E2D77

Standard Audit Period End Date (mm/dd/): 08/31/2019



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

CCADB Update to Salesforce Lightning Interface

[Kathleen Wilson via dev-security-policy]

CAs,

On Thursday, December 3, we intend to migrate CCADB to Salesforce’s 
newer interface, called Lightning.


Here is a document explaining the changes:

https://docs.google.com/document/d/1RchT4pMUvzHkKpLPRYyzdhuIovVUKd88KwLyijzobT4/edit?usp=sharing

Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CCADB Proposal: Add field called Full CRL Issued By This CA

[Kathleen Wilson via dev-security-policy]

All,

The following changes have been made in the CCADB:

On Intermediate Cert pages:
- Renamed section heading ‘Revocation Information’ to ‘Revocation 
Information for this Certificate’

- Added section called ‘Pertaining to Certificates Issued by this CA’
- Added 'Full CRL Issued By This CA' field to this new section.
Note: CAs modify this field directly on intermediate cert pages.

On Root Cert pages:
- Added section called ‘Pertaining to Certificates Issued by this CA’
- Added 'Full CRL Issued By This CA' field to this new section.
Note: Only root store operators may directly update root cert pages, so 
send email to your root store operator if you would like a URL added to 
this new field for a root cert.



Coming soon:
Add 'Full CRL Issued By This CA' column to report:
http://ccadb-public.secure.force.com/ccadb/AllCertificateRecordsCSVFormat


Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Audit Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of November 2020 Audit Reminder Emails
Date: Tue, 17 Nov 2020 20:01:50 + (GMT)

Mozilla: Audit Reminder
CA Owner: Google Trust Services LLC (GTS)
Root Certificates:
   GTS Root R2
   GTS Root R3
   GTS Root R4
   GTS Root R1
   GlobalSign
   GlobalSign
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=236832

Standard Audit Period End Date: 2019-09-30
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=236833

BR Audit Period End Date: 2019-09-30
CA Comments: null



Mozilla: Audit Reminder
CA Owner: D-TRUST
Root Certificates:
   D-TRUST Root CA 3 2013
   D-TRUST Root Class 3 CA 2 2009
   D-TRUST Root Class 3 CA 2 EV 2009
Standard Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2019120301_D-TRUST_Root_CA3_V1.0_s.pdf

Standard Audit Period End Date: 2019-10-07
Standard Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2019120302_D-TRUST_Root_Class_3_CA_2_2009_V1.0_s.pdf

Standard Audit Period End Date: 2019-10-07
Standard Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2019120303_D-TRUST_Root_Class3_CA2_EV_V1.0_s.pdf

Standard Audit Period End Date: 2019-10-07
BR Audit:
BR Audit Period End Date:
BR Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2019120302_D-TRUST_Root_Class_3_CA_2_2009_V1.0_s.pdf

BR Audit Period End Date: 2019-10-07
BR Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2019120303_D-TRUST_Root_Class3_CA2_EV_V1.0_s.pdf

BR Audit Period End Date: 2019-10-07
EV Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2019120303_D-TRUST_Root_Class3_CA2_EV_V1.0_s.pdf

EV Audit Period End Date: 2019-10-07
CA Comments: null



Mozilla: Overdue Audit Statements
CA Owner: E-Tugra
Root Certificates:
   E-Tugra Certification Authority
Standard Audit: 
https://lsti-certification.fr/images/LSTI_1646_135_AL-V10_E-Tugra.pdf

Standard Audit Period End Date: 2019-07-26
BR Audit: 
https://lsti-certification.fr/images/LSTI_1646_135_AL-V10_E-Tugra.pdf

BR Audit Period End Date: 2019-07-26
EV Audit: 
https://lsti-certification.fr/images/LSTI_1646_135_AL-V10_E-Tugra.pdf

EV Audit Period End Date: 2019-07-26

CA Comments:  https://bugzilla.mozilla.org/show_bug.cgi?id=1659426 -- 
audit delay due to Covid19.




Mozilla: Audit Reminder
CA Owner: SwissSign AG
Root Certificates:
   SwissSign Gold CA - G2
   SwissSign Platinum CA - G2
   SwissSign Silver CA - G2
Standard Audit: 
https://it-tuv.com/wp-content/uploads/2019/12/AA2019121902_Audit_Attestation_TA_CERT__SwissSign_Gold_G2.pdf

Standard Audit Period End Date: 2019-10-02
Standard Audit: 
https://it-tuv.com/wp-content/uploads/2020/01/AA2019121901_Audit_Attestation_TA_CERT__SwissSign_Platinum_G2.pdf

Standard Audit Period End Date: 2019-09-27
Standard Audit: 
https://it-tuv.com/wp-content/uploads/2020/01/AA2019121903_Audit_Attestation_TA_CERT__SwissSign_Silver_G2.pdf

Standard Audit Period End Date: 2019-09-27
BR Audit: 
https://it-tuv.com/wp-content/uploads/2019/12/AA2019121902_Audit_Attestation_TA_CERT__SwissSign_Gold_G2.pdf

BR Audit Period End Date: 2019-10-02
BR Audit:
BR Audit Period End Date:
BR Audit: 
https://it-tuv.com/wp-content/uploads/2020/01/AA2019121903_Audit_Attestation_TA_CERT__SwissSign_Silver_G2.pdf

BR Audit Period End Date: 2019-09-27
EV Audit: 
https://it-tuv.com/wp-content/uploads/2019/12/AA2019121902_Audit_Attestation_TA_CERT__SwissSign_Gold_G2.pdf

EV Audit Period End Date: 2019-10-02
CA Comments: null



Mozilla: Audit Reminder
CA Owner: SecureTrust
Root Certificates:
   Secure Global CA
   SecureTrust CA
   Trustwave Global ECC P256 Certification Authority
   Trustwave Global Certification Authority
   Trustwave Global ECC P384 Certification Authority
   XRamp Global Certification Authority
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=237400

Standard Audit Period End Date: 2019-09-30
BR Audit: 
https://certs.securetrust.com/CA/2%20-%20SecureTrust%202019%20SSL%20BL%20Report.pdf

BR Audit Period End Date: 2019-09-30
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=237401

EV Audit Period End Date: 2019-09-30
CA Comments: Changed CA Name from Trustwave to SecureTrust on February 
1, 2019.





___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

[Kathleen Wilson via dev-security-policy]

On 11/13/20 1:43 PM, Ryan Sleevi wrote:

In this regard, the principles from Mozilla's 1.0 Certificate Policy
provide a small minimum, along with some of the language from, say, the
FPKI, regarding technical competencies. The basis here is simply for the
auditor to *disclose* why they believe they meet the criteria or objectives
set. This avoids the need to address part of your questions (e.g. "How do
auditors apply to be considered qualified auditors"), because it leaves the
current policies and presumptions in place, but introduces the disclosure
requirement for why the auditor is relevant and reliable for the report.



I think it is reasonable to update section 3.2 of Mozilla's Root Store 
Policy in v2.7.1 to re-add information that appears to have been lost 
during the efforts to remove duplication with the BRs. And we could 
consider adding some incremental changes to improve transparency and 
clarify expectations regarding auditor experience.


For example, we could begin by updating section 3.2 to the following, 
which is a combination of the versions 2.7 and 2.4.1 
(https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md) of 
Mozilla's Root Store Policy. And then see if there are incremental 
updates to this that will improve transparency while keeping the audit 
statements that we add to the CCADB as fully public-facing documents.


===

3.2 Auditors

Mozilla requires that audits MUST be performed by a competent, 
independent, qualified party.


The burden is on the CA to prove that it has met the below requirements. 
However the CA MAY request a preliminary determination from us regarding 
the acceptability of the criteria and/or the competent, independent, 
qualified party or parties by which it proposes to meet the requirements 
of this policy.


By "competent party" we mean a person or other entity who is authorized 
to perform audits according to the stated criteria (e.g., by the 
organization responsible for the criteria or by a relevant government 
agency) or for whom there is sufficient public information available to 
determine that the party is competent to judge the CA’s conformance to 
the stated criteria. In the latter case the "public information" 
referred to SHOULD include information regarding the party’s:
- knowledge of CA-related technical issues such as public key 
cryptography and related standards;
- experience in performing security-related audits, evaluations, or risk 
analyses; and

- honesty and objectivity.

By "independent party" we mean a person or other entity who is not 
affiliated with the CA as an employee or director and for whom at least 
one of the following statements is true:

- the party is not financially compensated by the CA;
- the nature and amount of the party’s financial compensation by the CA 
is publicly disclosed; or
- the party is bound by law, government regulation, and/or a 
professional code of ethics to render an honest and objective judgement 
regarding the CA.


By "qualified party" we mean a person or other entity who meets the 
requirements of section 8.2 of the Baseline Requirements. If a CA wishes 
to use auditors who do not fit the definition in section 8.2 of the 
Baseline Requirements, they MUST receive written permission from Mozilla 
to do so in advance of the start of the audit engagement. Mozilla will 
make its own determination as to the suitability of the suggested party 
or parties, at its sole discretion.


==

Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

[Kathleen Wilson via dev-security-policy]

PS: In the meantime, we will continue to verify auditor qualifications 
as described here:

https://wiki.mozilla.org/CA/Audit_Statements#Auditor_Qualifications


On 11/12/20 4:27 PM, Kathleen Wilson wrote:

 > It is proposed in Issue #192
 > <https://github.com/mozilla/pkipolicy/issues/192> that information about
 > individual auditor's qualifications be provided--identity, competence,
 > experience and independence. (For those interested as to this 
independence

 > requirement, Mozilla Policy v.1.0 required either disclosure of the
 > auditor's compensation or the establishment that the auditor "is 
bound by
 > law, government regulation, and/or a professional code of ethics to 
render

 > an honest and objective judgement regarding the CA.")


I am very much in favor of increasing transparency about the 
qualifications of the auditors providing audit statements for CAs in our 
program. However, I think that we need to spend more time figuring out a 
few things before adding such a requirement to our policy. Therefore, I 
think we should add this to our list of things to spend some focused 
time to figure out in early 2021, and move this item to the next version 
of Mozilla’s root store policy.


Below are some of the questions we need to be able to answer before 
adding this requirement to Mozilla's root store policy.


Please do NOT respond to these questions now. We will have future 
discussions about this when we are ready.


- What information is needed and in what format to demonstrate each 
individual auditor's qualifications?
- What are the criteria to be considered and what is sufficient to be 
considered a qualified auditor?

- How do auditors apply to be considered qualified auditors?
- How can new participants become involved in this space and become 
qualified auditors?

- What is the process to determine if an auditor is qualified?
- Does every auditor signing their name or listed in an audit statement 
need to be verified as a qualified auditor? Or just the lead auditor?
- How are the qualifications of the auditors communicated in conjunction 
with the audit statement(s)?

- Who is responsible for verifying auditor qualifications?
- Who is responsible for maintaining the list of known qualified auditors?
- How do CAs find out if their auditors are qualified?

I look forward to having these discussions in full later, but I think 
this effort is too large in scope for version 2.7.1 of Mozilla's Root 
Store Policy.


Thanks,
Kathleen



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

[Kathleen Wilson via dev-security-policy]

> It is proposed in Issue #192
>  that information about
> individual auditor's qualifications be provided--identity, competence,
> experience and independence. (For those interested as to this 
independence

> requirement, Mozilla Policy v.1.0 required either disclosure of the
> auditor's compensation or the establishment that the auditor "is bound by
> law, government regulation, and/or a professional code of ethics to 
render

> an honest and objective judgement regarding the CA.")


I am very much in favor of increasing transparency about the 
qualifications of the auditors providing audit statements for CAs in our 
program. However, I think that we need to spend more time figuring out a 
few things before adding such a requirement to our policy. Therefore, I 
think we should add this to our list of things to spend some focused 
time to figure out in early 2021, and move this item to the next version 
of Mozilla’s root store policy.


Below are some of the questions we need to be able to answer before 
adding this requirement to Mozilla's root store policy.


Please do NOT respond to these questions now. We will have future 
discussions about this when we are ready.


- What information is needed and in what format to demonstrate each 
individual auditor's qualifications?
- What are the criteria to be considered and what is sufficient to be 
considered a qualified auditor?

- How do auditors apply to be considered qualified auditors?
- How can new participants become involved in this space and become 
qualified auditors?

- What is the process to determine if an auditor is qualified?
- Does every auditor signing their name or listed in an audit statement 
need to be verified as a qualified auditor? Or just the lead auditor?
- How are the qualifications of the auditors communicated in conjunction 
with the audit statement(s)?

- Who is responsible for verifying auditor qualifications?
- Who is responsible for maintaining the list of known qualified auditors?
- How do CAs find out if their auditors are qualified?

I look forward to having these discussions in full later, but I think 
this effort is too large in scope for version 2.7.1 of Mozilla's Root 
Store Policy.


Thanks,
Kathleen

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for Policy Constraints

[Kathleen Wilson via dev-security-policy]

>> For this MRSP Issue #152 update to v2.7.1, I propose that we make each
>> occurrence of "capable of issuing EV certificates" link to
>> https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable


In the definition of EV TLS Capable, I'd move the last bullet up to the top.



Done. Thanks!


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for Policy Constraints

[Kathleen Wilson via dev-security-policy]

On 10/16/20 11:26 PM, Ryan Sleevi wrote:

Because of this, it seems that there is a simpler, clearer, unambiguous
path for CAs that seems useful to move to:
- If a CA is trusted for purpose X, that certificate, and all subordinate
CAs, should be audited against the criteria relevant for X



I am in favor of this approach for a future version of Mozilla's Root 
Store Policy, but I prefer not to try to tackle it in this v2.7.1 
update.  So I filed a github issue to remind us to consider this in the 
next version:


https://github.com/mozilla/pkipolicy/issues/220


I have added a section called "EV TLS Capable" to the wiki pages, and I 
will appreciate feedback on it:


https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable

For this MRSP Issue #152 update to v2.7.1, I propose that we make each 
occurrence of "capable of issuing EV certificates" link to 
https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable


Thanks,
Kathleen

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Audit Reminders for Intermediate Certs

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of November 2020 Outdated Audit Statements for 
Intermediate Certs

Date: Tue, 3 Nov 2020 15:00:07 + (GMT)


CA Owner: AC Camerfirma, S.A.
   - Certificate Name: MULTICERT SSL Certification Authority 001
SHA-256 Fingerprint: 
06A57D1CD5879FBA2135610DD8D725CC268D2A6DE8A463D424C4B9DA89848696

Standard Audit Period End Date (mm/dd/): 07/18/2019
BR Audit Period End Date (mm/dd/): 07/18/2019

   - Certificate Name: DigitalSign Primary CA
SHA-256 Fingerprint: 
8101C3BAF9D0EDD71180D1F37D6D75B77B0E8CFB593D342C3A31E467985D4A74

Standard Audit Period End Date (mm/dd/): 07/22/2019
BR Audit Period End Date (mm/dd/): 07/22/2019



CA Owner: QuoVadis
   - Certificate Name: DigitalSign Qualified CA - G4
SHA-256 Fingerprint: 
41678B8897E635DEA03B6E48565E267BA5AAC3B8F4DC4B74B7A0A9748CFDD35E

Standard Audit Period End Date (mm/dd/): 07/22/2019





___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

CCADB Proposal: Add field called Full CRL Issued By This CA

[Kathleen Wilson via dev-security-policy]

All,

Root store operators would like to easily find and use the URLs to the 
Full CRLs for things like Mozilla’s CRLite. The BRs do not require CRL 
URLs in end-entity certificates, and many CAs use partitioned CRLs for 
end-entity certificates.


Proposal: Add field called 'Full CRL Issued By This CA'

- New field on intermediate certificate records which may be filled in 
by CAs or root store operators when the certificate signs certificates 
that do not contain CRL URLs or only contain URLs to partitioned CRLs.


- This field would be included in public-facing reports such as 
http://ccadb-public.secure.force.com/ccadb/AllCertificateRecordsCSVFormat 
so that it can be used programmatically by root store operators, and 
could also be provided in crt.sh.


- Also add this field to root certificate records, even though only root 
store operators can currently update root certificate records.



I will appreciate your input on this proposal.

Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Audit Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of October 2020 Audit Reminder Emails
Date: Tue, 20 Oct 2020 19:00:26 + (GMT)


Mozilla: Audit Reminder
CA Owner: Internet Security Research Group (ISRG)
Root Certificates:
   ISRG Root X1**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238186

Standard Audit Period End Date: 2019-08-31
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238187

BR Audit Period End Date: 2019-08-31
CA Comments: null



Mozilla: Your root is in danger of being removed
CA Owner: Sectigo
Root Certificates:
   COMODO RSA Certification Authority**
   USERTrust ECC Certification Authority**
   AAA Certificate Services**
   COMODO Certification Authority**
   COMODO ECC Certification Authority**
   USERTrust RSA Certification Authority**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://bug1472993.bmoattachments.org/attachment.cgi?id=9078178

Standard Audit Period End Date: 2019-03-31
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=231163

BR Audit Period End Date: 2019-03-31
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=231164

EV Audit Period End Date: 2019-03-31

CA Comments: https://bugzilla.mozilla.org/show_bug.cgi?id=1648593
Audit statements provided via Bugzilla. Waiting for WebTrust Seals



Mozilla: Audit Reminder
CA Owner: E-Tugra
Root Certificates:
   E-Tugra Certification Authority
Standard Audit: 
https://lsti-certification.fr/images/LSTI_1646_135_AL-V10_E-Tugra.pdf

Standard Audit Period End Date: 2019-07-26
BR Audit: 
https://lsti-certification.fr/images/LSTI_1646_135_AL-V10_E-Tugra.pdf

BR Audit Period End Date: 2019-07-26
EV Audit: 
https://lsti-certification.fr/images/LSTI_1646_135_AL-V10_E-Tugra.pdf

EV Audit Period End Date: 2019-07-26

CA Comments:  https://bugzilla.mozilla.org/show_bug.cgi?id=1659426 -- 
audit delay due to Covid19.





Mozilla: Audit Reminder
CA Owner: Microsec Ltd.
Root Certificates:
   Microsec e-Szigno Root CA 2009
   e-Szigno Root CA 2017
Standard Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019121301_Microsec-eSzignoRoot-CA-2009_V1.2_s.pdf

Standard Audit Period End Date: 2019-09-14
Standard Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019121302_e-Szigno-Root-CA-2017_V1.1_s.pdf

Standard Audit Period End Date: 2019-09-14
BR Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019121301_Microsec-eSzignoRoot-CA-2009_V1.2_s.pdf

BR Audit Period End Date: 2019-09-14
BR Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019121302_e-Szigno-Root-CA-2017_V1.1_s.pdf

BR Audit Period End Date: 2019-09-14
CA Comments: null



Mozilla: Audit Reminder
CA Owner: NetLock Ltd.
Root Certificates:
   NetLock Arany (Class Gold) Főtanúsítvány
Standard Audit: 
http://eng.matrix-tanusito.hu/wp-content/uploads/2019/11/I-NL19T2_TAN.EN_TAN.ME-01_signed.pdf

Standard Audit Period End Date: 2019-09-03
BR Audit: 
http://eng.matrix-tanusito.hu/wp-content/uploads/2019/11/I-NL19T2_TAN.EN_TAN.ME-01_signed.pdf

BR Audit Period End Date: 2019-09-03
CA Comments: null



Mozilla: Overdue Audit Statements
CA Owner: SECOM Trust Systems CO., LTD.
Root Certificates:
   SECOM Trust.net - Security Communication RootCA1**
   Security Communication RootCA2**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=234693

Standard Audit Period End Date: 2019-06-06
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=234694

BR Audit Period End Date: 2019-06-06
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=234695

EV Audit Period End Date: 2019-06-06

CA Comments: CA is updating the test websites



Mozilla: Audit Reminder
CA Owner: China Financial Certification Authority (CFCA)
Root Certificates:
   CFCA EV ROOT
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=236836

Standard Audit Period End Date: 2019-07-31
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=236837

BR Audit Period End Date: 2019-07-31
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=236838

EV Audit Period End Date: 2019-07-31
CA Comments: null




___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: PEM of root certs in Mozilla's root store

[Kathleen Wilson via dev-security-policy]

The text version has been updated to have each line limited to 64 
characters.


Text:

https://ccadb-public.secure.force.com/mozilla/IncludedRootsPEMTxt?TrustBitsInclude=Websites

https://ccadb-public.secure.force.com/mozilla/IncludedRootsPEMTxt?TrustBitsInclude=Email

CSV:
https://ccadb-public.secure.force.com/mozilla/IncludedRootsPEMCSV?TrustBitsInclude=Websites

https://ccadb-public.secure.force.com/mozilla/IncludedRootsPEMCSV?TrustBitsInclude=Email


1. The reports that contain /only/ PEM data.  I argue that the
traditional format of concatenated PEM files (as used by e.g. the
openssl command line tool) without CSV embellishments would be
preferable, and that the reports in the latest post by Kathleen
lacked the PEM line wrapping while still containing CSV
artifacts. 


Jakob, please explain what you mean by "still containing CSV artifacts". 
Does the new version of the text report have the problem?




2. The reports that contain other data in CSV format.  ...


Opening the CSV version of the reports in Excel and Numbers works fine 
for me. So I don't understand what the problem is with having this 
report be a direct extract of the PEM data that the CCADB has for each 
root certificate.




However, it might also be reasonable that if these concerns aren't easily
addressable, perhaps not offering the feed is another option, since it
seems a lot of work for something that should be and is naturally
discouraged.


It's not a lot of work, just a matter of understanding what is most 
useful to folks.


I think it would be good to have downstreams using current data, e.g. 
data published directly via the CCADB. I think that providing the data 
in an easily consumable format is better than having folks extract the 
data from certdata.txt.


Thanks,
Kathleen

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: PEM of root certs in Mozilla's root store

[Kathleen Wilson via dev-security-policy]

On 10/7/20 1:09 PM, Jakob Bohm wrote:
Please note that at least the first CSV download is not really a CSV 
file, as there are line feeds within each "PEM" value, and only one 
column.  It would probably be more useful as a simple concatenated PEM 
file, as used by various software packages as a root store input format.





Here's updated reports...

Text:

https://ccadb-public.secure.force.com/mozilla/IncludedRootsPEMTxt?TrustBitsInclude=Websites

https://ccadb-public.secure.force.com/mozilla/IncludedRootsPEMTxt?TrustBitsInclude=Email

CSV:
https://ccadb-public.secure.force.com/mozilla/IncludedRootsPEMCSV?TrustBitsInclude=Websites

https://ccadb-public.secure.force.com/mozilla/IncludedRootsPEMCSV?TrustBitsInclude=Email


If the Text reports look good, I'll add them to the wiki page, 
https://wiki.mozilla.org/CA/Included_Certificates



Thanks,
Kathleen

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Verifying Auditor Qualifications

[Kathleen Wilson via dev-security-policy]

On 10/11/20 11:06 PM, Nikolaos Soumelidis wrote:

Dear Kathleen,

We have been informed by ACCREDIA that the accreditation pages have now been 
updated to include ETSI EN 319 403. This removes any ambiguity.

URLs remain the same; for example, QMSCERT's accreditation:
https://services.accredia.it/ppsearch/accredia_orgmask.jsp?ID_LINK=1733&area=310&PPSEARCH_ORG_SEARCH_MASK_ORG=3761&PPSEARCH_ORG_SEARCH_MASK_SCHEMI=&PPSEARCH_ORG_SEARCH_MASK_SCHEMI_ALTRI=&PPSEARCH_ODC_SEARCH_MASK_SETTORE_ACCR=&PPSEARCH_ORG_SEARCH_MASK_CITTA=&PPSEARCH_ORG_SEARCH_MASK_PROVINCIA=&PPSEARCH_ORG_SEARCH_MASK_REGIONE=&PPSEARCH_ORG_SEARCH_MASK_STATO=&orgtype=all&PPSEARCH_ORG_SEARCH_MASK_SCOPO=&PPSEARCH_ORG_SEARCH_MASK_PDFACCREDITAMENTO=&submitBtn=Cerca


From a quick check, this applies for the other ACCREDIA CABs as well.


In addition to the above fix, the new accreditation documents will include 
similar explicit references.

Best regards,
Nikolaos Soumelidis



Thanks for letting me know. I have updated the corresponding auditor 
qualifications in the CCADB, since ACCREDIA now provides the required 
information directly on their website.


Thanks!
Kathleen


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: PEM of root certs in Mozilla's root store

[Kathleen Wilson via dev-security-policy]

On 10/7/20 9:30 AM, Matthew Hardeman wrote:

Would it be unreasonable to also consider publishing, as an "easy to use"
list, that set of only those anchors which are currently trusted in the
program and for which no exceptional in-product policy enforcement is
imposed?  (TLD constraints, provisional distrusts, etc.)

The lazier implementers are going to take the raw set of anchors and none
of the policy associated, and so the default assumption should be that none
of the enhanced policy enforcements from nss or firefox would get copied
along.




These reports are automatically generated by CCADB (Salesforce), so I 
cannot filter out all of the exceptions that may occur or that are 
currently listed in https://wiki.mozilla.org/CA/Additional_Trust_Changes


I could add a report that filters out root certificates that are 
name-constrained. However, there is currently only one name-constrained 
included root cert, and this option ended up not being very popular 
among CAs requesting root inclusion.


Also note that in Mozilla's program being name-constrained does not 
release the CA from following the same rules that all of the other CAs 
have to follow.


Therefore, I'm not currently inclined to add another report to filter 
out name-constrained root certs (currently just the one root cert).


Thanks,
Kathleen



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: PEM of root certs in Mozilla's root store

[Kathleen Wilson via dev-security-policy]

On 10/6/20 7:09 PM, Ryan Sleevi wrote:

It seems like there should be a link to
https://wiki.mozilla.org/CA/FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F
there



I added that link to https://wiki.mozilla.org/CA/Included_Certificates

Thanks,
Kathleen

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

PEM of root certs in Mozilla's root store

[Kathleen Wilson via dev-security-policy]

All,

I've been asked to publish Mozilla's root store in a way that is easy to 
consume by downstreams, so I have added the following to 
https://wiki.mozilla.org/CA/Included_Certificates


CCADB Data Usage Terms


PEM of Root Certificates in Mozilla's Root Store with the Websites 
(TLS/SSL) Trust Bit Enabled (CSV)



PEM of Root Certificates in Mozilla's Root Store with the Email (S/MIME) 
Trust Bit Enabled (CSV)




Please let me know if you have feedback or recommendations about this.

Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Audit Reminders for Intermediate Certs

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of October 2020 Outdated Audit Statements for 
Intermediate Certs

Date: Tue, 6 Oct 2020 14:00:25 + (GMT)


CA Owner: Government of The Netherlands, PKIoverheid (Logius)
   - Certificate Name: QuoVadis PKIoverheid Organisatie Server CA - G3
SHA-256 Fingerprint: 
CE2332390208742A1ACA6513974C4C9DB2691EAF4568B533E4A17ED5DDA973E6

Standard Audit Period End Date (mm/dd/): 05/31/2019
BR Audit Period End Date (mm/dd/): 05/31/2019

   - Certificate Name: QuoVadis PKIoverheid Server CA 2020
SHA-256 Fingerprint: 
EB2C2A806C69FC963C4E24A5BBEA20ED4E3B86AE798730BB4EEA51BF9DE33325

Standard Audit Period End Date (mm/dd/): 05/31/2019
BR Audit Period End Date (mm/dd/): 05/31/2019

   - Certificate Name: QuoVadis PKIoverheid Organisatie Persoon CA - G3
SHA-256 Fingerprint: 
15073C6BBDC74699A88518C27A57C956E5E23D6CA9619E521A468C7873DE4F8A

Standard Audit Period End Date (mm/dd/): 05/31/2019

   - Certificate Name: QuoVadis PKIoverheid Organisatie Services CA - G3
SHA-256 Fingerprint: 
BECFDE124CEDD344D925CB55EDDA662D9A9C0688FA9A0870CE3DBB6DA4313E4E

Standard Audit Period End Date (mm/dd/): 05/31/2019

   - Certificate Name: QuoVadis PKIoverheid Organisatie Server CA - G3
SHA-256 Fingerprint: 
85363A24CB1B66E6CF6244E87D243DBB8306F607357C614CB9C4C224A0E04358

Standard Audit Period End Date (mm/dd/): 05/31/2019
BR Audit Period End Date (mm/dd/): 05/31/2019


Bug Filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1669518



CA Owner: DigiCert
   - Certificate Name: thawte Primary Transition Root
SHA-256 Fingerprint: 
DBA1097710F3C629943C23DC7503AC82B9142825EF049F1C26538DB36B480549

Standard Audit Period End Date (mm/dd/): 05/31/2019
BR Audit Period End Date (mm/dd/): 05/31/2019

   - Certificate Name: TrustWise G3
SHA-256 Fingerprint: 
DD563A271590588CC055685E368CB02F6DED343186358B3A3814B2AA97005525

Standard Audit Period End Date (mm/dd/): 06/21/2019

   - Certificate Name: Government of Malta e-Mail Certificate Service CA G3
SHA-256 Fingerprint: 
0054DD53C74523CD542979850828F0F3CD18228687D4ED4AE345B5FEADE1FC9C

Standard Audit Period End Date (mm/dd/): 06/21/2019





CA Owner: Asseco Data Systems S.A. (previously Unizeto Certum)
   - Certificate Name: SSL.com Root Certification Authority RSA
SHA-256 Fingerprint: 
ACF718DF838E640051777D1947F51620E8D804BA186553AE52FC9811B5D34B8B

Standard Audit Period End Date (mm/dd/): 06/30/2019
Code Signing Audit Period End Date (mm/dd/): 06/30/2019
BR Audit Period End Date (mm/dd/): 06/30/2019
EV SSL Audit Period End Date (mm/dd/): 06/30/2019

   - Certificate Name: SSL.com EV Root Certification Authority RSA R2
SHA-256 Fingerprint: 
B97176F21B6ED64609267B2D1A2A9FAF0C4DEBD44644DC85EB6AE986FC867D56

Standard Audit Period End Date (mm/dd/): 06/30/2019
Code Signing Audit Period End Date (mm/dd/): 06/30/2019
BR Audit Period End Date (mm/dd/): 06/30/2019
EV SSL Audit Period End Date (mm/dd/): 06/30/2019






___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Audit Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

On 9/15/20 3:21 PM, Kathleen Wilson wrote:

 Forwarded Message 
Subject: Summary of September 2020 Audit Reminder Emails





Mozilla: Audit Reminder
CA Owner: E-Tugra
Root Certificates:
    E-Tugra Certification Authority
Standard Audit: 
https://lsti-certification.fr/images/LSTI_1646_135_AL-V10_E-Tugra.pdf

Standard Audit Period End Date: 2019-07-26
BR Audit: 
https://lsti-certification.fr/images/LSTI_1646_135_AL-V10_E-Tugra.pdf

BR Audit Period End Date: 2019-07-26
EV Audit: 
https://lsti-certification.fr/images/LSTI_1646_135_AL-V10_E-Tugra.pdf

EV Audit Period End Date: 2019-07-26
CA Comments: null




E-Tugra's representative has reminded me that they filed 
https://bugzilla.mozilla.org/show_bug.cgi?id=1659426 to inform us of 
audit delay due to Covid19.


Thanks,
Kathleen

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Audit Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of September 2020 Audit Reminder Emails
Date: Tue, 15 Sep 2020 19:00:12 + (GMT)


Mozilla: Overdue Audit Statements
CA Owner: eMudhra Technologies Limited
Root Certificates:
   emSign Root CA - C1**
   emSign ECC Root CA - C3**
   emSign ECC Root CA - G3**
   emSign Root CA - G1**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=234195

Standard Audit Period End Date: 2019-05-31
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=234196

BR Audit Period End Date: 2019-05-31
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=234204

EV Audit Period End Date: 2019-05-31

CA Comments: Audit statements pass ALV. Waiting for test website updates.



Mozilla: Your root is in danger of being removed
CA Owner: Sectigo
Root Certificates:
   COMODO RSA Certification Authority**
   USERTrust ECC Certification Authority**
   AAA Certificate Services**
   COMODO Certification Authority**
   COMODO ECC Certification Authority**
   USERTrust RSA Certification Authority**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://bug1472993.bmoattachments.org/attachment.cgi?id=9078178

Standard Audit Period End Date: 2019-03-31
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=231163

BR Audit Period End Date: 2019-03-31
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=231164

EV Audit Period End Date: 2019-03-31

CA Comments: Audit statements provided via Bugzilla. Waiting for 
WebTrust Seals




Mozilla: Audit Reminder
CA Owner: E-Tugra
Root Certificates:
   E-Tugra Certification Authority
Standard Audit: 
https://lsti-certification.fr/images/LSTI_1646_135_AL-V10_E-Tugra.pdf

Standard Audit Period End Date: 2019-07-26
BR Audit: 
https://lsti-certification.fr/images/LSTI_1646_135_AL-V10_E-Tugra.pdf

BR Audit Period End Date: 2019-07-26
EV Audit: 
https://lsti-certification.fr/images/LSTI_1646_135_AL-V10_E-Tugra.pdf

EV Audit Period End Date: 2019-07-26
CA Comments: null



Mozilla: Audit Reminder
CA Owner: GoDaddy
Root Certificates:
   Go Daddy Class 2 CA**
   Go Daddy Root Certificate Authority - G2**
   Starfield Class 2 CA**
   Starfield Root Certificate Authority - G2**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=234200

Standard Audit Period End Date: 2019-06-30
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=234201

BR Audit Period End Date: 2019-06-30
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=234202

EV Audit Period End Date: 2019-06-30
CA Comments: null



Mozilla: Audit Reminder
CA Owner: IdenTrust Services, LLC
Root Certificates:
   IdenTrust Commercial Root CA 1
   IdenTrust Public Sector Root CA 1
   DST Root CA X3
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=236834

Standard Audit Period End Date: 2019-06-30
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=236835

BR Audit Period End Date: 2019-06-30
CA Comments: null



Mozilla: Overdue Audit Statements
CA Owner: SECOM Trust Systems CO., LTD.
Root Certificates:
   SECOM Trust.net - Security Communication RootCA1**
   Security Communication RootCA2**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=234693

Standard Audit Period End Date: 2019-06-06
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=234694

BR Audit Period End Date: 2019-06-06
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=234695

EV Audit Period End Date: 2019-06-06
CA Comments: null



Mozilla: Audit Reminder
CA Owner: China Financial Certification Authority (CFCA)
Root Certificates:
   CFCA EV ROOT
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=236836

Standard Audit Period End Date: 2019-07-31
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=236837

BR Audit Period End Date: 2019-07-31
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=236838

EV Audit Period End Date: 2019-07-31
CA Comments: null



Mozilla: Audit Reminder
CA Owner: SSL.com
Root Certificates:
   SSL.com EV Root Certification Authority ECC
   SSL.com Root Certification Authority ECC
   SSL.com Root Certification Authority RSA
   SSL.com EV Root Certification Authority RSA R2
Standard Audit: 
https://cdn.ssl.com/app/uploads/2020/02/SSLcom-2019-WTCA-Indp-Acct-Report-and-Mgm

Re: Add Ben Wilson as Peer of Mozilla's CA Certificates and CA Certificate Policy modules

[Kathleen Wilson via dev-security-policy]

On 8/27/20 11:11 AM, Kathleen Wilson wrote:

All,

I propose adding Ben Wilson as a peer[1] of Mozilla's CA Certificates
Module[2] and CA Certificate Policy Module[3]. As you know, Ben and I
are distributing the job of running Mozilla's CA Program between us, so
Ben will continue to actively work on both of these Modules.

Thanks,
Kathleen

[1] https://wiki.mozilla.org/Modules
[2] https://wiki.mozilla.org/Modules/All#CA_Certificates
[3] https://wiki.mozilla.org/Modules/All#Mozilla_CA_Certificate_Policy




I have added Ben Wilson as a Peer of Mozilla's CA Certificates and CA
Certificate Policy modules.

Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Verifying Auditor Qualifications

[Kathleen Wilson via dev-security-policy]

On 8/31/20 11:07 AM, Kathleen Wilson wrote:

On 8/28/20 3:59 PM, Kathleen Wilson wrote:

On 8/26/20 1:41 PM, Kathleen Wilson wrote:
The 5 CABs that I haven't been able to complete the Standard Check 
for are:


- Bureau Veritas Italia S.p.A. - NAB is Accredia
- CSQA - NAB is Accredia
- KIWA - NAB is Accredia
- QMSCERT - NAB is Accredia
- QSCert - NAB is CAI



Update:  I received email from Accredia declaring the ETSI EN 
standards that the KIWA CAB is accredited for. I think it is 
reasonable to accept that for this auditor's re-verification. And I 
have asked that KIWA request Accredia to provide this information 
directly on their website for future reference.



Updates:

1) I received email from Accredia declaring the ETSI EN standards that 
the QMSCERT CAB is accredited for, and I will accept that for now.


2) The email from Accredia also said "We are working to provide this 
information directly on our website for future references."


3) 
https://ec.europa.eu/futurium/en/content/list-conformity-assessment-bodies-cabs-accredited-against-requirements-eidas-regulation 
was updated to provide the updated 
list_of_eidas_accredited_cabs-2020-08-28.pdf


Note: The 
https://ec.europa.eu/futurium/en/content/list-conformity-assessment-bodies-cabs-accredited-against-requirements-eidas-regulation 
site says:

    "Please note that the list is an informative tool."
So, the list_of_eidas_accredited_cabs-2020-08-28.pdf is not in itself 
sufficient proof of a CAB's qualifications. It is very helpful in making 
it easy to find the NAB and CAB accreditation information, but we must 
still check the NAB and CAB accreditation information and make sure the 
CAB accreditation document lists the ETSI EN 319 403, ETSI EN 319 401, 
ETSI EN 319 411-1, and ETSI EN 319 411-2 standards as per

https://wiki.mozilla.org/CA/Audit_Statements#Standard_Check

Thanks to all of you who have been helping with this!

Kathleen



Update: I received email from Accredia declaring the ETSI EN standards 
that the Bureau Veritas Italia S.p.A. and CSQA CABs are accredited for, 
and I will accept those for now.


So the remaining CAB that I still need to verify is QSCert, and I filed 
the following bug for it:


https://bugzilla.mozilla.org/show_bug.cgi?id=1662533

Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Audit Reminders for Intermediate Certs

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of September 2020 Outdated Audit Statements for 
Intermediate Certs

Date: Tue, 1 Sep 2020 14:00:20 + (GMT)

CA Owner: Government of The Netherlands, PKIoverheid (Logius)
   - Certificate Name: QuoVadis PKIoverheid Organisatie Server CA - G3
SHA-256 Fingerprint: 
CE2332390208742A1ACA6513974C4C9DB2691EAF4568B533E4A17ED5DDA973E6

Standard Audit Period End Date (mm/dd/): 05/31/2019
BR Audit Period End Date (mm/dd/): 05/31/2019

   - Certificate Name: QuoVadis PKIoverheid Server CA 2020
SHA-256 Fingerprint: 
5E99DD4A92307B92C495C56E24241DD79B4579D3CD0AD1ECC6D9D24A7981CA98

Standard Audit Period End Date (mm/dd/): 05/31/2019
BR Audit Period End Date (mm/dd/): 05/31/2019

   - Certificate Name: QuoVadis PKIoverheid Server CA 2020
SHA-256 Fingerprint: 
EB2C2A806C69FC963C4E24A5BBEA20ED4E3B86AE798730BB4EEA51BF9DE33325

Standard Audit Period End Date (mm/dd/): 05/31/2019
BR Audit Period End Date (mm/dd/): 05/31/2019

   - Certificate Name: QuoVadis PKIoverheid EV CA
SHA-256 Fingerprint: 
ED3DB748D6D78EEFF0B9452BC6A02E039039C55075A439323B8BA85FB21B9DDA

Standard Audit Period End Date (mm/dd/): 05/31/2019
BR Audit Period End Date (mm/dd/): 05/31/2019
EV SSL Audit Period End Date (mm/dd/): 05/31/2019

   - Certificate Name: QuoVadis PKIoverheid Organisatie Persoon CA - G3
SHA-256 Fingerprint: 
15073C6BBDC74699A88518C27A57C956E5E23D6CA9619E521A468C7873DE4F8A

Standard Audit Period End Date (mm/dd/): 05/31/2019

   - Certificate Name: QuoVadis PKIoverheid Organisatie Services CA - G3
SHA-256 Fingerprint: 
BECFDE124CEDD344D925CB55EDDA662D9A9C0688FA9A0870CE3DBB6DA4313E4E

Standard Audit Period End Date (mm/dd/): 05/31/2019

   - Certificate Name: QuoVadis PKIoverheid Organisatie Server CA - G3
SHA-256 Fingerprint: 
85363A24CB1B66E6CF6244E87D243DBB8306F607357C614CB9C4C224A0E04358

Standard Audit Period End Date (mm/dd/): 05/31/2019
BR Audit Period End Date (mm/dd/): 05/31/2019





CA Owner: DigiCert
   - Certificate Name: DigiCert TLS ICA VRSN Universal
SHA-256 Fingerprint: 
BA5B6E5DFEBDAE1C80BD72790BC85BCC6538AB4613023DA706CE826415F5E5B3

Standard Audit Period End Date (mm/dd/): 05/31/2019
BR Audit Period End Date (mm/dd/): 05/31/2019

   - Certificate Name: DigiCert TLS ICA GeoTrust PCA-G3
SHA-256 Fingerprint: 
95D9A8D30F6B1C069C296B3E106BC3CE01EB84AD57860D0F46BF7F15D053B1C0

Standard Audit Period End Date (mm/dd/): 05/31/2019
BR Audit Period End Date (mm/dd/): 05/31/2019

   - Certificate Name: DigiCert TLS ICA Thawte PCA-G3
SHA-256 Fingerprint: 
56E4F454D982DCDCE611B7B707DB12C533EAC29A25F4A5307E1C065713B0DC8E

Standard Audit Period End Date (mm/dd/): 05/31/2019
BR Audit Period End Date (mm/dd/): 05/31/2019

   - Certificate Name: DigiCert TLS ICA GeoTrust Global
SHA-256 Fingerprint: 
516D856D0353BA69FFEB9C1EBA035D780844857006ECE99C051EC19C10C36CD5

Standard Audit Period End Date (mm/dd/): 05/31/2019
BR Audit Period End Date (mm/dd/): 05/31/2019

   - Certificate Name: DigiCert Transition RSA Root
SHA-256 Fingerprint: 
0D88900DBB68C6CA5471F653FCACD407EBD7B1519046F9E0B8CED3C274FD11A1

Standard Audit Period End Date (mm/dd/): 05/31/2019
BR Audit Period End Date (mm/dd/): 05/31/2019

   - Certificate Name: DigiCert Transition ECC Root
SHA-256 Fingerprint: 
DB98194E55B936D26E6CB3F460A262EB6CA66337E7BFF17A0BFC083251F63626

Standard Audit Period End Date (mm/dd/): 05/31/2019
BR Audit Period End Date (mm/dd/): 05/31/2019

   - Certificate Name: thawte Primary G3 Transition Root
SHA-256 Fingerprint: 
85743AEA6A97C13445E0824C2E1FE502B97ADD124A97EF5120FE07F55812FC33

Standard Audit Period End Date (mm/dd/): 05/31/2019
BR Audit Period End Date (mm/dd/): 05/31/2019

   - Certificate Name: GeoTrust Primary Transition Root
SHA-256 Fingerprint: 
F54F6CED56CF682B570A6CAEC313E9482760DE12E8F928AE30452C4C66AC761A

Standard Audit Period End Date (mm/dd/): 05/31/2019
BR Audit Period End Date (mm/dd/): 05/31/2019

   - Certificate Name: DigiCert Universal Transition Root
SHA-256 Fingerprint: 
88A07073D4527069DC9E978053F35729705C058302648ED02E5FCE6561459E61

Standard Audit Period End Date (mm/dd/): 05/31/2019
BR Audit Period End Date (mm/dd/): 05/31/2019





CA Owner: Government of Taiwan, Government Root Certification Authority 
(GRCA)

   - Certificate Name: 行政院工商憑證管理中心 (MOEACA)
SHA-256 Fingerprint: 
90FFC5150CE0535069E7E5EF961E4047FB0861A140732C8CEDC7E8D58EB59BD1

Standard Audit Period End Date (mm/dd/): 03/31/2019
BR Audit Period End Date (mm/dd/): 03/31/2019

   - Certificate Name: 行政院內政部憑證管理中心 (MOICA)
SHA-256 Fingerprint: 
45111450FB31EF5137E4B7CFF9EE2BEF23E8BBFD165086DFBD93DF2F329B785E

Standard Audit Period End Date (mm/dd/): 03/31/2019
BR Audit Period End Date (mm/dd/): 03/31/2019

   - Certificate Name: 行政院醫事憑證管理中心 (HCA)
SHA-256 Fingerprint: 
A05EE43E556C8C2A38766D0377FB486806D169EA195E69CD873381D8EAB7DFCD

Standard Audit Period 

Re: Verifying Auditor Qualifications

[Kathleen Wilson via dev-security-policy]

On 8/28/20 3:59 PM, Kathleen Wilson wrote:

On 8/26/20 1:41 PM, Kathleen Wilson wrote:
The 5 CABs that I haven't been able to complete the Standard Check for 
are:


- Bureau Veritas Italia S.p.A. - NAB is Accredia
- CSQA - NAB is Accredia
- KIWA - NAB is Accredia
- QMSCERT - NAB is Accredia
- QSCert - NAB is CAI



Update:  I received email from Accredia declaring the ETSI EN standards 
that the KIWA CAB is accredited for. I think it is reasonable to accept 
that for this auditor's re-verification. And I have asked that KIWA 
request Accredia to provide this information directly on their website 
for future reference.



Updates:

1) I received email from Accredia declaring the ETSI EN standards that 
the QMSCERT CAB is accredited for, and I will accept that for now.


2) The email from Accredia also said "We are working to provide this 
information directly on our website for future references."


3) 
https://ec.europa.eu/futurium/en/content/list-conformity-assessment-bodies-cabs-accredited-against-requirements-eidas-regulation 
was updated to provide the updated 
list_of_eidas_accredited_cabs-2020-08-28.pdf


Note: The 
https://ec.europa.eu/futurium/en/content/list-conformity-assessment-bodies-cabs-accredited-against-requirements-eidas-regulation 
site says:

   "Please note that the list is an informative tool."
So, the list_of_eidas_accredited_cabs-2020-08-28.pdf is not in itself 
sufficient proof of a CAB's qualifications. It is very helpful in making 
it easy to find the NAB and CAB accreditation information, but we must 
still check the NAB and CAB accreditation information and make sure the 
CAB accreditation document lists the ETSI EN 319 403, ETSI EN 319 401, 
ETSI EN 319 411-1, and ETSI EN 319 411-2 standards as per

https://wiki.mozilla.org/CA/Audit_Statements#Standard_Check

Thanks to all of you who have been helping with this!

Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Verifying Auditor Qualifications

[Kathleen Wilson via dev-security-policy]

On 8/26/20 1:41 PM, Kathleen Wilson wrote:

The 5 CABs that I haven't been able to complete the Standard Check for are:

- Bureau Veritas Italia S.p.A. - NAB is Accredia
- CSQA - NAB is Accredia
- KIWA - NAB is Accredia
- QMSCERT - NAB is Accredia
- QSCert - NAB is CAI



Update:  I received email from Accredia declaring the ETSI EN standards 
that the KIWA CAB is accredited for. I think it is reasonable to accept 
that for this auditor's re-verification. And I have asked that KIWA 
request Accredia to provide this information directly on their website 
for future reference.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

How to Create and Audit Case in CCADB

[Kathleen Wilson via dev-security-policy]

CAs,

I have updated the instructions for creating an Audit Case in the CCADB, 
and have added a video that demonstrates the process.


https://www.ccadb.org/cas/updates#instructions

Please let me know if you have any questions about the updated process.

Thanks,
Kathleen

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Add Ben Wilson as Peer of Mozilla's CA Certificates and CA Certificate Policy modules

[Kathleen Wilson via dev-security-policy]

All,

I propose adding Ben Wilson as a peer[1] of Mozilla's CA Certificates
Module[2] and CA Certificate Policy Module[3]. As you know, Ben and I
are distributing the job of running Mozilla's CA Program between us, so
Ben will continue to actively work on both of these Modules.

Thanks,
Kathleen

[1] https://wiki.mozilla.org/Modules
[2] https://wiki.mozilla.org/Modules/All#CA_Certificates
[3] https://wiki.mozilla.org/Modules/All#Mozilla_CA_Certificate_Policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Verifying Auditor Qualifications

[Kathleen Wilson via dev-security-policy]

On 8/26/20 2:01 PM, Nikolaos Soumelidis wrote:

I will greatly appreciate it if you can reach out to them again. Please

let me know what information you would need.

Will definitely do. Probably no other information will be needed by you, but
I do appreciate the offer.



Thanks!




Please note that in the case of QMSCERT ("A" member of ACAB'C),
https://wiki.mozilla.org/CA/Audit_Statements#Simplified_Check applies.




https://wiki.mozilla.org/CA/Audit_Statements#Simplified_Check
"IMPORTANT: At this time, this check may only be used as a preliminary 
check, and the Standard Check must also be completed."


But the ACAB'c list is very helpful, with the direct link to the 
accreditation attestation for each ACAB.


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Verifying Auditor Qualifications

[Kathleen Wilson via dev-security-policy]

On 8/26/20 12:35 PM, Nikolaos Soumelidis wrote:


One would expect that they would put that in the accreditation documents or references, 



That helps answer part of my question -- that it is reasonable to expect 
the NAB's accreditation document to specifically list these ETSI EN 
standards.




If you feel that this is necessary, we can reach out to them again and provide 
feedback as soon as we get it.


I will greatly appreciate it if you can reach out to them again. Please 
let me know what information you would need.


According to the instructions for verifying ETSI auditor qualifications 
(https://wiki.mozilla.org/CA/Audit_Statements#Standard_Check) it is 
necessary that there be something on the NAB's website that clearly 
indicates that the CAB is accredited to perform audits for those 
specific standards. So my question in this m.d.s.p forum is: Is the 
information currently provided by Accredia specific enough, or do we 
need to get Accredia to update their documentation process?


Note that with the exception of 4 CABs accredited by Accredia and 1 CAB 
accredited by CAI, I was able to complete 
https://wiki.mozilla.org/CA/Audit_Statements#Standard_Check for the CABs 
used by CAs in Mozilla's root store.

The 5 CABs that I haven't been able to complete the Standard Check for are:

- Bureau Veritas Italia S.p.A. - NAB is Accredia
- CSQA - NAB is Accredia
- KIWA - NAB is Accredia
- QMSCERT - NAB is Accredia
- QSCert - NAB is CAI

Thanks,
Kathleen

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Verifying Auditor Qualifications

[Kathleen Wilson via dev-security-policy]

On 8/26/20 12:29 PM, Ben Wilson wrote:

This raises the
question of whether NABs typically include ETSI EN 319 401, ETSI EN 319
411-1 and ETSI EN 319 411-2 in such CAB certification records. 



The answer to that question is yes, the other NABs typically do list 
that information directly in the CAB certification records.


Here are a few examples:

https://www.enac.es/documents/7020/5ae31445-73fa-4e16-acc4-78e079375c4f

http://www.ipac.pt/pesquisa/ficha_ocp.asp?id=C0009

http://www.ukas.com/wp-content/uploads/schedule_uploads/00011/00295/0003Product%20Certification.pdf

http://www.cofrac.fr/annexes/sect5/5-0597.pdf

https://nah.gov.hu/uploads/attachment/file/7913/RO_3_-CERTOP_0034_K_2019_03_28.pdf 



https://www.dakks.de/as/ast/d/D-ZE-16077-01-00.pdf

Cheers,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Verifying Auditor Qualifications

[Kathleen Wilson via dev-security-policy]

On 6/3/20 4:20 PM, Kathleen Wilson wrote:
It recently came to my attention that I need to be more diligent in 
verifying auditor qualifications. 


https://wiki.mozilla.org/CA/Audit_Statements#Auditor_Qualifications


All,

While re-verifying auditor qualifications I have run into the following 
situation, that I will appreciate your opinions on.



https://wiki.mozilla.org/CA/Audit_Statements#Standard_Check

>> Check 1:  The NAB is listed as “full member” under 
https://european-accreditation.org/ea-members/directory-of-ea-members-and-mla-signatories/


The NAB, Accredia (https://www.accredia.it/) is listed as a "Full Member".


>> Check 2:  The accreditation documentation was issued by that NAB and 
is hosted on the NAB's website


The accreditation documentation on the NAB's website for a few CABs:

QMSCERT: 
http://services.accredia.it/ppsearch/accredia_orgmask.jsp?ID_LINK=1733&area=310&PPSEARCH_ORG_SEARCH_MASK_ORG=3761


Bureau Veritas Italia: 
http://services.accredia.it/ppsearch/accredia_orgmask.jsp?ID_LINK=1733&area=310&PPSEARCH_ORG_SEARCH_MASK_ORG=0663


CSQA: 
http://services.accredia.it/ppsearch/accredia_orgmask.jsp?ID_LINK=1733&area=310&PPSEARCH_ORG_SEARCH_MASK_ORG=0010



>> Check 3: The CABs accreditation documentation explicitly refers to 
all of the following: 411-1, and ETSI EN 319 411-2>


This is where I'm running into difficulty. The NAB's accreditation 
documentation does not explicitly state that the CAB is certified to 
audit against those ETSI EN standards.


For each of the CABs listed above, an Allegato (for UNI CEI EN/ISO/IEC 
17065:2012) can be downloaded that says: "TSP (Trust Service Provider) 
and the services they offer compared with (EU Regulation) 910/2014 and / 
or specific provisions adopted by the national authorities for the 
services covered by the Accreditation Scheme."


Which apparently refers to the the following documents that list the 
ETSI EN standards:
Italian: 
https://www.accredia.it/app/uploads/2020/03/Circolare_tecnica_DC_05-2020.pdf
English: 
https://www.accredia.it/app/uploads/2017/03/7015_DC2017SSV046eng.pdf

https://www.accredia.it/documento/circolare-dc-n-82017-informativa-in-merito-allaccreditamento-degli-organismi-di-certificazione-operanti-a-fronte-dei-requisiti-del-regolamento-ue-2014_910-eidas-e-della-norma-etsi-en-319_4/


Is that sufficient evidence that the CAB is certified by the NAB to 
audit according to the ETSI EN 319 403, ETSI EN 319 401, ETSI EN 319 
411-1, and ETSI EN 319 411-2 standards?


Thanks,
Kathleen






___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CCADB Updates August 20-24: Policy Document Objects

[Kathleen Wilson via dev-security-policy]

Here are a couple clarifications about this CCADB update. Please let me 
know if you run into any problems or have further questions about it.


1) The multiple-policy-documents feature is only available at the root 
certificate level.


2) Changes to root certificate records and their policy document objects 
are still only done via Audit Cases. We are aware that we need to enable 
CAs to provide mid-year updates that are not related to audit 
statements, and plan to work on that soon.



Regarding
>> We are already working to fix the AllCertificateRecordsCSVFormat 
report, which is currently messing up crt.sh/mozilla-disclosures.


The report has been fixed.

Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CCADB Updates August 20-24: Policy Document Objects

[Kathleen Wilson via dev-security-policy]

The CCADB has been updated to enable many-to-many mapping between policy 
documents and root certificates.


If you run into any problems using the CCADB, please send an email to 
supp...@ccadb.org. We are already working to fix the 
AllCertificateRecordsCSVFormat report, which is currently messing up 
crt.sh/mozilla-disclosures.


Summary of the changes:

1) Root Certificate pages have a new 'Policy Documents' section. The old 
information is also still visible in the 'DEPRECATED: Policies and 
Practices Information' section.


2) Case pages:
- There's a new 'Policy Documents' section. The old information is also 
still visible in the 'DEPRECATED: Policies and Practices Information' 
section.

- Added button: 'Update Policy Documents'
- Updated Progress Bar and instructions at the top of the page
- Updated https://www.ccadb.org/cas/updates#instructions

3) Moved 'Document Repository' and 'Document Repository Description' 
fields from root certificate pages to CA Owner pages. For those of you 
with multiple document repository URLs, please send me email to let me 
know if you would like change the list in your CA Owner record.


Thanks,
Kathleen


On 8/13/20 4:35 PM, Kathleen Wilson wrote:

All,

Currently CCADB only allows for one CP URL and one CPS URL per root 
certificate, so we are updating the CCADB to enable many-to-many mapping 
between policy documents and root certificates. One or more policy 
documents may be provided and associated with one or more root 
certificates and policy OIDs. Screenshots showing the changes are here:


https://docs.google.com/document/d/1bhlCSLhdAfLa1J-ek7N3jupLRE630XOjqeNaMQ9lSsU/edit?usp=sharing 



We intend to migrate the changes to production August 20 to 24. You 
should be able to use the CCADB during this update, which will impact: 
CA Owner, Root Certificate, Audit Case, Root Inclusion Case.


There will be a one-time migration from existing fields to new Policy 
Document objects.


If you run into problems with the CCADB from August 20 to August 24, 
please try again later. If you run into problems with the CCADB after 
August 24, please send an email to supp...@ccadb.org.


Thanks,
Kathleen


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Audit Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of August 2020 Audit Reminder Emails
Date: Tue, 18 Aug 2020 19:00:34 + (GMT)

Mozilla: Audit Reminder
CA Owner: eMudhra Technologies Limited
Root Certificates:
   emSign Root CA - C1
   emSign ECC Root CA - C3
   emSign ECC Root CA - G3
   emSign Root CA - G1
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=234195

Standard Audit Period End Date: 2019-05-31
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=234196

BR Audit Period End Date: 2019-05-31
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=234204

EV Audit Period End Date: 2019-05-31
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Chunghwa Telecom
Root Certificates:
   Chunghwa Telecom Co., Ltd. - ePKI Root Certification Authority
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=232565

Standard Audit Period End Date: 2019-05-31
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=232566

BR Audit Period End Date: 2019-05-31
CA Comments: null



Mozilla: Overdue Audit Statements
CA Owner: Sectigo
Root Certificates:
   COMODO RSA Certification Authority**
   USERTrust ECC Certification Authority**
   AAA Certificate Services**
   COMODO Certification Authority**
   COMODO ECC Certification Authority**
   USERTrust RSA Certification Authority**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://bug1472993.bmoattachments.org/attachment.cgi?id=9078178

Standard Audit Period End Date: 2019-03-31
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=231163

BR Audit Period End Date: 2019-03-31
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=231164

EV Audit Period End Date: 2019-03-31
CA Comments: null



Mozilla: Audit Reminder
CA Owner: GoDaddy
Root Certificates:
   Go Daddy Class 2 CA
   Go Daddy Root Certificate Authority - G2
   Starfield Class 2 CA
   Starfield Root Certificate Authority - G2
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=234200

Standard Audit Period End Date: 2019-06-30
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=234201

BR Audit Period End Date: 2019-06-30
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=234202

EV Audit Period End Date: 2019-06-30
CA Comments: null



Mozilla: Audit Reminder
CA Owner: IdenTrust Services, LLC
Root Certificates:
   IdenTrust Commercial Root CA 1
   IdenTrust Public Sector Root CA 1
   DST Root CA X3
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=236834

Standard Audit Period End Date: 2019-06-30
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=236835

BR Audit Period End Date: 2019-06-30
CA Comments: null



Mozilla: Audit Reminder
CA Owner: SECOM Trust Systems CO., LTD.
Root Certificates:
   SECOM Trust.net - Security Communication RootCA1
   Security Communication RootCA2
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=234693

Standard Audit Period End Date: 2019-06-06
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=234694

BR Audit Period End Date: 2019-06-06
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=234695

EV Audit Period End Date: 2019-06-06
CA Comments: null



Mozilla: Audit Reminder
CA Owner: SSL.com
Root Certificates:
   SSL.com EV Root Certification Authority ECC
   SSL.com Root Certification Authority ECC
   SSL.com Root Certification Authority RSA
   SSL.com EV Root Certification Authority RSA R2
Standard Audit: 
https://cdn.ssl.com/app/uploads/2020/02/SSLcom-2019-WTCA-Indp-Acct-Report-and-Mgmt-Assertion-June-2019-REVISED-FINAL.pdf

Standard Audit Period End Date: 2019-06-30
BR Audit: 
https://cdn.ssl.com/app/uploads/2020/02/SSLcom-2019-WTBR-Indp-Acct-Report-and-Mgmt-Assertion-June-2019-REVISED-FINAL.pdf

BR Audit Period End Date: 2019-06-30
EV Audit: 
https://cdn.ssl.com/app/uploads/2020/02/SSLcom-2019-WTEV-SSL-Indp-Acct-Report-and-Mgmt-Assertion-June-2019-REVISED-FINAL.pdf

EV Audit Period End Date: 2019-06-30
CA Comments: null




___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

CCADB Updates August 20-24: Policy Document Objects

[Kathleen Wilson via dev-security-policy]

All,

Currently CCADB only allows for one CP URL and one CPS URL per root 
certificate, so we are updating the CCADB to enable many-to-many mapping 
between policy documents and root certificates. One or more policy 
documents may be provided and associated with one or more root 
certificates and policy OIDs. Screenshots showing the changes are here:


https://docs.google.com/document/d/1bhlCSLhdAfLa1J-ek7N3jupLRE630XOjqeNaMQ9lSsU/edit?usp=sharing

We intend to migrate the changes to production August 20 to 24. You 
should be able to use the CCADB during this update, which will impact: 
CA Owner, Root Certificate, Audit Case, Root Inclusion Case.


There will be a one-time migration from existing fields to new Policy 
Document objects.


If you run into problems with the CCADB from August 20 to August 24, 
please try again later. If you run into problems with the CCADB after 
August 24, please send an email to supp...@ccadb.org.


Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Adding Distrust-After Date columns to CCADB reports

[Kathleen Wilson via dev-security-policy]

While we're at it we're going to update the date format in the reports 
to -MM-DD.



On 8/4/20 9:06 AM, Kathleen Wilson wrote:
No concerns have been raised, so we will proceed with the inserting the 
new columns between the "Trust Bits" and "EV Policy OID(s)" columns.


On 7/29/20 11:11 AM, Kathleen Wilson wrote:

All,

I have been asked to add two columns to the following CCADB reports.

Columns to add:
1) Distrust for TLS After Date
2) Distrust for S/MIME After Date

Reports to update:
1) 
https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport
2) 
https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReportCSVFormat 

3) 
https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReportPEMCSV 



I think it makes most sense to insert the new columns between the 
"Trust Bits" and "EV Policy OID(s)" columns, but I realize that could 
break things for folks who are using a CSV version of the report.


Please let me know if you are aware of particular hardship that will 
be caused if I insert the two columns, rather than adding them to the 
end.


Also, let me know if there are other CCADB reports that you would like 
these two columns added to.


Thanks,
Kathleen




___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Audit Reminders for Intermediate Certs

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of August 2020 Outdated Audit Statements for 
Intermediate Certs

Date: Tue, 4 Aug 2020 14:00:25 + (GMT)


CA Owner: Government of Taiwan, Government Root Certification Authority 
(GRCA)

   - Certificate Name: 行政院工商憑證管理中心 (MOEACA)
SHA-256 Fingerprint: 
90FFC5150CE0535069E7E5EF961E4047FB0861A140732C8CEDC7E8D58EB59BD1

Standard Audit Period End Date (mm/dd/): 03/31/2019
BR Audit Period End Date (mm/dd/): 03/31/2019

   - Certificate Name: 行政院內政部憑證管理中心 (MOICA)
SHA-256 Fingerprint: 
45111450FB31EF5137E4B7CFF9EE2BEF23E8BBFD165086DFBD93DF2F329B785E

Standard Audit Period End Date (mm/dd/): 03/31/2019
BR Audit Period End Date (mm/dd/): 03/31/2019

   - Certificate Name: 行政院醫事憑證管理中心 (HCA)
SHA-256 Fingerprint: 
A05EE43E556C8C2A38766D0377FB486806D169EA195E69CD873381D8EAB7DFCD

Standard Audit Period End Date (mm/dd/): 03/31/2019


Comments on Government Root Certification Authority - Taiwan:
CKA_NSS_SERVER_DISTRUST_AFTER set to 9/19/2019 in NSS 3.53, Firefox 78.
https://bugzilla.mozilla.org/show_bug.cgi?id=1621159



CA Owner: Asseco Data Systems S.A. (previously Unizeto Certum)
   - Certificate Name: UCA Global G2 Root
SHA-256 Fingerprint: 
C1AFC65B1E813B0E6146E6AA5341681272ABE9A38D59F7BD1B27B729834A0D9C

Standard Audit Period End Date (mm/dd/): 04/30/2019
BR Audit Period End Date (mm/dd/): 04/30/2019






___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Adding Distrust-After Date columns to CCADB reports

[Kathleen Wilson via dev-security-policy]

No concerns have been raised, so we will proceed with the inserting the 
new columns between the "Trust Bits" and "EV Policy OID(s)" columns.


On 7/29/20 11:11 AM, Kathleen Wilson wrote:

All,

I have been asked to add two columns to the following CCADB reports.

Columns to add:
1) Distrust for TLS After Date
2) Distrust for S/MIME After Date

Reports to update:
1) 
https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport
2) 
https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReportCSVFormat 

3) 
https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReportPEMCSV 



I think it makes most sense to insert the new columns between the "Trust 
Bits" and "EV Policy OID(s)" columns, but I realize that could break 
things for folks who are using a CSV version of the report.


Please let me know if you are aware of particular hardship that will be 
caused if I insert the two columns, rather than adding them to the end.


Also, let me know if there are other CCADB reports that you would like 
these two columns added to.


Thanks,
Kathleen


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Adding Distrust-After Date columns to CCADB reports

[Kathleen Wilson via dev-security-policy]

All,

I have been asked to add two columns to the following CCADB reports.

Columns to add:
1) Distrust for TLS After Date
2) Distrust for S/MIME After Date

Reports to update:
1) https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport
2) 
https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReportCSVFormat
3) 
https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReportPEMCSV


I think it makes most sense to insert the new columns between the "Trust 
Bits" and "EV Policy OID(s)" columns, but I realize that could break 
things for folks who are using a CSV version of the report.


Please let me know if you are aware of particular hardship that will be 
caused if I insert the two columns, rather than adding them to the end.


Also, let me know if there are other CCADB reports that you would like 
these two columns added to.


Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Audit Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of July 2020 Audit Reminder Emails
Date: Tue, 21 Jul 2020 19:00:13 + (GMT)


Mozilla: Audit Reminder
CA Owner: eMudhra Technologies Limited
Root Certificates:
   emSign Root CA - C1
   emSign ECC Root CA - C3
   emSign ECC Root CA - G3
   emSign Root CA - G1
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=234195

Standard Audit Period End Date: 2019-05-31
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=234196

BR Audit Period End Date: 2019-05-31
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=234204

EV Audit Period End Date: 2019-05-31
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Actalis
Root Certificates:
   Actalis Authentication Root CA**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://www.actalis.it/documenti-en/actalisca_audit_statement_2019.aspx

Standard Audit Period End Date: 2019-05-31
BR Audit: 
https://www.actalis.it/documenti-en/actalisca_audit_statement_2019.aspx

BR Audit Period End Date: 2019-05-31
EV Audit: 
https://www.actalis.it/documenti-en/actalisca_audit_statement_2019.aspx

EV Audit Period End Date: 2019-05-31
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Disig, a.s.
Root Certificates:
   CA Disig Root R2**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: https://eidas.disig.sk/pdf/Audit2019_report.pdf
Standard Audit Period End Date: 2019-05-24
BR Audit: https://eidas.disig.sk/pdf/Audit2019_report.pdf
BR Audit Period End Date: 2019-05-24
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Chunghwa Telecom
Root Certificates:
   Chunghwa Telecom Co., Ltd. - ePKI Root Certification Authority
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=232565

Standard Audit Period End Date: 2019-05-31
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=232566

BR Audit Period End Date: 2019-05-31
CA Comments: null



Mozilla: Overdue Audit Statements
CA Owner: Sectigo
Root Certificates:
   COMODO RSA Certification Authority**
   USERTrust ECC Certification Authority**
   AAA Certificate Services**
   COMODO Certification Authority**
   COMODO ECC Certification Authority**
   USERTrust RSA Certification Authority**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://bug1472993.bmoattachments.org/attachment.cgi?id=9078178

Standard Audit Period End Date: 2019-03-31
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=231163

BR Audit Period End Date: 2019-03-31
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=231164

EV Audit Period End Date: 2019-03-31
CA Comments: null



Mozilla: Overdue Audit Statements
CA Owner: GlobalSign
Root Certificates:
   GlobalSign**
   GlobalSign**
   GlobalSign**
   GlobalSign Root CA**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=231566

Standard Audit Period End Date: 2019-03-31
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=9112465
BR Audit Period End Date: 2019-03-31
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=231568

EV Audit Period End Date: 2019-03-31
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Government of Spain, Autoritat de Certificació de la Comunitat 
Valenciana (ACCV)

Root Certificates:
   ACCVRAIZ1
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=232656

Standard Audit Period End Date: 2019-04-30
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=232657

BR Audit Period End Date: 2019-04-30
CA Comments: null



Mozilla: Overdue Audit Statements
CA Owner: Government of Taiwan, Government Root Certification Authority 
(GRCA)

Root Certificates:
   Government Root Certification Authority - Taiwan**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
http://grca.nat.gov.tw/download/Audit/GRCA_GCA_XCA_WTCA_Audit_Report_2019.pdf

Standard Audit Period End Date: 2019-03-31
BR Audit: 
http://grca.nat.gov.tw/download/Audit/GRCA_GCA_BR_Audit_Report_2019.pdf

BR Audit Period End Date: 2019-03-31
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Izenpe S.A.
Root Certificates:
   Izenpe.com
Standard Audit: 
http://lsti-certification.fr/images/LSTI_Audit_Atttestation_Letter_1652-127_V21_S_copie.pdf

Standard Audit Period End Date: 2019-05-24
BR Audit: 
http://lsti-certification.fr/images/LSTI_Audit_Atttestation_Letter_1652-127_V21_S_copie.pdf

BR Audit Period End Date: 2019-05-24
EV Audit: 
http://lsti-certification.fr/images/LSTI_Audit_A

Re: Audit Reminders for Intermediate Certs

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of July 2020 Outdated Audit Statements for Intermediate 
Certs

Date: Tue, 7 Jul 2020 14:00:11 + (GMT)


CA Owner: Government of Taiwan, Government Root Certification Authority 
(GRCA)

   - Certificate Name: 行政院工商憑證管理中心 (MOEACA)
SHA-256 Fingerprint: 
90FFC5150CE0535069E7E5EF961E4047FB0861A140732C8CEDC7E8D58EB59BD1

Standard Audit Period End Date (mm/dd/): 03/31/2019
BR Audit Period End Date (mm/dd/): 03/31/2019

   - Certificate Name: 行政院內政部憑證管理中心 (MOICA)
SHA-256 Fingerprint: 
45111450FB31EF5137E4B7CFF9EE2BEF23E8BBFD165086DFBD93DF2F329B785E

Standard Audit Period End Date (mm/dd/): 03/31/2019
BR Audit Period End Date (mm/dd/): 03/31/2019

   - Certificate Name: 行政院醫事憑證管理中心 (HCA)
SHA-256 Fingerprint: 
A05EE43E556C8C2A38766D0377FB486806D169EA195E69CD873381D8EAB7DFCD

Standard Audit Period End Date (mm/dd/): 03/31/2019


Comments on Government Root Certification Authority - Taiwan:
CKA_NSS_SERVER_DISTRUST_AFTER set to 9/19/2019 in NSS 3.53, Firefox 78.
https://bugzilla.mozilla.org/show_bug.cgi?id=1621159
Email trust bit disabled in NSS 3.54, Firefox 79.
https://bugzilla.mozilla.org/show_bug.cgi?id=1621151


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Verifying Auditor Qualifications

[Kathleen Wilson via dev-security-policy]

On 6/24/20 8:48 PM, Ryan Sleevi wrote:

On Wed, Jun 24, 2020 at 3:08 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


I have updated the following section of the wiki page to incorporate
feedback that I received from representatives of ACAB'c.


https://wiki.mozilla.org/CA/Audit_Statements#Verifying_ETSI_Auditor_Qualifications

I will greatly appreciate it if those of you familiar with ETSI audits
will review it and provide feedback.



I would suggest that, for the time being, ACAB’c isn’t a shortcut. I
realize that means more work for Mozilla, and broadly for the industry, but
it might provide an opportunity for ACAB’c to focus on whether the goal is
to support eIDAS audit schemes and accreditation, or whether it is to
provide browsers equivalent confidence and focused collaboration in the way
the WebTrust TF had engaged in. That isn’t to suggest the auditors might
not also provide eIDAS audits, but it seems a real missed opportunity for
auditors to more proactively engage and ensure needs like Mozilla’s are met.


I have added the following sentence to the top of the Simplified Check 
section:
IMPORTANT: At this time, this check may only be used as a preliminary 
check, and the Standard Check must also be completed.


Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Verifying Auditor Qualifications

[Kathleen Wilson via dev-security-policy]

I have updated the following section of the wiki page to incorporate 
feedback that I received from representatives of ACAB'c.


https://wiki.mozilla.org/CA/Audit_Statements#Verifying_ETSI_Auditor_Qualifications

I will greatly appreciate it if those of you familiar with ETSI audits 
will review it and provide feedback.


Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Audit Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of June 2020 Audit Reminder Emails
Date: Tue, 16 Jun 2020 19:00:31 + (GMT)


Mozilla: Audit Reminder
CA Owner: Shanghai Electronic Certification Authority Co., Ltd. (SHECA)
Root Certificates:
   UCA Extended Validation Root
   UCA Global G2 Root
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=230630

Standard Audit Period End Date: 2019-04-30
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=230631

BR Audit Period End Date: 2019-04-30
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=230632

EV Audit Period End Date: 2019-04-30
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Atos
Root Certificates:
   Atos TrustedRoot 2011**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://www.mydqs.com/kunden/kundendatenbank.html?aoemydqs%5BrequestId%5D=europev2-DQS-D4601883F55A11E9B50B005056A04F41-_v2&aoemydqs%5BdownloadKey%5D=ebe97140cee29a7c498ca32f1d76cc2143a5a383&aoemydqs%5Baction%5D=downloadDocument&cHash=f86244b64421ebaad940

Standard Audit Period End Date: 2019-04-28
BR Audit: 
https://www.mydqs.com/kunden/kundendatenbank.html?aoemydqs%5BrequestId%5D=europev2-DQS-D4601883F55A11E9B50B005056A04F41-_v2&aoemydqs%5BdownloadKey%5D=ebe97140cee29a7c498ca32f1d76cc2143a5a383&aoemydqs%5Baction%5D=downloadDocument&cHash=f86244b64421ebaad940

BR Audit Period End Date: 2019-04-28
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Sectigo
Root Certificates:
   COMODO RSA Certification Authority
   USERTrust ECC Certification Authority
   AAA Certificate Services
   AddTrust Class 1 CA Root
   AddTrust External CA Root
   COMODO Certification Authority
   COMODO ECC Certification Authority
   USERTrust RSA Certification Authority
Standard Audit: 
https://bug1472993.bmoattachments.org/attachment.cgi?id=9078178

Standard Audit Period End Date: 2019-03-31
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=231163

BR Audit Period End Date: 2019-03-31
BR Audit:
BR Audit Period End Date:
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=231164

EV Audit Period End Date: 2019-03-31
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert)
Root Certificates:
   EC-ACC
Standard Audit: 
https://www.aenor.com/Certificacion_Documentos/eiDas/2019%20AENOR%20Anexo%202%20ETSI%20319%20411-2%20PSC-CAOC_v4.pdf

Standard Audit Period End Date: 2019-03-28
BR Audit: 
https://www.aenor.com/Certificacion_Documentos/eiDas/2019%20AENOR%20Anexo%202%20ETSI%20319%20411-1%20PSC-CAOC_v4.pdf

BR Audit Period End Date: 2019-03-28
CA Comments: null



Mozilla: Audit Reminder
CA Owner: GlobalSign
Root Certificates:
   GlobalSign
   GlobalSign
   GlobalSign
   GlobalSign Root CA
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=231566

Standard Audit Period End Date: 2019-03-31
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=9112465
BR Audit Period End Date: 2019-03-31
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=231568

EV Audit Period End Date: 2019-03-31
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Government of Spain, Autoritat de Certificació de la Comunitat 
Valenciana (ACCV)

Root Certificates:
   ACCVRAIZ1
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=232656

Standard Audit Period End Date: 2019-04-30
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=232657

BR Audit Period End Date: 2019-04-30
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Government of Taiwan, Government Root Certification Authority 
(GRCA)

Root Certificates:
   Government Root Certification Authority - Taiwan
Standard Audit: 
http://grca.nat.gov.tw/download/Audit/GRCA_GCA_XCA_WTCA_Audit_Report_2019.pdf

Standard Audit Period End Date: 2019-03-31
BR Audit: 
http://grca.nat.gov.tw/download/Audit/GRCA_GCA_BR_Audit_Report_2019.pdf

BR Audit Period End Date: 2019-03-31
CA Comments: null



Mozilla: Audit Reminder
CA Owner: HARICA
Root Certificates:
   Hellenic Academic and Research Institutions RootCA 2011
   Hellenic Academic and Research Institutions ECC RootCA 2015
   Hellenic Academic and Research Institutions RootCA 2015
Standard Audit: 
https://repo.harica.gr/documents/HARICA-AUDIT_ATTESTATION_W_ANNEX_290617-7-R2-AA-text.pdf

Standard Audit Period End Date: 2019-03-29
BR Audit: 
https://repo.harica.gr/documents/HARICA-AUDIT_ATTESTATION_W_ANNEX_290617-7-R2-AA-text.pdf

BR Audit Period End Date: 2019-03-29
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Telia Company (formerly TeliaSonera)
Root Certificates:
   Sonera Class2 CA
   TeliaSonera Root CA v1
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandl

Re: Verifying Auditor Qualifications

[Kathleen Wilson via dev-security-policy]

On 6/4/20 1:25 AM, Arvid Vermote wrote:

Hi Kathleen

Related to the below it would be helpful if the WebTrust organization would 
disclose additional details on the licensed WebTrust practitioners: right now 
there is no data publicly available on historical WebTrust auditor licensing. 
We don't know as of when an auditor has been licensed and as far as I am aware 
there is no overview of auditors that did not renew, withdrew or had their 
license revoked. Having such a list would certainly help CAs in the auditor 
selection process and better monitoring of auditor qualifications.

The Dutch NAB has an excellent inventory of their suspensions and withdrawals 
of accreditations: 
https://www.rva.nl/en/accredited-organisations/suspended-withdrawals. We think 
everyone would benefit from the WebTrust task force / CPA Canada maintaining a 
similar public inventory.

Thanks

Arvid



Hi Arvid,

Your message has been forwarded to WebTrust and CPA Canada folks.

Thanks,
Kathleen

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009

[Kathleen Wilson via dev-security-policy]

On 6/4/20 11:17 AM, Ben Wilson wrote:

Having received no further comments, I have recommended approval of this
request in bug 1445364


- Ben




To clarify, Ben is recommending approval of the request to include the 
e-Szigno Root CA 2017 certificate and enable the websites trust bit.


However, he has recommended that we deny the request for EV treatment 
for both root certificates. Microsec may re-apply by filing a new 
request for EV treatment after they have demonstrated improved 
compliance with the BRs and EV Guidelines.


Reference: 
https://groups.google.com/d/msg/mozilla.dev.security.policy/rHTmKOzspCo/yLTkQ25uAAAJ


Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Verifying Auditor Qualifications

[Kathleen Wilson via dev-security-policy]

All,

It recently came to my attention that I need to be more diligent in 
verifying auditor qualifications. Therefore, we have added a field in 
the CCADB called “Date Qualifications Verified” (on Auditor Location 
objects), which will be used to remind root store operators to check 
each auditor’s qualifications every year. This field can only be edited 
by a root store operator, and we will enter this date whenever we 
confirm that the auditor is still qualified to perform ETSI or WebTrust 
audits.


Some of you may notice that your Audit Case or Root Inclusion Case has 
the message: “Auditor Verification Date is blank”. This warning message 
is intended to remind root store operators that we need to verify the 
auditor's qualifications. In the future you may also notice a warning 
message when the date in that field is over a year old, reminding us 
root store operators to re-verify the auditor's qualifications.


I will greatly appreciate your input on the following new wiki page 
section, especially in regards to verifying auditor qualifications.


https://wiki.mozilla.org/CA/Audit_Statements#Auditor_Qualifications

Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DRAFT May 2020 CA Communication/Survey

[Kathleen Wilson via dev-security-policy]

Based on the survey results, we (Ben and I) have recommended the 
following updates to the Browser Alignment Ballot. (currently in draft 
form here:  https://github.com/sleevi/cabforum-docs/pull/10)


1) For the following changes proposed in the ballot, we have recommended 
that the effective date be on September 30, 2020.


- OCSP requirements (OCSP must be supported, validity interval for OCSP 
response more explicitly defined, revocationReason required)

- CRL updates (reasonCode required)
-- The change regarding the OCSP and CRL updates is already in progress 
here:

https://github.com/sleevi/cabforum-docs/commit/1e59ed6bc3f1411b28ecafc3ee41b293903cd755

- Certificate Policies (MUST contain at least one CA/Browser Forum 
defined-policy OID.)

-- This change is already in progress here:
https://github.com/sleevi/cabforum-docs/commit/80ea02a31b29d614b843d119a6c022652840c806

- Name Encoding Rules (Byte-for-byte Identical Issuer and Subject 
Distinguished Names)

-- This change is already in progress here:
https://github.com/sleevi/cabforum-docs/commit/91125b8fbc1b56abea7783f63b915ba09ca799de


2) Restrict the second part of the Name Encoding Rules (Byte-for-byte 
Identical Issuer and Subject Distinguished Names) changes to subCAs.

-- This change is already in progress here:
https://github.com/sleevi/cabforum-docs/commit/91125b8fbc1b56abea7783f63b915ba09ca799de


3) (No Change, just explanation) Mozilla’s approach to adding the 
certificate validity period reduction to our root store policy would 
normally have included a public discussion in 
mozilla.dev.security.policy. In the survey, CAs all indicated that they 
will be following this new requirement anyways for compatibility 
reasons. So we are OK with it remaining in this ballot.



Any further discussion about the Browser Alignment Ballot should 
continue in the CA/Browser Forum Server Certificate Working Group or in 
GitHub.


Thanks,
Kathleen

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Audit Reminders for Intermediate Certs

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of June 2020 Outdated Audit Statements for Intermediate 
Certs

Date:   Tue, 2 Jun 2020 14:00:11 + (GMT)

intermediate certs chaining up to root certs in Mozilla's program.>




___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DRAFT May 2020 CA Communication/Survey

[Kathleen Wilson via dev-security-policy]

Thank you to all of you who responded to the May 2020 CA 
Communication/Survey.


Communication/Survey:
https://wiki.mozilla.org/CA/Communications#May_2020_CA_Communication

Blog Post:
https://blog.mozilla.org/security/2020/05/08/may-2020-ca-communication/

Responses:
https://wiki.mozilla.org/CA/Communications#May_2020_Responses

Summary of Results:

* Item 1 -- Impact of COVID-19 Restrictions
Everyone responded with: "We have reviewed 
https://wiki.mozilla.org/CA/Audit_Statements#Audit_Delay and understand 
the action to take if we need to report issues to Mozilla."


* Item 2 -- Mozilla Root Store Policy version 2.7 Requirements and Deadlines
Most CAs responded with: "Our responses to the January 2020 CA 
Communication have not changed, and we will meet these requirements 
according to the dates we previously specified."
Some CAs indicated the work that they are still doing. I did not notice 
any alarming responses.


* Item 3 -- Reducing Maximum Validity Period for TLS Certificates

** Sub Item 3.1 -- Limit TLS Certificates to 398-day validity
(https://github.com/mozilla/pkipolicy/issues/204)
Most CAs who are issuing TLS certificates indicated their intent to 
limit TLS certificate validity period to 398 days or less for 
certificates issued after September 1, 2020.
Some CAs are already issuing TLS certs with shorter validity periods, 
and others indicated that they would be able to implement shorter 
validity periods by the date Mozilla specifies in its policy.
Many CAs voiced discontent with the way this requirement came about. To 
quote one CA: "Root programs should not place binding requirements on 
CAs via email messages without corresponding root policy updates, or at 
a minimum, a blog or announcement that can be referenced as a an 
authoritative trusted source."


** Sub Item 3.2 -- Limit re-use of domain name and IP address 
verification to 398 days

(https://github.com/mozilla/pkipolicy/issues/206)
19 CAs responded that they either do not re-use domain verification, or 
that their re-use of domain verification is already less than 398 days.
11 CAs indicated that they could implement the changes to their 
processes and documentation to limit the re-use of domain name 
verification to 398 days or less before 2020 Sep 30, 2020
9 CAs shared the sentiment that they would prefer that the re-use of 
verification information be regulated by the CA/Browser Forum Baseline 
Requirements.
A few CAs indicated that this requirement would cause extra work for 
their customers, and requested a detailed security analysis of this 
change which they could convey to their customers.
One CA noted: "If there is a change to reuse requirements, it should 
only apply to data verified on or after the effective date of the 
change. This change should not apply to data verified before the 
effective date of the change to avoid creating a verification cliff for 
the CAs and Subscribers. Note, if Mozilla requires that a domain name or 
IP address is re-verified each time a TLS certificate is issued, then 
this will reduce the effectivity of a number of verification 
methodologies that can be used and could impact many ecosystems which 
rely on TLS."


* Item 4 -- CA/Browser Forum Ballot for Browser Alignment

** Sub Item 4.1 -- CA/Browser Forum defined-policy OID in Subscriber 
Cert certificatePolicies

(https://github.com/mozilla/pkipolicy/issues/212)
With the exception of one CA, every CA that is issuing TLS certs 
responded that they either already do this, or can do this by September 
30, 2020.


** Sub Item 4.2 -- Byte-for-byte Identical Issuer and Subject 
Distinguished Names

(https://github.com/mozilla/pkipolicy/issues/213)
Most CAs already do this, but a few CAs indicated that they would need 
some time for further analysis and making changes which appear do-able 
for future cert issuance.
Note: I would not want this to cause lots of revocations of existing 
certs, so prefer a future effective date.


A couple CAs indicated that the second part of the requirement should be 
restricted to subCAs.

Note: This change is already under consideration per discussion in the CABF.

** Sub Item 4.3 -- Text-searchable PDF Audit Statements
(https://github.com/mozilla/pkipolicy/issues/210)
All CAs indicated that either they already do this, or that they can do 
this for their next audits.


** Sub Item 4.4 -- OCSP Requirements
(https://github.com/mozilla/pkipolicy/issues/211)
All CAs indicated that they either already do this, or can do this by 
September 2020. (Note that one CA said October 14, 2020)



Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Audit Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of May 2020 Audit Reminder Emails
Date: Tue, 19 May 2020 19:00:17 + (GMT)


Mozilla: Audit Reminder
CA Owner: Global Digital Cybersecurity Authority Co., Ltd. (Formerly 
Guang Dong Certificate Authority (GDCA))

Root Certificates:
   GDCA TrustAUTH R5 ROOT
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=229546

Standard Audit Period End Date: 2019-02-28
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=229547

BR Audit Period End Date: 2019-02-28
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=229548

EV Audit Period End Date: 2019-02-28
CA Comments: null



Mozilla: Audit Reminder
CA Owner: LuxTrust
Root Certificates:
   LuxTrust Global Root 2
Standard Audit: 
https://www.lsti-certification.fr/images/LSTI_Audit_Atttestation_Letter_11085-124_V10.pdf

Standard Audit Period End Date: 2019-03-29
BR Audit: 
https://www.lsti-certification.fr/images/LSTI_Audit_Atttestation_Letter_11085-124_V10.pdf

BR Audit Period End Date: 2019-03-29
EV Audit: 
https://www.lsti-certification.fr/images/LSTI_Audit_Atttestation_Letter_11085-124_V10.pdf

EV Audit Period End Date: 2019-03-29
CA Comments: null



Mozilla: Audit Reminder
CA Owner: SK ID Solutions AS
Root Certificates:
   EE Certification Centre Root CA
Standard Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019051701_SK_EE_Certification_Centre_Root_CA_s.pdf

Standard Audit Period End Date: 2019-03-01
BR Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019051701_SK_EE_Certification_Centre_Root_CA_s.pdf

BR Audit Period End Date: 2019-03-01
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Autoridad de Certificacion Firmaprofesional
Root Certificates:
   Autoridad de Certificacion Firmaprofesional CIF A62634068
Standard Audit: 
https://www.aenor.com/Certificacion_Documentos/eiDas/2019%20AENOR%20Anexo%202%20ETSI%20319%20411-1%20PSC-FP_v4%20c.pdf

Standard Audit Period End Date: 2019-03-27
BR Audit: 
https://www.aenor.com/Certificacion_Documentos/eiDas/2019%20AENOR%20Anexo%202%20ETSI%20319%20411-1%20PSC-FP_v4%20c.pdf

BR Audit Period End Date: 2019-03-27
EV Audit: 
https://www.aenor.com/Certificacion_Documentos/eiDas/2019%20AENOR%20Anexo%202%20ETSI%20319%20411-1%20PSC-FP_v4%20c.pdf

EV Audit Period End Date: 2019-03-27
CA Comments: null



Mozilla: Audit Reminder
CA Owner: AC Camerfirma, S.A.
Root Certificates:
   Chambers of Commerce Root
   Chambers of Commerce Root - 2008
   Global Chambersign Root
   Global Chambersign Root - 2008
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=230425

Standard Audit Period End Date: 2019-04-13
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8995930
BR Audit Period End Date: 2018-04-13
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=9072794
BR Audit Period End Date: 2019-03-28
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=236204

BR Audit Period End Date: 2019-04-13
EV Audit: https://bugzilla.mozilla.org/attachment.cgi?id=9072794
EV Audit Period End Date: 2019-03-28
CA Comments: null



Mozilla: Overdue Audit Statements
CA Owner: certSIGN
Root Certificates:
   certSIGN ROOT CA**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=229553

Standard Audit Period End Date: 2019-02-08
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=229551

BR Audit Period End Date: 2019-02-08
CA Comments: Audit statements provided, waiting for Seals to be provided 
by CPA Canada.




Mozilla: Audit Reminder
CA Owner: Sectigo
Root Certificates:
   COMODO RSA Certification Authority
   USERTrust ECC Certification Authority
   AAA Certificate Services
   AddTrust Class 1 CA Root
   AddTrust External CA Root
   COMODO Certification Authority
   COMODO ECC Certification Authority
   USERTrust RSA Certification Authority
Standard Audit: 
https://bug1472993.bmoattachments.org/attachment.cgi?id=9078178

Standard Audit Period End Date: 2019-03-31
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=231163

BR Audit Period End Date: 2019-03-31
BR Audit:
BR Audit Period End Date:
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=231164

EV Audit Period End Date: 2019-03-31
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert)
Root Certificates:
   EC-ACC
Standard Audit: 
https://www.aenor.com/Certificacion_Documentos/eiDas/2019%20AENOR%20Anexo%202%20ETSI%20319%20411-2%20PSC-CAOC_v4.pdf

Standard Audit Period End Date: 2019-03-28
BR Audit: 
https://www.aenor.com/Certificacion_Documentos/eiDas/2019%20AENOR%20Anexo%202%20ETSI%20319%20411-1%20PSC-CAOC_v4.pdf

Re: DRAFT May 2020 CA Communication/Survey

[Kathleen Wilson via dev-security-policy]

On 5/7/20 11:33 AM, Kathleen Wilson wrote:

 > I have drafted a potential CA Communication and survey, and will greatly
 > appreciate your input on it.
 >
 > https://wiki.mozilla.org/CA/Communications#May_2020_CA_Communication
 >
 > Direct link to read-only copy of the draft survey:
 > 
https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J42AUSv 




I believe that all of the questions/concerns have been resolved, so I 
will open up the survey now, and prepare to send the email to the CAs 
about it.



Thanks,
Kathleen



The email has been sent to the Primary POC (cc'd the CA's email alias) 
for each CA with a root cert currently in Mozilla's root store.


Blog post:
https://blog.mozilla.org/security/2020/05/08/may-2020-ca-communication/

Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Audit Reminders for Intermediate Certs

[Kathleen Wilson via dev-security-policy]

On 5/6/20 5:19 AM, Ryan Sleevi wrote:

Should we be creating CA incidents for repeats? I wasn’t sure if this was
just an administrative hiccup on the Mozilla side in processing the case,
or if this is a matter where the CA is not disclosing in a timely fashion.



CAs directly add audit information to intermediate certificate records 
in the CCADB, so there is no dependency on the Mozilla side for this.


https://wiki.mozilla.org/CA/Email_templates#Outdated_Audit_Statements_for_Intermediate_Certificates
"This email is automatically sent by the CCADB on the first Tuesday of 
each month to CAs who have outdated audit statements in their 
intermediate cert records. An audit statement is determined to be 
outdated when its Audit Period End Date is older than 1 year + 3 months."


Last year I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1549861 
regarding Camerfirma not providing updated audit statements for their 
subCAs.


This year Camerfirma received one notice for the outdated audit 
statement for an intermediate cert, before they fixed it.


I didn't post the "Summary of April 2020 Outdated Audit Statements for 
Intermediate Certs" here in m.d.s.p, because it was empty. But perhaps I 
should post those empty summaries as well.


Anyways, my preference is to file a CA incident bug whenever a CA 
receives more than one of these "Outdated Audit Statements for 
Intermediate Certs" reminders for consecutive months.


Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DRAFT May 2020 CA Communication/Survey

[Kathleen Wilson via dev-security-policy]

> I have drafted a potential CA Communication and survey, and will greatly
> appreciate your input on it.
>
> https://wiki.mozilla.org/CA/Communications#May_2020_CA_Communication
>
> Direct link to read-only copy of the draft survey:
> 
https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J42AUSv 




I believe that all of the questions/concerns have been resolved, so I 
will open up the survey now, and prepare to send the email to the CAs 
about it.



Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Audit Reminders for Intermediate Certs

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of May 2020 Outdated Audit Statements for Intermediate 
Certs

Date: Tue, 5 May 2020 14:00:08 + (GMT)


CA Owner: SECOM Trust Systems CO., LTD.
   - Certificate Name: SECOM Passport for Web MH CA
SHA-256 Fingerprint: 
4E62A252592F9D71FFE2037757F855D4A0235D6638BD105E9EF17086CE2BBC25

Standard Audit Period End Date (mm/dd/): 01/29/2019
BR Audit Period End Date (mm/dd/): 01/29/2019

   - Certificate Name: FujiSSL Public Validation Authority - G3
SHA-256 Fingerprint: 
56DA6EFEF1D504134C72EEDC3AE44AA7FA11B848820DBFAA86CA8E35D60EDB04

Standard Audit Period End Date (mm/dd/): 01/29/2019
BR Audit Period End Date (mm/dd/): 01/29/2019

   - Certificate Name: CrossTrust DV CA5
SHA-256 Fingerprint: 
18F4368FE93B3CAE025230BCE7EAD340FD90FB27F9A10E36FEE89FC454F22788

Standard Audit Period End Date (mm/dd/): 01/29/2019
BR Audit Period End Date (mm/dd/): 01/29/2019

   - Certificate Name: CrossTrust OV CA5
SHA-256 Fingerprint: 
79C4091B05B15C1683128B7A355E0AAD62E1BBBC3E5F3735370C06CC4D1AFB44

Standard Audit Period End Date (mm/dd/): 01/29/2019
BR Audit Period End Date (mm/dd/): 01/29/2019

   - Certificate Name: EINS/PKI Public Certification Authority V4
SHA-256 Fingerprint: 
38B26CF45C932EA28019D93E440AC72BAE83F9CBF52D6AD913698B18FCC8717D

Standard Audit Period End Date (mm/dd/): 01/29/2019
BR Audit Period End Date (mm/dd/): 01/29/2019

   - Certificate Name: KDDI Web Communications Certification Authority 3
SHA-256 Fingerprint: 
2B30D5E912906358C9AD6FB57FD7B368A01A78E395B4EC11645C5B98A0967DE8

Standard Audit Period End Date (mm/dd/): 01/29/2019
BR Audit Period End Date (mm/dd/): 01/29/2019



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DRAFT May 2020 CA Communication/Survey

[Kathleen Wilson via dev-security-policy]

On 5/4/20 9:31 AM, Corey Bonnell wrote:

Thank you very much for the clarifications. If I'm understanding correctly, it
sounds like Mozilla is considering to add sub-items of item 4 on the survey as
Mozilla Root Program requirements if the associated CAB Forum ballot does not
pass. However, there is concern that many CAs may not be compliant with these
requirements, so the purpose of the survey is to gauge potential impact to CAs
so that effective dates can be set such that CAs can react appropriately as
well as to gather data to better inform Mozilla's position in the CAB Forum.
Is that a correct assessment of the purpose of question 4?




Correct.

I created the issues in Github so these items get considered for 
Mozilla's policy in one form or other (direct, through BRs, or both).


Here is a breakdown of my perspective of the Browser Alignment Ballot 
(https://github.com/sleevi/cabforum-docs/pull/10) specifically in 
regards to Mozilla’s Root Store Policy.


Audit Reporting

- CAs should already be following all but one of the additions, because 
they are already part of section 3.1.4 of Mozilla’s Root Store Policy[1] 
and section 5.1 of the CCADB Policy[2].


- I filed https://github.com/mozilla/pkipolicy/issues/210 for the 
requirement that would be new to Mozilla policy: “CCADB Policy: Require 
audit statements to be text-searchable PDF”

(SUB ITEM 4.3 in the May 2020 CA Communication/Survey.)

OCSP

- I filed https://github.com/mozilla/pkipolicy/issues/211 to consider 
updating section 6 of Mozilla’s Root Store Policy: “Require OCSP and 
Reduce OCSP response max validity from 10 days to 7 days”

(SUB ITEM 4.4 in the May 2020 CA Communication/Survey.)

- Mozilla may propose in the CABF that the other three items in this 
section be removed from the ballot (fresh OCSP responses at one-half of 
validity interval, must contain revocationReason, must not contain a 
reasonCode singleExtension).


CRLs

- Mozilla may propose in the CABF that these changes be removed from the 
ballot (reasonCode requirements for intermediate cert revocations). I 
don't see a reason for Mozilla to require this or enforce such a rule.


Certificate Policies

- I filed https://github.com/mozilla/pkipolicy/issues/212 to consider 
updating Mozilla’s Root Store Policy if this doesn’t get added to the 
BRs: “Require at least one CABF defined-policy OID in 
certificatePolicies extension for TLS certs”

(SUB ITEM 4.1 in the May 2020 CA Communication/Survey.)


Authority Key ID

- CAs should already be following this item because it is already part 
of RFC 5280 and section 5.2 of Mozilla’s Root Store Policy. (RFC 5280: 
authorityKeyIdentifier MUST be present and MUST contain a keyIdentifier, 
Mozilla Policy: “CAs MUST NOT issue certificates that have … authority 
key IDs that include both the key ID and the issuer’s issuer name and 
serial number”)


Extended Key Usage

- CAs should already be following this item because it is already part 
of section 5.3 of Mozilla’s Root Store Policy.


Name Encoding Rules

- I filed https://github.com/mozilla/pkipolicy/issues/213 to consider 
updating Mozilla’s Root Store Policy even if this does get added to the 
BRs: “Require Byte-for-byte Identical Issuer and Subject Distinguished 
Names”

(SUB ITEM 4.2 in the May 2020 CA Communication/Survey.)

CP/CPS

- CAs should already be following this item because it is already in 
section 3.3 of Mozilla’s Root Store Policy.


Key Algorithms and Sizes

- CAs should already be following this item because it is already in 
section 5 of Mozilla’s Root Store Policy.


Signature Algorithms

- These clarifications were added to section 5 of Mozilla’s Root Store 
Policy in version 2.7, with an effective date of January 1, 2020.


Certificate Lifetimes

 - https://github.com/mozilla/pkipolicy/issues/204
(ITEM 3 in the May 2020 CA Communication/Survey.)

Clarify Effective Dates

- This is a clarification that seems reasonable, and does not require 
action.



Thanks,
Kathleen

[1] 
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy

[2] https://www.ccadb.org/policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DRAFT May 2020 CA Communication/Survey

[Kathleen Wilson via dev-security-policy]

On 5/1/20 10:18 AM, Corey Bonnell wrote:



I agree that the intent of item 3 is clear, given the previous discussion on
the topic [1]. However, there is no corresponding discussion on the Mozilla
list (nor any Github issues [2]) for item 4 and the associated sub-items,
which is why I asked for clarification on intent.

Thanks,
Corey



Do you think it would be useful for me to file issues in GitHub for each 
of those requirements in the draft ballot and label them for 
consideration in v2.7.1 of Mozilla's Root Store Policy?


Such issues could be closed without discussion in m.d.s.p if the CABF 
ballot includes them and passes.


I see pros and cons about doing this (filing the Github issues), but am 
not opposed to it if you think it would help.


Thanks,
Kathleen



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DRAFT May 2020 CA Communication/Survey

[Kathleen Wilson via dev-security-policy]

On 5/1/20 9:48 AM, Corey Bonnell wrote:

Hi Kathleen,
Thank you for sending out this notification of the draft survey. I have briefly 
reviewed and would like to ask what is the intent of Item 4 and the associated 
sub-items? The Browser Alignment draft ballot is under discussion in the CAB 
Forum, so the intent behind the shift of the location of discourse to the 
Mozilla forum is unclear.

Thanks,
Corey



Hi Corey,

We do not intend to shift the location of the discourse.

The intent of Item 4 and the associated sub-items in our survey is to 
help Mozilla with the specific questions/concerns that we have about the 
ballot, so that we can use input from CAs in our program to recommend 
changes to the draft. It is relatively easy to tack our questions about 
this draft ballot onto our CA Communication/survey, and the results will 
give us the data we are currently lacking.


Currently some of my concerns about the draft of the ballot have no data 
behind them. While I think it is good to add many of those items in the 
ballot to the BRs, I am concerned about the effective dates of 
"immediately" or "Sept 1". I don't want to end up with a bunch of cert 
revocations caused by effective dates that should have been changed 
while the ballot was in draft form. I also don't want to see the entire 
ballot fail just because we didn't have the data to reasonably update 
the draft of the ballot.


Note: There are some items in the ballot that we (Mozilla) might request 
be removed, but that input will be provided by Mozilla's CABF 
representatives (Ben and Wayne) directly into the CABF discussion forum.


I will greatly appreciate your thoughts on how to better ask the 
questions in item 4 of our survey, to clarify our intent, and be able to 
get the data that we seek.


Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

DRAFT May 2020 CA Communication/Survey

[Kathleen Wilson via dev-security-policy]

All,

I have drafted a potential CA Communication and survey, and will greatly 
appreciate your input on it.


https://wiki.mozilla.org/CA/Communications#May_2020_CA_Communication

Direct link to read-only copy of the draft survey:
https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J42AUSv

Purpose:
- Communicate Mozilla's expectations about what CAs should do when 
audits, revocations, or other requirements are impacted by COVID-19 
restrictions.

- Remind CAs about deadlines in version 2.7 of Mozilla’s Root Store Policy.
- Collect CA input on limiting TLS cert lifetimes.
- Collect CA input on the draft CA/Browser Forum Browser Alignment Ballot.

Thanks,
Kathleen

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Audit Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of April 2020 Audit Reminder Emails
Date: Tue, 21 Apr 2020 19:00:09 + (GMT)


Mozilla: Audit Reminder
CA Owner: Global Digital Cybersecurity Authority Co., Ltd. (Formerly 
Guang Dong Certificate Authority (GDCA))

Root Certificates:
   GDCA TrustAUTH R5 ROOT
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=229546

Standard Audit Period End Date: 2019-02-28
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=229547

BR Audit Period End Date: 2019-02-28
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=229548

EV Audit Period End Date: 2019-02-28
CA Comments: null



Mozilla: Audit Reminder
CA Owner: SK ID Solutions AS
Root Certificates:
   EE Certification Centre Root CA
Standard Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019051701_SK_EE_Certification_Centre_Root_CA_s.pdf

Standard Audit Period End Date: 2019-03-01
BR Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019051701_SK_EE_Certification_Centre_Root_CA_s.pdf

BR Audit Period End Date: 2019-03-01
CA Comments: null



Mozilla: Audit Reminder
CA Owner: certSIGN
Root Certificates:
   certSIGN ROOT CA
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=229553

Standard Audit Period End Date: 2019-02-08
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=229551

BR Audit Period End Date: 2019-02-08
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Cybertrust Japan / JCSI
Root Certificates:
   SecureSign RootCA11**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=229662

Standard Audit Period End Date: 2019-02-28
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=229661

BR Audit Period End Date: 2019-02-28
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Entrust
Root Certificates:
   Entrust Root Certification Authority - EC1
   Entrust Root Certification Authority - G2
   Entrust Root Certification Authority - G4
   AffirmTrust Commercial
   AffirmTrust Networking
   AffirmTrust Premium
   AffirmTrust Premium ECC
   Entrust Root Certification Authority
   Entrust.net Certification Authority (2048)
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=230012

Standard Audit Period End Date: 2019-02-28
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=230013

Standard Audit Period End Date: 2019-02-28
BR Audit: 
https://www.entrustdatacard.com/-/media/documentation/licensingandagreements/ecs/2019-entrust-baseline-requirements-report.pdf

BR Audit Period End Date: 2019-02-28
BR Audit: 
https://www.affirmtrust.com/wp-content/uploads/2019-AFT-Baseline-Requirements-report.pdf

BR Audit Period End Date: 2019-02-28
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=230012

EV Audit Period End Date: 2019-02-28
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=230013

EV Audit Period End Date: 2019-02-28
CA Comments: null



Mozilla: Overdue Audit Statements
CA Owner: Trustis
Root Certificates:
   Trustis Limited - Trustis FPS Root CA**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://bug1360184.bmoattachments.org/attachment.cgi?id=9047305

Standard Audit Period End Date: 2019-01-15
BR Audit: https://bug1360184.bmoattachments.org/attachment.cgi?id=9047305
BR Audit Period End Date: 2019-01-15
CA Comments: https://bugzilla.mozilla.org/show_bug.cgi?id=1623472



Mozilla: Audit Reminder
CA Owner: Asseco Data Systems S.A. (previously Unizeto Certum)
Root Certificates:
   Certum Trusted Network CA 2
   Certum CA
   Certum Trusted Network CA
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=234363

Standard Audit Period End Date: 2019-03-04
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=234364

BR Audit Period End Date: 2019-03-04
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=234365

EV Audit Period End Date: 2019-03-04
CA Comments: null




___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Welcome Ben Wilson to Mozilla!

[Kathleen Wilson via dev-security-policy]

All,

I am pleased to announce that Ben Wilson has joined Mozilla as a CA 
Program Manager!


Ben has worked in PKI security, compliance, and policy since 1998. 
Previously, he worked at DigiCert in various roles, including VP of PKI 
Operations, VP of Compliance, and Chair of DigiCert’s Policy Authority 
team to develop and communicate policies and practices for internal and 
external stakeholders. Ben has also been very involved in the CA/Browser 
Forum. He is a former Chair of the CA/Browser Forum and of the American 
Bar Association’s Information Security Committee. Over the years, Ben 
has also participated in this mozilla.dev.security.policy forum.


Here are some of the things that Ben will be responsible for:
+ Steps 3 through 9 of Mozilla’s root inclusion process[1], which 
includes the detailed CP/CPS reviews[2] and the public discussion phase[3]

+ CA Incident Bugs[4]
+ Updates to Mozilla’s Root Store Policy[5] and the Common CCADB 
Policy[6], including prioritizing potential changes[7] and leading 
discussions to determine the actual changes

+ Represent Mozilla in the CA/Browser Forum, along with Wayne

I have added Ben to the Policy_Participants wiki page[8], and updated 
Wayne's entry.


Welcome, Ben!

Thanks,
Kathleen

[1] https://wiki.mozilla.org/CA/Application_Process
[2] https://wiki.mozilla.org/CA/Application_Verification#Detailed_Review
[3] https://wiki.mozilla.org/CA/Application_Verification#Public_Discussion
[4] https://wiki.mozilla.org/CA/Incident_Dashboard
[5] 
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

[6] https://www.ccadb.org/policy
[7] https://github.com/mozilla/pkipolicy/issues
[8] https://wiki.mozilla.org/CA/Policy_Participants
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Auditing of CA facilities in lockdown because of an environmental disaster/pandemic

[Kathleen Wilson via dev-security-policy]

All,

Just FYI that I updated the CA Incident Dashboard wiki page to separate 
the audit delay bugs into their own section.


https://wiki.mozilla.org/CA/Incident_Dashboard#Audit_Delays

Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Auditing of CA facilities in lockdown because of an environmental disaster/pandemic

[Kathleen Wilson via dev-security-policy]

It's still very much a work-in-progress, but I updated the first bullet 
point in the "Minimum Expectations" section again.


https://wiki.mozilla.org/CA/Audit_Statements#Audit_Delay

""
Both ETSI and WebTrust Audits should:
- Disclose each location (at the state/province level) that was included 
in the scope of the audit or should have been included in the scope of 
the audit, whether the inspection was physically carried out in person 
at each location, and which audit criteria were checked (or not checked) 
at each location.
-- If the CA has more than one location in the same state/province, then 
use terminology to clarify the number of facilities in that 
state/province and whether or not all of them were audited. For example: 
"Facility 1 in Province", "Facility 2 in Province, Facility 3 in 
Province" or "Primary Facility in Province", "Secondary Facility in 
Province", "Tertiary Facility in Province".

""

TO DO: Clarify the types of CA locations that should be disclosed in the 
audit statement. e.g. data center locations, registration authority 
locations, where IT and business process controls of CA operations are 
performed, facility hosting an active HSM with CA private keys, facility 
or bank deposit box storing a deactivated and encrypted copy of a 
private key, other?


I will continue to appreciate your feedback on this, and the entire 
"Audit Delay" section.



I also filed an issue in GitHub regarding adding this to Mozilla's root 
store policy.

https://github.com/mozilla/pkipolicy/issues/207

Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: COVID-19 and CA Operational Status

[Kathleen Wilson via dev-security-policy]

All,

If Mozilla decides to ask each CA in our program these types of 
questions, we will do so via a CA Communication 
(https://wiki.mozilla.org/CA/Communications).


I appreciate Burton's curiosity, but your participation in this 
particular discussion thread is optional, and will not be considered to 
be your CA's response to an official Mozilla CA Communication and survey.


Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Auditing of CA facilities in lockdown because of an environmental disaster/pandemic

[Kathleen Wilson via dev-security-policy]

On 3/20/20 1:15 PM, Jeremy Rowley wrote:

What about issues other than audits? For example, with certain locations 
closing, key ceremonies may become impossible, leading to downed CRLs/OCSP for 
intermediates. There's also a potential issue with trusted roles even being 
able to access the data center if something goes down and Sub CAs can't be 
revoked. Should that be mentioned, requiring CAs to file an incident report as 
soon as the event becomes likely?




Good point.

I added the following to https://wiki.mozilla.org/CA/Incident_Dashboard
** If the issue is due to mandated restrictions regarding COVID-19, use 
Whiteboard = [ca-compliance][covid-19]



I updated https://wiki.mozilla.org/CA/Audit_Statements#Audit_Delay
to:
* Whiteboard = [ca-compliance][audit-delay]
* For audit delays due to mandated restrictions regarding COVID-19, use 
Whiteboard = [ca-compliance][audit-delay][covid-19]


Do you think we should also add a section to 
https://wiki.mozilla.org/CA/Responding_To_An_Incident about COVID-19?



Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Auditing of CA facilities in lockdown because of an environmental disaster/pandemic

[Kathleen Wilson via dev-security-policy]

All,

I will greatly appreciate your ideas about the following.

In the Minimum Expectations section in
https://wiki.mozilla.org/CA/Audit_Statements#Audit_Delay
I added:
""
* Both ETSI and WebTrust Audits must:
** Disclose each location that was included in the scope of the audit, 
as well as whether the inspection was physically carried out in person.

""

My question: What should "location" mean in the above requirement?

The problem is that we require public-facing audit statements, so I do 
not want sensitive or confidential information in the audit statements, 
such as the exact physical addresses of CA Operations and root cert 
private key storage.


What information could be added to audit statements to give us a clear 
sense about which CA facilities were and were not audited?


For example, if a CA happens to have two facilities in the same city 
that should be audited, how can the audit statement clearly indicate if 
all of that CA's facilities were audited without providing the exact 
physical addresses?


Thanks,
Kathleen



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Auditing of CA facilities in lockdown because of an environmental disaster/pandemic

[Kathleen Wilson via dev-security-policy]

On 3/18/20 5:16 PM, Ryan Sleevi wrote:

Suggestions:
1) Rename "Audit Delay" to [audit-delay] and rename "Audit Delay COVID-19"
to [audit-delay] [covid-19] or [audit-delay-covid-19], depending
Rationale: In general, our filters work on word searches, so the brackets
brackets help distinguish the two. To search for "Audit Delay" without
considering COVID-19, the filter would have to be ("Audit" AND "Delay") AND
NOT "COVID-19". The renames help us search for "[audit-delay]" (which would
exclude Covid-19) or "[audit-delay]" AND NOT "[covid-19]", which is...
slightly easier :) This is mostly minor, but also tracks how we handled
[ca-compliance], [auditor-compliance], [delayed-revocation-leaf] and
[delayed-revocation-ca] :)


Done



2) Rename "Potential remediations" to "Minimum expectations"
Rationale: I worry that "potential remediations" may be seen as an
indefinite escape clause. As noted in the discussion of force majeure that
you've linked, in general, these clauses generally temporarily suspend
certain obligations, but may not indefinitely apply. While this situation
continues to evolve, and we will hopefully see a timely global recovery,
there exists the non-negligible possibility that it may become necessary at
some point in the future to limit or restrict trust in CAs in order to
minimize risk to users. These are absolutely case-by-case scenarios, and so
this isn't meant to scare CAs or Auditors into engaging in unsafe or risky
procedures, but more to highlight that as part of recovery from such
scenarios, it may be necessary to figure out how to transition from
uncertainy to certainty, such as rolling keys over to new
roots/intermediates. Keeping people physically safe is certainly the
pressing priority here, and we should be sensitive to that, but I worry
that "potential remediations" suggests that such measures might be
indefinitely accepted.


Done



3) Clarify ETSI documentation and disclosure requirements
Rationale: My concern with the ETSI approach is that Mozilla may not
receive the same information the auditor/CAB provides to the CA/TSP. For
example, as currently worded, it'd be impossible to discover the
limitations that the auditor might have encountered (such as a
documentation-only assessment), because that'd be normally addressed in the
engagement letter between the CAB/TSP, and beyond them, typically only the
Supervisory Body would be party to such details. While your requirements
for disclosure are unambiguous, my worry is how many TSPs/CABs using an
ETSI scheme have failed to uphold Mozilla's expectations / CCADB
expectations, and thus it wouldn't be clear when a TSP was violating policy
(e.g. by not having disclosed the situation).

Potentially: "Audit letters MUST disclose each location that was included
in the scope of the audit, as well as whether the inspection was physically
carried out in person"

There's probably a MUCH better way to word this, but the concept I'm trying
to capture is some positive affirmation by the auditor about what they did.
If a Letter doesn't include that, it's a red flag (to reject the audit). If
it does, that at least provides clarity and fits back in to the incident
report discussion.



Added the following to the top of the "Minimum Expectations" list:
* Both ETSI and WebTrust Audits must:
** Disclose each location that was included in the scope of the audit, 
as well as whether the inspection was physically carried out in person.


This way we can easily add more sub-bullet points as needed.


I also added a summary to the top of the page
https://wiki.mozilla.org/CA/Audit_Statements
CA Audits are one of the primary mechanisms relied upon by Mozilla to 
ensure that a CA is operating securely and in compliance with our 
policies. CA audits and audit statements must comply with the following 
requirements.

* Section 3.1 of Mozilla's Root Store Policy.
** An Audit Delay is when one or more of the following requirements in 
section 3.1.3 cannot be met:
***"Full-surveillance period-of-time audits MUST be conducted and 
updated audit information provided no less frequently than annually."
***"... MUST be provided to Mozilla via the CCADB within three months of 
the point-in-time date or the end date of the period."

* Section 5.1 of the Common CCADB Policy.
* Section 8 of the CA/Browser Forum Baseline Requirements, if the root 
certificate has the Websites (TLS/SSL) trust bit enabled.



Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Auditing of CA facilities in lockdown because of an environmental disaster/pandemic

[Kathleen Wilson via dev-security-policy]

All,

I will greatly appreciate your input on the following new "Audit Delay" 
section.


https://wiki.mozilla.org/CA/Audit_Statements#Audit_Delay

Thanks,
Kathleen

PS: I moved the content of
https://wiki.mozilla.org/CA/Audit_Letter_Validation
to
https://wiki.mozilla.org/CA/Audit_Statements
(with a redirect from the old page)


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Audit Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of March 2020 Audit Reminder Emails
Date: Tue, 17 Mar 2020 19:00:22 + (GMT)

Mozilla: Audit Reminder
CA Owner: Government of The Netherlands, PKIoverheid (Logius)
Root Certificates:
   Staat der Nederlanden EV Root CA
   Staat der Nederlanden Root CA - G3
   Staat der Nederlanden Root CA - G2
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=224596

Standard Audit Period End Date: 2018-12-31
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=224597

BR Audit Period End Date: 2018-12-31
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=9119053
BR Audit Period End Date: 2018-12-31
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=224598

EV Audit Period End Date: 2018-12-31
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Krajowa Izba Rozliczeniowa S.A. (KIR)
Root Certificates:
   SZAFIR ROOT CA2
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=226440

Standard Audit Period End Date: 2018-12-18
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=226441

BR Audit Period End Date: 2018-12-18
CA Comments: null



Mozilla: Audit Reminder
CA Owner: certSIGN
Root Certificates:
   certSIGN ROOT CA
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=229553

Standard Audit Period End Date: 2019-02-08
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=229551

BR Audit Period End Date: 2019-02-08
CA Comments: null



Mozilla: Audit Reminder
CA Owner: QuoVadis
Root Certificates:
   QuoVadis Root CA 1 G3
   QuoVadis Root CA 2
   QuoVadis Root CA 2 G3
   QuoVadis Root CA 3
   QuoVadis Root CA 3 G3
   QuoVadis Root Certification Authority
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=227627

Standard Audit Period End Date: 2018-12-31
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=227628

BR Audit Period End Date: 2018-12-31
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=227629

EV Audit Period End Date: 2018-12-31
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Taiwan-CA Inc. (TWCA)
Root Certificates:
   TWCA Global Root CA**
   TWCA Root Certification Authority**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=225350

Standard Audit Period End Date: 2018-12-31
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=225502

BR Audit Period End Date: 2018-12-31
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=225503

EV Audit Period End Date: 2018-12-31
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Trustis
Root Certificates:
   Trustis Limited - Trustis FPS Root CA**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://bug1360184.bmoattachments.org/attachment.cgi?id=9047305

Standard Audit Period End Date: 2019-01-15
BR Audit: https://bug1360184.bmoattachments.org/attachment.cgi?id=9047305
BR Audit Period End Date: 2019-01-15
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Government of Spain, Fábrica Nacional de Moneda y Timbre (FNMT)
Root Certificates:
   FNMT-RCM - SHA256
Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=9057798
Standard Audit Period End Date: 2019-01-12
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=9057798
BR Audit Period End Date: 2019-01-12
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Amazon Trust Services
Root Certificates:
   Amazon Root CA 3
   Amazon Root CA 2
   Starfield Services Root Certificate Authority - G2
   Amazon Root CA 1
   Amazon Root CA 4
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=227776

Standard Audit Period End Date: 2019-01-15
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=22

BR Audit Period End Date: 2019-01-15
EV Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=227778

EV Audit Period End Date: 2019-01-15
CA Comments: null




___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: About upcoming limits on trusted certificates

[Kathleen Wilson via dev-security-policy]

Thanks to all of you who have participated in this discussion. We plan 
to begin work on a minor update (version 2.7.1) to Mozilla's Root Store 
Policy soon. In response to this discussion, the following two issues 
have been created and labelled for 2.7.1.


Wayne filed https://github.com/mozilla/pkipolicy/issues/204
"Limit TLS Certificates to 398 day validity after Aug 31, 2020"

And I filed https://github.com/mozilla/pkipolicy/issues/206
"Limit re-use of domain name verification to 395 days"
which says:
"When we update Mozilla's Root Store Policy to limit TLS certificate 
validity periods to 398 days, we should also update the policy to limit 
re-use of domain name verification results.
I started discussion about this in m.d.s.p, and consensus appears to 
support the idea, with the two primary recommendations:
- Change the effective date to April 2021 to give CAs time to update 
their processes.
- Provide a Mozilla Security Blog explaining the reasons for making this 
change. The idea being to provide one place where people can go to read 
about why it is important to frequently re-verify domain name ownership 
and why it is important to reduce TLS cert validity periods."



Thanks,
Kathleen


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: About upcoming limits on trusted certificates

[Kathleen Wilson via dev-security-policy]

On 3/14/20 11:53 AM, Nick Lamb wrote:

On Thu, 5 Mar 2020 14:15:17 +
Nick Lamb via dev-security-policy
 wrote:


Would Mozilla
accept third party work to implement something like #908125 ? 



Hi Nick,

I apologize for my delay in replying to your question. I checked with 
the Crypto Engineering team, and it turns out that they do have a plan 
for addressing this bug. It sounds like the work will also include other 
considerations such as configurability and testing.


Thanks,
Kathleen



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: About upcoming limits on trusted certificates

[Kathleen Wilson via dev-security-policy]

On 3/12/20 5:52 AM, Doug Beattie wrote:


Changing the domain validation re-user period is a substantial change from the Apple proposed max validity period change and will place an additional burden on certificate Applicants to update their domain validation more than twice as frequently. 



Please elaborate about why re-verifying the domain name ownership is 
difficult for the CA who is issuing the renewal TLS cert.
Or why the TLS certificate Applicant will face undue burden if they have 
to prove domain name ownership when they renew their TLS cert to replace 
the cert that was issued a year ago.


Or, is your concern about the date?
e.g. aligning the change with the date that Apple chose of September 1, 
2020 for the one-year validity period?
I am not set on any particular date, so long as we are making forward 
progress. So if the concern is about the date, please suggest 
alternatives for when it would be reasonable to require CAs to re-verify 
that the certificate Applicant still owns the domain name to be included 
in their TLS cert to replace the cert that was issued a year ago.




Certificate validity and domain validation re-use periods don’t necessarily 
need to be tied to the same value, so having certificate validity capped at 398 
days and domain re-use set at 825 days isn’t contradictory.



BygoneSSL explains why domain ownership validation should be done more 
frequently:


https://insecure.design/
""
This is the demo site for BygoneSSL. It outlines what can happen when a 
SSL certificate can outlive one of its domains' ownerships into the next.

Why is this a problem?
Well, aside from the fact that the previous domain owner could 
Man-in-the-Middle the new domain owner's SSL traffic for that domain, if 
there are any domains that share alt-names with the domain, they can be 
revoked, potentially causing a Denial-of-Service if they are still in use.

""



Can you also provide, in a blog or a publicly posted article, the reasons for 
shortening the certificate validity?  There are hundreds of comments and 
suggestions in multiple mail lists, but there is a lack of a documented formal 
security analysis of the recommended changes that we can point our customers to.




If folks think that it would be helpful, I (or someone at Mozilla) could 
post in Mozilla's Security Blog to list some of the reasons for 
shortening certificate validity periods and shortening the frequency of 
re-validating domain name verification.



Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: About upcoming limits on trusted certificates

[Kathleen Wilson via dev-security-policy]

On 3/11/20 4:37 PM, Paul Walsh wrote:



On Mar 11, 2020, at 4:11 PM, Kathleen Wilson via dev-security-policy 
 wrote:

On 3/11/20 3:51 PM, Paul Walsh wrote:

Can you provide some insight to why you think a shorter frequency in domain 
validation would be beneficial?
[PW] If the owner’s identity has already been validated and that information is still valid, why ask them to validate again? 



By "domain validation" I specifically mean verifying that the 
certificate requestor owns/controls the domain name(s) to be included in 
the TLS certificate.



[PW] I believe it’s a good idea to ensure they’re still in control of the domain. 



So I guess we are in agreement on this.



My comment is in relation to the cost of validating their identity.



My proposal has nothing to do with identity validation.




[PW] Thanks for this info. If this is already part of the CA/B Forum, is it 
your intention to potentially do something different/specific for Firefox, 
irrespective of what happens in that forum?




My proposal is that if we are going to update Mozilla's policy to 
require TLS certs to have validity period of 398 days or less, we should 
also update Mozilla's policy to say that re-use of domain validation is 
only valid up to 398 days. i.e. the ownership/control of the domain name 
should be re-validated before the renewal cert is issued.


Currently Mozilla's policy and the BRs allow the CA to re-use domain 
validation results for up to 825 days. (which is inline with the 825 day 
certificate validity period currently allowed by the BRs)


Kathleen




___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: About upcoming limits on trusted certificates

[Kathleen Wilson via dev-security-policy]

On 3/11/20 3:51 PM, Paul Walsh wrote:
Can you provide some insight to why you think a shorter frequency in domain validation would be beneficial? 


To start with, it is common for a domain name to be purchased for one 
year. A certificate owner that was able to prove ownership/control of 
the domain name last year might not have renewed the domain name. So why 
should they be able to get a renewal cert without having that re-checked?




At the very least it deserves a new thread as the potential impact could be 
significant.


What exactly do you think is the significant impact in regards to 
re-verifying that the certificate requestor still has control of the 
domain name to be included in the new certificate?




And out of curiosity, why not raise your question inside the CA/Browser forum 
if you believe the original change being discussed should have been brought up 
there? I believe the potential outcome would have a separate impact on CAs and 
website owners. In particular, it would cost website owners in more time, 
resource and money. For this reason, I’m assuming you’re not asking the 
question to simply line up with another change.



It was part of the CAB Forum Ballot SC22 that was proposed last year by 
Google. That ballot was to change both the cert validity period and the 
validation information to 398 days.
"| 2020-03-01 | 4.2.1 and 6.3.2 | Certificates issued SHOULD NOT have a 
Validity Period greater than 397 days and MUST NOT have a Validity 
Period greater than 398 days. Re-use of validation information limited 
to 398 days. |"



Reference:
https://cabforum.org/pipermail/servercert-wg/2019-August/000894.html
https://github.com/cabforum/documents/compare/master...sleevi:0a72b35f7c877e6aa1e7559f712ad9eb84b2da12?diff=split#diff-7f6d14a20e7f3beb696b45e1bf8196f2


Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: About upcoming limits on trusted certificates

[Kathleen Wilson via dev-security-policy]

All,

First, I would like to say that my preference would have been for this 
type of change (limit SSL cert validity period to 398 days) to be agreed 
to in the CA/Browser Forum and added to the BRs. However, the ball is 
already rolling, and discussion here in m.d.s.p is supportive of 
updating Mozilla's Root Store Policy to incorporate the shorter validity 
period. So...


What do you all think about also limiting the re-use of domain validation?

BR section 3.2.2.4 currently says: "Completed validations of Applicant 
authority may be valid for the issuance of multiple Certificates over time."
And BR section 4.2.1 currently says: "The CA MAY use the documents and 
data provided in Section 3.2 to verify certificate information, or may 
reuse previous validations themselves, provided that the CA obtained the 
data or document from a source specified under Section 3.2 or completed 
the validation itself no more than 825 days prior to issuing the 
Certificate."


In line with that, section 2.1 of Mozilla's Root Store Policy currently 
says:

"CAs whose certificates are included in Mozilla's root program MUST: ...
"5. verify that all of the information that is included in SSL 
certificates remains current and correct at time intervals of 825 days 
or less;"


When we update Mozilla's Root Store Policy, should we shorten the domain 
validation frequency to be in line with the shortened certificate 
validity period? i.e. change item 5 in section 2.1 of Mozilla's Root 
Store Policy to:
"5. limit the validity period and re-use of domain validation for SSL 
certificates to 398 days or less if the certificate is issued on or 
after September 1, 2020;"


I realize that in order to enforce shorter frequency in domain 
validation we will need to get this change into the BRs and into the 
audit criteria. But CAs are expected to follow Mozilla's Root Store 
Policy regardless of enforcement mechanisms, and having this in our 
policy would make Mozilla's intentions clear.


As always, I will greatly appreciate your thoughtful and constructive 
input on this.


Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009

[Kathleen Wilson via dev-security-policy]

This request is for inclusion of the Microsec e-Szigno Root CA 2017 
trust anchor and to EV-enable the currently included Microsec e-Szigno 
Root CA 2009 trust anchor as documented in the following bug: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1445364


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


Summary of Information Gathered and Verified: 
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0274


Root Certificate Download URLs:
http://www.e-szigno.hu/rootca2017.crt
http://www.e-szigno.hu/rootca2009.crt

CP/CPS:
eIDAS conform Qualified Certificate for Website Authentication CP (EV): 
https://static.e-szigno.hu/docs/hr--min--ssl--EN--v2.13.pdf
eIDAS conform Qualified Certificate for Website Authentication CPS (EV): 
https://static.e-szigno.hu/docs/szsz--min--ssl--EN--v2.13.pdf
eIDAS conform Certificate for Website Authentication CP (DV, OV): 
https://static.e-szigno.hu/docs/hr--fok--ssl--EN--v2.13.pdf
eIDAS conform Certificate for Website Authentication CPS (DV, OV): 
https://static.e-szigno.hu/docs/szsz--fok--ssl--EN--v2.13.pdf


This request is to include the 2017 root with the websites and email 
trust bits enabled, and to enable both roots for EV.


Test Websites for the 2017 root:
Valid: https://eqtlsca2018-valid.e-szigno.hu/
Expired: https://eqtlsca2018-expired.e-szigno.hu/
Revoked: https://eqtlsca2018-revoked.e-szigno.hu/

Test Websites for the 2009 root:
Valid: https://qtlsca2018-valid.e-szigno.hu/
Expired: https://qtlsca2018-expired.e-szigno.hu/
Revoked: https://qtlsca2018-revoked.e-szigno.hu/

CRL URLs:
http://rootca2017-crl1.e-szigno.hu/rootca2017.crl, 
http://rootca2017-crl2.e-szigno.hu/rootca2017.crl, 
http://rootca2017-crl3.e-szigno.hu/rootca2017.crl

http://rootca2009-crl1.e-szigno.hu/rootca2009.crl,
http://rootca2009-crl2.e-szigno.hu/rootca2009.crl, 
http://rootca2009-crl3.e-szigno.hu/rootca2009.crl


OCSP URLs:
http://rootca2017-ocsp1.e-szigno.hu, 
http://rootca2017-ocsp2.e-szigno.hu, http://rootca2017-ocsp3.e-szigno.hu

http://rootca2009-ocsp1.e-szigno.hu,
http://rootca2009-ocsp2.e-szigno.hu, http://rootca2009-ocsp3.e-szigno.hu

Audit: Annual audits are performed by TÜViT according to the ETSI 319 
411 audit criteria.

Microsec e-Szigno Root CA 2017:
BR: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019121302_e-Szigno-Root-CA-2017_V1.1_s.pdf
EV: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019061201_Microsec-eSzignoRoot-CA-2017_EV-CAs_s.pdf

Microsec e-Szigno Root CA 2009:
BR: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019121301_Microsec-eSzignoRoot-CA-2009_V1.1_s.pdf 

EV: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019121301_Microsec-eSzignoRoot-CA-2009_V1.1_s.pdf 



Wayne performed the detailed review of the CPs, CPSs, BR Self 
Assessment, and related information for inclusion of the Microsec 
e-Szigno Root CA 2017 and the EV-enablement of the Microsec e-Szigno 
Root CA 2009 roots that are being tracked in this bug and he had the 
following comments:


==Meh==
* The subordinate CA certificates for this root were created in 2017 and 
2018. None of those intended for serverAuth are constrained by EKU. 
Mozilla began requiring this in 2019.

* Microsec issued two certificates in 2018 with 3-year validity periods [1].
* There are roughly 20 policy documents for this hierarchy [2]. It is 
quite challenging to determine which documents apply to which types of 
certificates. The upcoming version of Mozilla policy states that “CAs 
must provide a way to clearly determine which CP and CPS applies to each 
of its root and intermediate certificates.”
* CP section 1.3.2 permits 3rd party RAs, but in their BR 
Self-Assessment, Microsec states that “The Trust Service Provider do not 
apply third parties for RA activities.”
* CPS section 4.9.5 provides a detailed explanation of the revocation 
process but fails to mention the required preliminary report to the 
Subscriber and the entity who filed the Certificate Problem Report.
* CPS section 4.9.1 contains a section titled “Reasons for Revoking a 
Subordinate CA Certificate operated by another CA” but in their BR 
Self-assessment, Microsec states that “All Subordinate CA-s under the 
Microsec roots are operated by Microsec.”


==Bad==
* I was unable to locate the description of email address validation 
practices required by Mozilla policy section 2.2. Microsec published new 
CPS version adding section 3.2.7 to resolve this issue.
* Microsec recently issued what appears to be two certificate used for 
testing that violate the BRs [3][4]. They are now expired.

* CCADB currently lists 9 audit letter validation failures for Microsec.
* The root contains subject L and organizationIdentifier fields which 
are arguably in violation of BR 7.1.4.3 [5]. Some, if not all, of the 
subCAs also exhibit this issue.
* BR section 4.9.3 requires CPS section 1.5.2 to contain instructions 
for reporting an issue 

Re: Audit Reminders for Intermediate Certs

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of March 2020 Outdated Audit Statements for 
Intermediate Certs

Date: Tue, 3 Mar 2020 15:00:16 + (GMT)

CA Owner: AC Camerfirma, S.A.
   - Certificate Name: InfoCert Organization Validation CA 3
SHA-256 Fingerprint: 
247A6D807FF164031E0EB22CA85DE329A3A4E6603DBC6203F0C6E282A9C9EA84

Standard Audit Period End Date (mm/dd/): 12/02/2018
BR Audit Period End Date (mm/dd/): 12/02/2018



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 1H2020 Symantec Root Updates

[Kathleen Wilson via dev-security-policy]

I have filed these three bugs.

=== Bug #1: Root Removal and Disable Email Trust Bit ===


https://bugzilla.mozilla.org/show_bug.cgi?id=1618402
Symantec root certs - removal and turning off Email trust bit


=== Bug #2: Set CKA_NSS_SERVER_DISTRUST_AFTER ===


https://bugzilla.mozilla.org/show_bug.cgi?id=1618404
Symantec root certs - Set CKA_NSS_SERVER_DISTRUST_AFTER



=== Bug #3: Set CKA_NSS_EMAIL_DISTRUST_AFTER  ===


https://bugzilla.mozilla.org/show_bug.cgi?id=1618407
Symantec root certs - Set CKA_NSS_EMAIL_DISTRUST_AFTER

Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Auditing of CA facilities in lockdown because of an environmental disaster/pandemic

[Kathleen Wilson via dev-security-policy]

All,

First, I would like to add a personal note that I am truly sorry about 
the many people, families, and colleagues that are being impacted by the 
Coronavirus. This is a heartbreaking situation.


At Mozilla, our responsibility lies in ensuring people's security and 
privacy as they navigate the internet. Protecting our users and the 
integrity of the web is the reason Firefox exists. The best approach to 
do this is to work with certificate authorities as partners, through 
open and frank communication.


We will continue to follow our standard process to adjudicate the issue 
regarding failures to provide CA audit statements [1] and we will work 
with the impacted CAs throughout this process. Pursuant to this process, 
Mozilla will file CA incident bugs [2] in Bugzilla when audit statements 
are past due. The CA should respond in such bugs providing their 
Incident Report [3] explaining the situation with their audits, 
precautions that have been taken and their plan to move forward in 
reaching compliance again.


If it would be helpful, we could add a note in the Bugzilla whiteboard 
to indicate when the delayed audit statements are caused by CAs and 
auditors being unable to access facilities to perform the audits due to 
circumstances beyond their control. For example, the whiteboard could be 
something like: “[ca-compliance] Lockdown - Next Update ”. I will 
greatly appreciate thoughtful and constructive feedback on this.


Thanks,
Kathleen

References:
[1] https://www.ccadb.org/cas/updates
[2] https://wiki.mozilla.org/CA/Incident_Dashboard
[3] https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy