test - please ignore this thread

[Kathleen Wilson via dev-security-policy]

Please ignore this email thread.

In order for folks to debug the problem of posts to mozilla.dev.security.policy 
not getting propagated to Google Groups, they need email headers that are less 
than 8 days old.

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

Thanks,
Kathleen

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

Re: test - please ignore this thread

[Kathleen Wilson via dev-security-policy]

On Wednesday, November 29, 2017 at 1:39:54 PM UTC-8, Kathleen Wilson wrote:
> Please ignore this email thread.
> 
> In order for folks to debug the problem of posts to 
> mozilla.dev.security.policy not getting propagated to Google Groups, they 
> need email headers that are less than 8 days old.
> 
> Reference:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1412993
> 
> Thanks,
> Kathleen


Trying again...



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

Welcome Wayne Thayer to Mozilla!

[Kathleen Wilson via dev-security-policy]

All,

I am pleased to announce that Wayne Thayer is now a Mozilla employee, 
and will be working with me on our CA Program!


Many of you know Wayne from his involvement in this discussion forum and 
in the CA/Browser Forum, as a representative for the Go Daddy CA. Wayne 
was involved in Go Daddy's CA program from the beginning, so he has a 
deep understanding of CA policies, audits, and standards.


Some of the things Wayne will be working on in his new role include:
+ Review of root inclusion/update requests in discussion.
+ Investigate more complex root inclusion/update requests.
+ Help with CA mis-issuance investigations, bugs, and discussions.
+ Lead prioritization, effort, and discussions to update Mozilla Root 
Store Policy and CCADB Policy. (transition from Gerv over time)

+ Represent Mozilla in the CA/Browser Forum, along with Gerv.

I have added Wayne to the Policy_Participants wiki page:
https://wiki.mozilla.org/CA/Policy_Participants

Welcome, Wayne!

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

Re: .tg Certificates Issued by Let's Encrypt

[Kathleen Wilson via dev-security-policy]

On 11/6/17 3:40 AM, Ben Laurie wrote:

Since CT is not (yet) compulsory, it seems you probably have to contact all
CAs, doesn't it?




To close the loop on this...

I have added the following to the draft of the November 2017 CA 
Communication.


~~
ACTION 8: Check for issuance of TLS/SSL certificates to .tg domains from 
October 25 to November 2, 2017.


We believe that the .tg Registry was compromised from October 25 to 
November 1, 2017, such that a perpetrator set the Name Server (NS) 
Records for some domains to name servers controlled by them, and then 
successfully obtained SSL certificates for those domains.


Please check the SSL certificates that were issued to .tg domains and 
that chain up to your root certificates included in Mozilla's program to 
ensure that the certificate subscriber actually owns the domains 
included in their certificate.


Response Options:

- There are no TLS/SSL certificates issued to .tg domains that chain up 
to our root certificates included in Mozilla's program.


- There are TLS/SSL certificates issued to .tg domains that chain up to 
our root certificates included in Mozilla's program, but there were no 
new validations on .tg domains from October 25 to November 2, 2017.


- There are TLS/SSL certificates issued to .tg domains that chain up to 
our root certificates included in Mozilla's program, and we have 
re-verified the certificates that were issued to .tg domains from 
October 25 to November 2, 2017, and no problems were found.


- We have revoked certificates to .tg domains between October 25 and 
November 2, 2017, and have sent information about these revoked 
certificates to Mozilla.


- Not Applicable, because our root certificates do not have the Websites 
trust bit enabled.


- Other - explain
~~


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

Re: New Sub CAs under the DigiCert RSA and ECC Transition Roots

[Kathleen Wilson via dev-security-policy]

On 11/10/17 1:44 PM, Ben Wilson wrote:

In the spirit of full transparency and in attempt to comply to the extent we
can with Mozilla policy, on Thursday, Nov. 2, we created several sub CAs
under two new "transition" roots (yet to be submitted as roots).  These sub
CAs haven't been uploaded yet to the CCADB because no instances of the roots
have been created in the CCADB.  Also, I don't have access, yet, to the
Symantec roots in the CCADB, so while these sub CAs chain to the DigiCert
RSA and ECC transition roots (which have been cross-certified by the
Symantec roots - see https://ccadb.force.com/0011J1BtNYx and
https://ccadb.force.com/0011J1BtNaF), they are not listed yet in the
CCADB (because as a technical matter, I have no access - I get an error when
I attempt to do so).  No end entity certificates have been issued by the new
sub CAs.  We'll get those sub CAs uploaded to the CCADB when I get access
first thing next week.

Ben Wilson, JD, CISA, CISSP



Ben, I will follow up with you in separate email.

All, Just FYI... CAs are not allowed to directly add/edit Root Cert 
records in the CCADB, because that information must be verified by a 
root store operator first.


Cheers,
Kathleen

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

Re: .tg Certificates Issued by Let's Encrypt

[Kathleen Wilson via dev-security-policy]

On 11/13/17 7:22 PM, Jakob Bohm wrote:


Wouldn't the .tg incident be equally relevant for the e-mail trust bit?
(In which case the first 3 options should say TLS/SSL/e-mail)



Good point. To make it easier, I removed "TLS/SSL", and changed text to 
"certificates containing .tg domains".



Updated as follows:

~~

ACTION 8: Check for issuance of certificates containing .tg domains from 
October 25 to November 2, 2017.


We believe that the .tg Registry was compromised from October 25 to 
November 1, 2017, such that a perpetrator set the Name Server (NS) 
Records for some domains to name servers controlled by them, and then 
successfully obtained certificates for those domains.


Please check the certificates containing .tg domains that chain up to 
your root certificates included in Mozilla's program to ensure that the 
certificate subscriber actually owns the domains included in their 
certificate.


Response Options:

- There are no certificates containing .tg domains that chain up to our 
root certificates included in Mozilla's program.


- There are certificates containing .tg domains that chain up to our 
root certificates included in Mozilla's program, but there were no new 
validations on .tg domains from October 25 to November 2, 2017.


- There are certificates containing .tg domains that chain up to our 
root certificates included in Mozilla's program, and we have re-verified 
the certificates that were issued for .tg domains from October 25 to 
November 2, 2017, and no problems were found.


- We have revoked certificates containing .tg domains that were issued 
between October 25 and November 2, 2017, and have sent information about 
these revoked certificates to Mozilla.


- Other - explain
~~

Thanks,
Kathleen


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

Re: .tg Certificates Issued by Let's Encrypt

[Kathleen Wilson via dev-security-policy]

On 11/14/17 4:34 AM, douglas.beat...@gmail.com wrote:


Do we believe that this issue has been resolved by the Registry and issuance an 
resume as normal, or are there ongoing concerns which CAs should be aware of 
when issuing certificates to .tg domains?




Based on information from folks that are monitoring their NS Records, we 
believe that the .tg Registry problems were fixed on November 1, and 
have remained fixed since then.


I have not looked into how Registries are operated and maintained, so 
here is my personal (uneducated) opinion: I think it is possible that 
the .tg Registry could be compromised again. I have no idea if all of 
the newer Registries are using good network and security protocols, 
infrastructure, etc.


I think that we will need to have much deeper investigation and 
discussions about Registries, so I have added this to my to-do list, but 
I will not be able to get to it until January.


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]

Note to CAs: The indicator that an Audit Case is under review for 
particular root certs will only be added if there has been a 
corresponding Audit Root Case created for that particular root cert. If 
you have only created the Audit Case (and not the Audit Root Cases), 
that will not be indicated below.


http://ccadb.org/cas/updates
"CAs will create a single Audit Case for a particular set of audits 
(e.g. WebTrust CA, WebTrust BR, and WebTrust EV). Then the CA will 
create a set of corresponding Root Cases, one per root, to tell the 
CCADB which Root Certificate records the audit statements in that Audit 
Case apply to."



 Forwarded Message 
Subject: Summary of November 2017 Audit Reminder Emails
Date: Tue, 21 Nov 2017 20:00:14 + (GMT)

Mozilla: Audit Reminder
Root Certificates:
   EE Certification Centre Root CA
Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8826692
Audit Statement Date: 2016-11-25
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8826692
BR Audit Statement Date: 2016-11-25
CA Comments: null



Mozilla: Overdue Audit Statements
Root Certificates:
   Autoridad de Certificacion Firmaprofesional CIF A62634068**

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


Standard Audit: https://cert.webtrust.org/SealFile?seal=2032=pdf
Audit Statement Date: 2016-04-11
BR Audit: https://bug521439.bmoattachments.org/attachment.cgi?id=8809981
BR Audit Statement Date: 2016-08-05
EV Audit: https://bug521439.bmoattachments.org/attachment.cgi?id=8809982
EV Audit Statement Date: 2016-08-05
CA Comments: https://bugzilla.mozilla.org/show_bug.cgi?id=1412950 
Misunderstanding when switching from WebTrust to eIDAS/ETSI audit - 
resulted in point-in-time audit that Mozilla has not accepted. On 
October 31 CA requested 90 days to get period-of-time audits.




Mozilla: Audit Reminder
Root Certificates:
   CA Disig Root R1
   CA Disig Root R2
Standard Audit: https://eidas.disig.sk/pdf/Audit2016_report.pdf
Audit Statement Date: 2016-10-26
BR Audit: https://eidas.disig.sk/pdf/Audit2016_report.pdf
BR Audit Statement Date: 2016-10-26
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   AC Raíz Certicámara S.A.
Standard Audit: https://cert.webtrust.org/SealFile?seal=2120=pdf
Audit Statement Date: 2016-09-15
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   D-TRUST Root CA 3 2013
Standard Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/6768UE_s.pdf

Audit Statement Date: 2016-11-21
BR Audit:
BR Audit Statement Date:
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   TUBITAK Kamu SM SSL Kok Sertifikasi - Surum 1
Standard Audit: 
https://bug1262809.bmoattachments.org/attachment.cgi?id=8819839

Audit Statement Date: 2016-12-19
BR Audit: https://bug1262809.bmoattachments.org/attachment.cgi?id=8819839
BR Audit Statement Date: 2016-12-19
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   NetLock Arany (Class Gold) F?tanúsítvány**

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


Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8803550
Audit Statement Date: 2016-10-20
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8803550
BR Audit Statement Date: 2016-10-20
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   OpenTrust Root CA G1**
   OpenTrust Root CA G2**
   Certplus Root CA G1**
   OpenTrust Root CA G3**
   Certplus Root CA G2**

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


Standard Audit: 
https://bug1297034.bmoattachments.org/attachment.cgi?id=8783476

Audit Statement Date: 2016-08-19
BR Audit: https://bug1297034.bmoattachments.org/attachment.cgi?id=8783476
BR Audit Statement Date: 2016-08-19
EV Audit: https://bug1297034.bmoattachments.org/attachment.cgi?id=8783476
EV Audit Statement Date: 2016-08-19
CA Comments: https://bugzilla.mozilla.org/show_bug.cgi?id=1297034 Did 
not find reference to "Class 2 Primary CA" in the 2016 audit statements. 
Update: Audit of Class 2 Primary CA completed mid-October. Waiting for 
auditor to write attestation letter.




Mozilla: Audit Reminder
Root Certificates:
   Secure Global CA
   SecureTrust CA
   XRamp Global Certification Authority
Standard Audit: https://cert.webtrust.org/SealFile?seal=2138=pdf
Audit Statement Date: 2016-11-18
BR Audit: https://cert.webtrust.org/SealFile?seal=2139=pdf
BR Audit Statement Date: 2016-11-18
EV Audit: https://cert.webtrust.org/SealFile?seal=2140=pdf
EV Audit Statement Date: 2016-11-18
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Visa eCommerce Root**

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


Standard Audit: 
https://bug1301210.bmoattachments.org/attachment.cgi?id=8789076

Audit Statement Date: 2016-08-23
BR Audit: 

Upvote Salesforce Feature Request for Authenticated SMTP Relaying

[Kathleen Wilson via dev-security-policy]

Hi Everyone,

If any of you use Salesforce for something other than CCADB, then I will 
greatly appreciate it if you will Upvote for the following Salesforce 
feature request for password authentication for SMTP Relaying:


https://success.salesforce.com/ideaView?id=08730006wu7AAA

We are running into problems with companies adding stricter email 
policies, so email is bouncing because CCADB is hosted by Salesforce, so 
the email comes from @salesforce.com, but the From is supp...@ccadb.com. 
So we need to set up email relaying, but Salesforce does not support 
authenticated SMTP relaying, and Mozilla will not allow un-authenticated 
email relaying (even for 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: DigiCert/Symantec updates

[Kathleen Wilson via dev-security-policy]

This hasn't shown up in Google Groups for me yet, so please see the 
message below from Jeremy.


Note that there is a bug 
(https://bugzilla.mozilla.org/show_bug.cgi?id=1412993) and a Google 
support ticket open for this problem of messages that are posted via 
Google Groups not showing up in Google Groups. The messages are showing 
up in news.mozilla.org.

Other ways to participate in this discussion forum:
https://www.mozilla.org/en-US/about/forums/#dev-security-policy


On 11/15/17 9:03 PM, Jeremy Rowley wrote:

Hey everyone,

  


I wanted to give the community and update on how the DigiCert-Symantec
transition is going and make everyone aware of a few issues I recently
created on Bugzilla.

  


First, the good news.  DigiCert has started validating and issuing
certificates through the Symantec platform for a limited number of
customers.  The initial tests are positive, and I think we're on track to
meet the Dec 1 requirements.  Thanksgiving next week is going to be a sad
holiday, but we're very excited to see everything go live.  Right now, we
are doing DV, OV, and EV validation, although only issuing DV certs (as a
test of the integration).  You can see the hierarchy and migration plans
here: https://bugzilla.mozilla.org/show_bug.cgi?id=1401384. I'm happy to
answer any questions about it as well.

  


The bad news is there are some compliance issues.

  


1.  EV JOI issues. I filed this a while ago but never posted about it.
This bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1413761) caused
duplicate certificates to issue with incorrect JOI information. Basically,
when someone duplicated with a different key (RSA vs. ECC), incorrect JOI
information would be placed in the certificate.  The certs were revoked and
everything was dumped into CT.
2.  CAA Woes. Like most CAs, Symantec had improper CAA record checking
where DNSSEC was not properly checked if the record timed out.
(https://bugzilla.mozilla.org/show_bug.cgi?id=1409735). A patch was applied
to prevent this. As of Dec 1, all CAA record checking will be done by
DigiCert's systems instead of the systems we acquired from Symantec.
3.  Undisclosed CAs.  The details are a little iffy on this one so far,
but I think there are a couple hundred undisclosed issuing CAs within
Symantec's infrastructure.  These CAs are not issuing TLS certs from what I
can see, but they aren't disclosed in CCDAB
(https://bugzilla.mozilla.org/show_bug.cgi?id=1417771). I'll be posting
updates there as we figure out what we're looking at.  I think there was
confusion about whether these required disclosure as they don't issue certs
and are within the Symantec HSMs. I think disclosure and audit reports are
required so we'll be updating the latest audit report to show them.

  


And my least favorite because its DigiCert pre-close:

4.  Insufficient Entropy.  This one makes me sad because of how dumb it
is (https://bugzilla.mozilla.org/show_bug.cgi?id=141).  DigiCert's older
validation system validated domain control using random values in emails
sent to the WHOIS contact. These random values did not contain 112 bits of
entropy.  They contained 112 bits, but some of the characters were fixed.
The actual entropy was about 77.  Only the one system was impacted.  The
root cause was a developer not realizing 112 bits != 112 bits of entropy.
All other systems were verified as operationally correct.  This impacts a
large number of certs (like tens of thousands) so we're not 100% sure on how
to best remediate, especially since significant entropy still existed in the
random value.

  


Let me know what questions/comments you have. Looking forward to the
discussion!

Jeremy

  



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

Re: DRAFT November 2017 CA Communication

[Kathleen Wilson via dev-security-policy]

On 11/13/17 1:52 PM, Kathleen Wilson wrote:

Link to November 2017 CA Communication on wiki page:
https://wiki.mozilla.org/CA/Communications#November_2017_CA_Communication

Direct link to the survey:
https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3mogw7 



I will greatly appreciate it if you will review and comment on this 
version of the draft of the November 2017 CA Communication.


I am hoping to send it this week.



Hey Everyone,

I am planning to send this CA Communication in about two hours. I will 
send it to the Primary POCs and CC the CA's Email Alias 1 (as indicated 
in the CCADB).


I will also post a related announcement in Mozilla's Security Blog 
(https://blog.mozilla.org/security/).


Thanks,
Kathleen


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

Re: .tg Certificates Issued by Let's Encrypt

[Kathleen Wilson via dev-security-policy]

Thank you to everyone who has been looking into the .tg Registry problem 
and providing valuable information. I greatly appreciate all of your 
efforts!


I have updated the related action item in the November CA Communication 
to reflect the dates that we believe the .tg Registry was having 
problems with NS Records.


~~
ACTION 8: Check for issuance of certificates containing .tg domains from 
October 25 to November 11, 2017.


We believe that the .tg Registry was compromised from October 25 to 
November 10, 2017, such that a perpetrator set the Name Server (NS) 
Records for some domains to name servers controlled by them, and then 
successfully obtained certificates for those domains.


Please check the certificates containing .tg domains that chain up to 
your root certificates included in Mozilla's program to ensure that the 
certificate subscriber actually owns the domains included in their 
certificate.


Response Options:
- There are no certificates containing .tg domains that chain up to our 
root certificates included in Mozilla's program.


- There are certificates containing .tg domains that chain up to our 
root certificates included in Mozilla's program, but there were no new 
validations on .tg domains from October 25 to November 11, 2017.


- There are certificates containing .tg domains that chain up to our 
root certificates included in Mozilla's program, and we have re-verified 
the certificates that were issued for .tg domains from October 25 to 
November 11, 2017, and no problems were found.


- We have revoked certificates containing .tg domains that were issued 
between October 25 and November 11, 2017, and have sent information 
about these revoked certificates to Mozilla.


- Other - explain

~~

Thanks,
Kathleen

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

Re: DRAFT November 2017 CA Communication

[Kathleen Wilson via dev-security-policy]

On 11/16/17 10:04 AM, Kathleen Wilson wrote:

On 11/13/17 1:52 PM, Kathleen Wilson wrote:

Link to November 2017 CA Communication on wiki page:
https://wiki.mozilla.org/CA/Communications#November_2017_CA_Communication

Direct link to the survey:
https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3mogw7 



I will greatly appreciate it if you will review and comment on this 
version of the draft of the November 2017 CA Communication.


I am hoping to send it this week.



Hey Everyone,

I am planning to send this CA Communication in about two hours. I will 
send it to the Primary POCs and CC the CA's Email Alias 1 (as indicated 
in the CCADB).


I will also post a related announcement in Mozilla's Security Blog 
(https://blog.mozilla.org/security/).


Thanks,
Kathleen




The email is being sent now.

I have also posted about it in Mozilla's Security Blog:

https://blog.mozilla.org/security/2017/11/16/november-2017-ca-communication/

Thanks,
Kathleen

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

Re: DRAFT November 2017 CA Communication

[Kathleen Wilson via dev-security-policy]

All,

I have updated the draft of the November 2017 CA Communication as follows:

- Postponed the response deadline to December 15.

- Removed the CT item (that will be handled separately, later)

- Added an action item (#4) about full period-of-time audits with no 
gaps. (resulted in a slight re-ordering of the action items)


- Added action to test the Problem Reporting email (added to ACTION #6)

- Added "Mozilla currently allows Errata ID 5065 and 5097." to the CAA 
item (ACTION #7)


- Added an action item regarding the .tg Registry problems (ACTION #8)


Link to November 2017 CA Communication on wiki page:
https://wiki.mozilla.org/CA/Communications#November_2017_CA_Communication

Direct link to the survey:
https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3mogw7

I will greatly appreciate it if you will review and comment on this 
version of the draft of the November 2017 CA Communication.


I am hoping to send it this week.

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

Re: DRAFT November 2017 CA Communication

[Kathleen Wilson via dev-security-policy]

It has been suggested that I need to communicate to CAs that there will 
be consequences if their audit statements do not meet Mozilla’s 
requirements, so how about if I add the following to the November CA 
Communication?


~~
As stated in Mozilla’s April 2017 CA Communication[1] and Mozilla’s Root 
Store Policy[2, 3] audit statements/letters must meet the following 
requirements or Mozilla will reject the audit statements. And CAs 
without proper and current audit statements will be put on notice and 
potentially removed from Mozilla’s Root Store.


Additionally, audit statements must be provided in English from now on.

As a reminder, here is what Mozilla’s Root Store Policy[2, 3] currently 
says:
“Full-surveillance period-of-time audits MUST be conducted and updated 
audit information provided no less frequently than annually. Successive 
audits MUST be contiguous (no gaps).


The publicly-available documentation relating to each audit MUST contain 
at least the following clearly-labelled information:

- name of the company being audited;
- name and address of the organization performing the audit;
- Distinguished Name and SHA256 fingerprint of each root and 
intermediate certificate that was in scope;
- audit criteria (with version number) that were used to audit each of 
the certificates;
- a list of the CA policy documents (with version numbers) referenced 
during the audit;

- whether the audit is for a period of time or a point in time;
- the start date and end date of the period, for those that cover a 
period of time;

- the point-in-time date, for those that are for a point in time;
- the date the report was issued (which will necessarily be after the 
end date or point-in-time date); and
- For ETSI, a statement to indicate if the audit was a full audit, and 
which parts of the criteria were applied, e.g. DVCP, OVCP, NCP, NCP+, 
LCP, EVCP, EVCP+, QCP-w, Part1 (General Requirements), and/or Part 2 
(Requirements for trust service providers).

“

The above listed information MUST be provided by the auditor in each 
audit statement or its accompanying letter. If the information is 
provided in an accompanying letter, then the pdf file that is submitted 
to Mozilla must contain BOTH the audit statement and the letter.


Please indicate your CA’s understanding that each audit statement/letter 
provided to Mozilla must be in English and must meet the requirements of 
Mozilla’s Root Store Policy, specifically stating the information listed 
above. Otherwise Mozilla will reject the audit statement, and put the CA 
on notice for being out of compliance, which may result in the CA’s root 
certificate(s) being removed from our program.



[1] 
https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o03WrzBC=Q00018,Q00032


[2] 
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#audit-parameters


[3] 
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#public-audit-information


~~


As always, I will appreciate your thoughtful and constructive feedback 
on this suggested addition to the draft of theNovember CA Communication.


Thanks,
Kathleen


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

Re: Francisco Partners acquires Comodo certificate authority business

[Kathleen Wilson via dev-security-policy]

On 11/1/17 12:22 PM, westmai...@gmail.com wrote:

Hello,

Why you're removed the post of Peter Gutmann (Nov. 1, 2017, 4:08)?

If I understand correctly, at the time of the public discussion for new root 
certificates SSL.com (RA Comodo) Mozilla concealed information about the 
acquisition of SSL business of Comodo and that now the past public discussion 
about new root certificates SSL.com can be considered incorrect on this moment 
of time.

Regards,
Andrew.




Please forward the missing email from Peter Gutmann to me.

I do not know if it is related, but we have been experiencing problems 
with groups.google.com:


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

Kathleen

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

Re: Discrepancy in Included CAs and Included CA Certificates List

[Kathleen Wilson via dev-security-policy]

On 11/9/17 5:58 AM, cbonn...@trustwave.com wrote:

Hello all,
I was cross-referencing data contained in the "Included CAs" spreadsheet 
(https://wiki.mozilla.org/CA/Included_CAs) and the "Included CA Certificates" spreadsheet 
(https://wiki.mozilla.org/CA/Included_Certificates) and discovered that CNNIC is listed in the "Included CAs" 
spreadsheet but has no roots listed in the "Included CA Certificates" spreadsheet. It appears that CNNIC is 
the only CA that does not appear in both spreadsheets. Is this discrepancy intentional?

Thanks,
Corey Bonnell




Thanks for checking, and for reporting this. It has been fixed.

Thanks!
Kathleen

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

Bugzilla/wiki integration broken

[Kathleen Wilson via dev-security-policy]

All,

Mozilla's Bugzilla system was updated a couple of days ago, and now the 
Bugzilla/wiki integration is not working very well. So you will notice some 
changes in the following wiki pages:

https://wiki.mozilla.org/CA/Incident_Dashboard

https://wiki.mozilla.org/CA/Dashboard

I have implemented a temporary work-around, so at least the Bug Summary is 
getting displayed again.

I have filed a bug about this:
https://bugzilla.mozilla.org/show_bug.cgi?id=1412570

I will restore the wiki pages as soon as the bug is fixed.

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

DRAFT November 2017 CA Communication

[Kathleen Wilson via dev-security-policy]

All,

I will greatly appreciate your thoughtful and constructive feedback on the 
DRAFT of Mozilla's next CA Communication, which I am hoping to send in early 
November.

https://wiki.mozilla.org/CA/Communications#November_2017_CA_Communication

Direct link to the survey:
https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3mogw7

Thanks,
Kathleen

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

Re: ETSI audits not listing audit periods

[Kathleen Wilson via dev-security-policy]

On Monday, October 30, 2017 at 2:59:31 PM UTC-7, Ryan Sleevi wrote:
> 
> I would expect that it would be incumbent on the CABs and the CAs providing
> EN 319 411-1 certificates to help the community better understand the level
> of assurance provided. That is, I think those supporting the continued
> recognition of ETSI should attempt to demonstrate where either the
> understanding of WebTrust-based audits or EN 319 411-1 certificates is
> incorrect or inaccurate. Otherwise, I think your conclusions - about no
> longer recognizing such schemes - are reasonable.


I hope that CAs who rely on ETSI audits are following this discussion forum, 
and that they will promptly add their comments/explanation here, and ask their 
auditors to do the same. 

I've filed this issue:
https://github.com/mozilla/pkipolicy/issues/105
In which I said:
~~
I think that all CAs should be held to the same level of assurance/audits.

So, I think we have two choices:

1) Remove ETSI as an acceptable audit scheme.

2) The ETSI folks update their audit schemes (that Mozilla's Root Store Policy 
currently allows) to meet our requirements about looking backward at 
certificate issuance data -- period-of-time audits as described above and in 
our policy and the BRs.
~~


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

Re: Bugzilla/wiki integration broken

[Kathleen Wilson via dev-security-policy]

On Monday, October 30, 2017 at 5:17:38 PM UTC-7, Kathleen Wilson wrote:
> On Saturday, October 28, 2017 at 5:07:51 PM UTC-7, Kathleen Wilson wrote:
> > All,
> > 
> > Mozilla's Bugzilla system was updated a couple of days ago, and now the 
> > Bugzilla/wiki integration is not working very well. So you will notice some 
> > changes in the following wiki pages:
> > 
> > https://wiki.mozilla.org/CA/Incident_Dashboard
> > 
> > https://wiki.mozilla.org/CA/Dashboard
> > 
> > I have implemented a temporary work-around, so at least the Bug Summary is 
> > getting displayed again.
> > 
> > I have filed a bug about this:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1412570
> > 
> > I will restore the wiki pages as soon as the bug is fixed.
> > 
> 
> 
> The columns are displaying correctly now
> 
> But the "status" parameter is still not working, so the tables show bugs in 
> all statuses, including RESOLVED.
> 


I spoke too soon - now there is zero data being displayed in these pages.  

The appropriate folks are aware of the problem and working to fix it.

Kathleen

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

Re: ETSI Audits Almost Always FAIL to list audit period

[Kathleen Wilson via dev-security-policy]

Thank you, Dimitris, for sharing input from your auditor.


> Long story short, as an accredited CAB, we _definitely_ must check 
> historical data over the period since previous audit. This requirement 
> is clearly included in Section 7.9 of ETSI EN 319 403 
> :
> 
> “/In addition, a sample of records relating to the operation of TSP over 
> the historical period since the previous audit shall be examined by the 
> auditor./”


I don't find the definition of "historical period" in that document. So, to me 
this statement does not mean the same thing as reviewing or sampling the data 
over a particular period of time.

Also this section says: "Surveillance audits need not necessarily be full 
system audits."

That also then raises the question: Are ETSI Surveillance Audits holding CAs 
accountable to the same level as WebTrust audits?

I'm fairly certain that each annual WebTrust audit is a full system audit. 
Please correct me if I'm wrong.



> 
> Also (in the same section):
> 
> “/The Conformity Assessment Body shall define a programme of periodic 
> surveillance and re-assessment that includes on-site audits to verify 
> that TSPs and trust services they provide continue to comply with the 
> requirements. It is recommended that at least one surveillance audit per 
> year is performed in between full (re-)assessment audits./”


This isn't helping to convince me that ETSI audits (especially surveillance 
audits) are meeting Mozilla's policy requirements, and the BRs.



> 
> The above is closely linked to Section 7.9.4 of the more generic ISO/IEC 
> 17065:2012  which requires 
> that, since this is a product / service certification:
> 
> “/When continuing use of a certification mark is authorized for a 
> process or service, surveillance shall be established and shall include 
> periodic surveillance activities to ensure ongoing validity of the 
> demonstration of fulfilment of process or service requirements./”


While that sounds good, I'm afraid that "surveillance" is up for 
interpretation. And the document clearly says that "surveillance" does not mean 
full system audit, and may involve sampling of data over an unspecified period 
of time (which could be one day).


> 
> CA/B Forum BR 
>  
> takes a slightly more time-specific approach in Section 8.1:
> 
> “/The period during which the CA issues Certificates SHALL be divided 
> into an unbroken sequence of audit periods. An audit period MUST NOT 
> exceed one year in duration./”
> 
> Thus, I agree with you, *this is mainly an audit report issue*, and it 
> is due to a difference in the terminology and approach.


I am not convinced.


> 
> For example, in all our audits for other standards, no “audit period” is 
> clearly documented in the report; time since previous audit is always 
> implied.


Again, I don't believe that it is reasonable to assume that auditing/sampling 
has been done over the full year.


> 
> As a more general remark:
> 
> CABs are auditing *only* according to specific rules and requirements 
> set by the standards.


Then, perhaps the ETSI standards are not sufficient, and we should not allow 
ETSI audits until the ETSI standard do become sufficient.


> 
> Any private sector requirements, such as the CA/B Forum BR, are also 
> verified during the audit only when they are referenced by the standards 
> or if this is requested explicitly by the TSP itself.
> 
> Any CAB who *is accredited* to conduct audits according to ISO/IEC 17065 
> + ETSI EN 319 403 meets their requirements and *this is assessed by its 
> NAB* (both in office and in the field). It does not provide “some extra 
> level of assurance”, it is the cornerstone of the accreditation scheme.
> 
> This accreditation is *accepted internationally* due to the 
> participation of the NAB to EA MLA 
>  and IAF 
>  (i.e. similar to 
> the cross-certification between Root CA’s concept). Its purpose is to 
> ensure *equivalence and reliability*.
> 
> If CA/B Forum requires for an audit period to be clearly defined and 
> this information to present in the final report, *this should be 
> communicated* to all accredited CABs either directly (one can find this 
> list here 
> )
>  


I do agree that the CAs should be ensuring that their auditors are performing 
audits that meet the BRs, and the CAs should be ensuring that their auditors 
provide audit statements that meet our requirements, which have been 
communicated via CA Communications and Mozilla's root store policy.

I do not agree that the CAB Forum and the Root Store Operators are supposed 

Re: ETSI Audits Almost Always FAIL to list audit period

[Kathleen Wilson via dev-security-policy]

On 10/31/17 2:57 PM, Dimitris Zacharopoulos wrote:


[NS]: If all ETSI reports delivered to Root Programs had clear 
indication regarding the “audit period” and the type of the audit (i.e. 
full), probably this discussion would not be raised at all?



Correct.






For example, in all our audits for other standards, no “audit period” is
clearly documented in the report; time since previous audit is always
implied.


Again, I don't believe that it is reasonable to assume that 
auditing/sampling has been done over the full year.




[NS]: No assumptions are made. This is common practice and common 
understanding.



Sigh. If it were so well understood then I would think CAs and auditors 
would be providing better answers regarding whether their audits are 
point-in-time or full audits, and what the audit period start and end 
dates are.


I has truly been an uphill battle to get audit statements that have this 
information, and (since so many of the ETSI audit statements do not have 
this information) trying to get this information from the CAs and their 
auditors regarding their current audit statements.




Then, perhaps the ETSI standards are not sufficient, and we should not 
allow ETSI audits until the ETSI standard do become sufficient.




[NS]: This is true, but only if you isolate it from the rest of the text 
below! But, ETSI standards (e.g. ETSI EN 319 411-1, section 2.1, points 
4 and 5) include clear normative references to BR and EVG. Explicit 
references are also included in many detailed requirements of the 
standard. So, ETSI standards cannot be audited without BR (and EVG in 
case of EV).


On top of that, Root Program requirements are also included in the scope 
of the audit for all CAs which wish to participate in these programs.






Then I don't understand why so many of the ETSI audits that CAs are 
sending to us are failing to meet our requirements about audit periods 
and being full period-of-time audits.




I do agree that the CAs should be ensuring that their auditors are 
performing audits that meet the BRs, and the CAs should be ensuring 
that their auditors provide audit statements that meet our 
requirements, which have been communicated via CA Communications and 
Mozilla's root store policy.


I do not agree that the CAB Forum and the Root Store Operators are 
supposed to contact all of the ETSI auditors to communicate our 
requirements.


On the other hand, I think that whomever is in charge of ETSI should 
care enough to reach out to the CAB Forum and the major Root Store 
Operators to ensure that the ETSI criteria is sufficient, and that 
there is appropriate templates for their auditors to use, to ensure 
proper audits and audit statements.


WebTrust folks have been doing things for years now.



[NS]: Makes sense.


or through the TSPs which participate in Root Programs. Even better,
disclose its recommended “ETSI audit report template”, common across all
Root Programs.


Shouldn't an ETSI person be doing this, with input from the CAB Forum 
and major root store operators?


Mozilla's requirements are already listed here:

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#audit-parameters 



https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#public-audit-information 



What further information do auditors need from us, before they will 
start performing the required audits and providing the required audit 
statement content?



Sorry if I'm being slow here, but how do we get the ETSI audits and 
audit statements fixed ASAP?


I have already expressed my expectations in previous CA Communications, 
and our requirements are listed in Mozilla's Root Store Policy.


I do *not* believe that it is my responsibility to fix these ETSI audit 
problems. I *do* believe it is my responsibility to stop accepting ETSI 
audits if the problems are not fixed ASAP.


Thanks,
Kathleen



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

Incident Report : GlobalSign certificates with ROCA Fingerprint

[Kathleen Wilson via dev-security-policy]

Re-posting the message below, because it appears that this message did 
not get propagated to groups.google.com.


I have filed a bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1412993 - 
mozilla.dev.security.policy posts not getting propagated to Google Groups



-Original Message-
Sent: Monday, October 30, 2017 1:36 PM
To: mozilla-dev-security-policy
Subject: Incident Report : GlobalSign certificates with ROCA Fingerprint

I wanted to send out a status of where we are on the ROCA vulnerable 
certificates issued by GlobalSign.  A full report will be coming later 
this week once we've completed the revocations, but here is a summary of 
the scope and status as it stands right now.


Here's the Timeline:

10/16: Became aware of the ROCA issue via a post to mdsp list.

10/17-18: Created and ran a report over all active SSL certificates in 
our database that showed there were 53 vulnerable SSL certificates. 
They are all from one customer and they are all under the  ".apsch.by" 
domain.


10/18: Received link with a list of 35 GlobalSign issued SSL 
certificates, all of which were on our report, 
https://misissued.com/batch/28/


10/19: Customer was contacted and we let them know about the issue. 
These are used within a Tolling system which, if revoked, would result 
in substantial disruption of commercial services.  They immediately 
initiated process to get them replaced; however, due to the location of 
the devices and the need to generate the keys using a new process (which 
is not vulnerable), they need approximately 2 weeks to perform the 
replacement.  They have firm plans to complete this by November 3rd.


We're prioritizing the fix to prohibit issuance of additional SSL 
certificate with this vulnerability and in the meantime we're running 
the report every few days to verify no new certificates were issued with 
this vulnerability.


We'll complete the full report as soon as we perform the revocations.

Doug

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

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

Re: ETSI audits not listing audit periods

[Kathleen Wilson via dev-security-policy]

On Monday, October 30, 2017 at 5:02:08 PM UTC-7, Buschart, Rufus wrote:
> Our ETSI audit report 
> (https://www.siemens.com/corp/pool/pki/siemens_etsi.pdf) states:
> 
> > An audit of the certification service, documented in a report, provided 
> > evidence that the requirements of the following
> > specification have been fulfilled. The audit was conducted on 22th - 24th 
> > February 2017 covering the timeframe
> > 27th February 2016 to 21st February 2017. It was a full audit covering all 
> > aspects of the standard performed.
> > A second and third audit was performed on 19th and 20th June 2017 to 
> > implement further Issuing CAs and in the time
> > between 23rd to 30th August.
> 
> We repeat this full audit annually. From what I understand out of this 
> discussion, this will meet your requirements, correct?


Yes, that meets our requirement regarding stating the audit period and if it is 
a period-of-time/full audit. The problem is that most ETSI audit statements 
that we get do not say this. And it has been an uphill battle for me to get 
ETSI audit statements to say this.

Please note that there is still information missing from the audit statement, 
such as SHA-256 fingerprints. See:
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#public-audit-information


But your audit statement is much better than most ETSI audit statements I get.


> 
> If you want us to move from ETSI to Webtrust we, and probably every other CA 
> relying on ETSI, would highly appreciate a reasonable grace period to do so, 
> since we are already in the middle of the preparation of our next audit in 
> February 2018.


I understand.

Thanks,
Kathleen

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

Re: Bugzilla/wiki integration broken

[Kathleen Wilson via dev-security-policy]

On Saturday, October 28, 2017 at 5:07:51 PM UTC-7, Kathleen Wilson wrote:
> All,
> 
> Mozilla's Bugzilla system was updated a couple of days ago, and now the 
> Bugzilla/wiki integration is not working very well. So you will notice some 
> changes in the following wiki pages:
> 
> https://wiki.mozilla.org/CA/Incident_Dashboard
> 
> https://wiki.mozilla.org/CA/Dashboard
> 
> I have implemented a temporary work-around, so at least the Bug Summary is 
> getting displayed again.
> 
> I have filed a bug about this:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1412570
> 
> I will restore the wiki pages as soon as the bug is fixed.
> 


The columns are displaying correctly now

But the "status" parameter is still not working, so the tables show bugs in all 
statuses, including RESOLVED.

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 2018 Audit Reminder Emails
Date: Tue, 15 May 2018 19:00:06 + (GMT)


Mozilla: Audit Reminder
Root Certificates:
   GDCA TrustAUTH R5 ROOT**

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


Standard Audit: https://cert.webtrust.org/SealFile?seal=2231=pdf
Audit Statement Date: 2017-04-14
BR Audit: https://cert.webtrust.org/SealFile?seal=2232=pdf
BR Audit Statement Date: 2017-04-14
EV Audit: https://cert.webtrust.org/SealFile?seal=2233=pdf
EV Audit Statement Date: 2017-04-14
CA Comments: null



Mozilla: Audit Reminder
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
   UTN-USERFirst-Client Authentication and Email
   USERTrust RSA Certification Authority
Standard Audit: https://cert.webtrust.org/SealFile?seal=2270=pdf
Audit Statement Date: 2017-06-02
BR Audit: https://cert.webtrust.org/SealFile?seal=2274=pdf
BR Audit Statement Date: 2017-06-02
BR Audit:
BR Audit Statement Date:
EV Audit: https://cert.webtrust.org/SealFile?seal=2272=pdf
EV Audit Statement Date: 2017-06-02
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   ComSign CA**

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


Standard Audit: 
https://bug1368471.bmoattachments.org/attachment.cgi?id=8872330

Audit Statement Date: 2017-04-26
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   SecureSign RootCA11
Standard Audit: https://cert.webtrust.org/SealFile?seal=2251=pdf
Audit Statement Date: 2017-05-10
BR Audit: https://bug1369520.bmoattachments.org/attachment.cgi?id=8873589
BR Audit Statement Date: 2017-05-10
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Entrust Root Certification Authority - EC1
   Entrust Root Certification Authority - G2
   AffirmTrust Commercial
   AffirmTrust Networking
   AffirmTrust Premium
   AffirmTrust Premium ECC
   Entrust Root Certification Authority
   Entrust.net Certification Authority (2048)
Standard Audit: https://cert.webtrust.org/SealFile?seal=2248=pdf
Audit Statement Date: 2017-05-17
Standard Audit: 
https://www.affirmtrust.com/wp-content/uploads/20170114-20170531-AffirmTrust-WebTrust-for-CA.pdf

Audit Statement Date: 2017-06-12
BR Audit: https://cert.webtrust.org/SealFile?seal=2248=pdf
BR Audit Statement Date: 2017-05-17
BR Audit: 
https://www.affirmtrust.com/wp-content/uploads/20170114-20170531-AffirmTrust-SSL-Baseline-Requirements..pdf

BR Audit Statement Date: 2017-06-12
EV Audit: https://cert.webtrust.org/SealFile?seal=2248=pdf
EV Audit Statement Date: 2017-05-17
EV Audit: 
https://www.affirmtrust.com/wp-content/uploads/20170114-20170531-AffirmTrust-WebTrust-for-EV-SSL.pdf

EV Audit Statement Date: 2017-06-12
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Government Root Certification Authority - Taiwan
Standard Audit: https://cert.webtrust.org/SealFile?seal=2252=pdf
Audit Statement Date: 2017-05-24
BR Audit: https://cert.webtrust.org/SealFile?seal=2253=pdf
BR Audit Statement Date: 2017-05-24
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   SwissSign Platinum CA - G2
   SwissSign Silver CA - G2
Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8861552
Audit Statement Date: 2017-03-30
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8861552
BR Audit Statement Date: 2017-03-30
CA Comments: null



Mozilla: Audit Reminder
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=8862399

Audit Statement Date: 2017-03-01
BR Audit: https://bug1360184.bmoattachments.org/attachment.cgi?id=8862399
BR Audit Statement Date: 2017-03-01
CA Comments: https://bugzilla.mozilla.org/show_bug.cgi?id=1360184#c10




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

Updating CCADB PEM extracted data June 18-22

[Kathleen Wilson via dev-security-policy]

All,

We will begin the CCADB migration to the new PEM-extraction tool today, 
and expect to be done by Friday. It will take a couple days to make all 
the changes, re-run the PEM-extraction over all of the data, update 
reports, etc.


The CCADB and reports will continue to be available during the 
migration, but there may be momentary inconsistencies in the 
PEM-extracted data and fields. Note that these are read-only fields in 
the CCADB.



The most noticeable changes will be:

1) Certificate Serial Number
New value is upper case. (e.g. old: 35def4cf, new: 35DEF4CF)

2) SHA-1 Fingerprint and SHA-256 Fingerprint
Removing the colons.
OLD: 
08:29:7A:40:47:DB:A2:36:80:C7:31:DB:6E:31:76:53:CA:78:48:E1:BE:BD:3A:0B:01:79:A7:07:F9:2C:F1:78

NEW: 08297A4047DBA23680C731DB6E317653CA7848E1BEBD3A0B0179A707F92CF178

3) "Certificate ID" field will be replaced by a new "Subject + SPKI 
SHA256" field, and a new "SPKI SHA256" field will be added.

Removing the colons.
OLD: 
4F:31:A6:06:59:45:EA:BC:6A:45:CB:AD:72:D8:0A:20:A4:40:0E:55:05:B9:2A:0C:4C:F1:F6:C1:A3:10:92:9F

NEW: FF5680CD73A5703DA04817A075FD462506A73506C4B81A1583EF549478D26476

4) New Signature Hash Algorithm values
NEW Values:
ecdsaWithSHA256
ecdsaWithSHA384
MD5WithRSA
SHA1WithRSA
SHA256WithRSA
SHA384WithRSA
SHA512WithRSA

5) New Key Usage values
NEW Values:
CRL Sign
Digital Signature
Non Repudiation
Key Encipherment
Certificate Sign
Key Agreement

6) New Extended Key Usage values
NEW Values:
ExtKeyUsageOCSPSigning
ExtKeyUsageIPSECEndSystem
ExtKeyUsageIPSECTunnel
ExtKeyUsageIPSECUser
ExtKeyUsageClientAuth
ExtKeyUsageCodeSigning
ExtKeyUsageEmailProtection
ExtKeyUsageServerAuth
ExtKeyUsageTimeStamping
ExtKeyUsageMicrosoftServerGatedCrypto
ExtKeyUsageNetscapeServerGatedCrypto

7) Technically Constrained
Checkbox will be updated according to Mozilla's current policy (e.g. EKU 
*and* Name Constraints)


I will appreciate your patience this week, during this migration.

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

Re: Updating CCADB PEM extracted data June 18-22

[Kathleen Wilson via dev-security-policy]

Most of the PEM data in the CCADB has been updated using the new tool.

There are 5 records (listed below) that the new tool fails to do the PEM 
extraction for, so I am updating their PEM data manually.


Suva Root CA 1  Intermediate Certificate (Revoked)
832266D6BA8CBFCBF28E0614A01D9F4C39B8E41F7C87D2077DBB6C03840CA9C2
Error Statuscode: 400 Message: Could not parse X.509 certificate: x509: 
failed to parse rfc822Name constraint "@suva.ch"


SSL.com EV Code Signing Intermediate CA RSA R2	Intermediate Certificate	 
(Technically Constrained via EKU to codeSigning)

D8:D3:82:E3:7D:2F:93:81:1A:A3:D9:40:EE:F4:C6:EE:A4:7B:B3:BA:50:27:1A:8B:F2:E8:C2:4C:DD:39:3C:56
Error Statuscode: 400 Message: Failed to parse certificate PEM  

SSL.com EV Timestamping Intermediate CA RSA R1  Intermediate Certificate
(Technically Constrained via EKU to timeStamping)
55:4E:3A:E3:14:AF:F2:64:D3:FD:E7:F2:BB:C8:18:F2:E7:34:D9:4B:33:62:08:ED:EF:E7:C3:7B:16:2B:6A:96
Error Statuscode: 400 Message: Failed to parse certificate PEM  

DPDHL TLS CA I3 Intermediate Certificate
(Revoked)
5F:FD:ED:E8:29:57:B4:3D:46:76:B1:CF:CC:39:CE:B1:50:DC:63:DB:FC:33:E2:6D:99:CA:A9:B9:76:2A:45:64
Error Statuscode: 400 Message: Could not parse X.509 certificate: x509: 
failed to parse dnsName constraint "leserservice-media.de "	


DPDHL TLS CA I3 Intermediate Certificate
(Revoked)
60:61:F7:73:35:4C:D2:ED:56:13:A0:94:AB:0E:82:70:D5:C2:47:99:32:B4:2D:FD:A7:27:DB:83:FE:BD:18:B8
Error Statuscode: 400 Message: Could not parse X.509 certificate: x509: 
failed to parse dnsName constraint "leserservice-media.de "



Please let me know if you notice any problems with the new data in the 
CCADB.


Thanks,
Kathleen



On 6/18/18 10:58 AM, Kathleen Wilson wrote:

All,

We will begin the CCADB migration to the new PEM-extraction tool today, 
and expect to be done by Friday. It will take a couple days to make all 
the changes, re-run the PEM-extraction over all of the data, update 
reports, etc.


The CCADB and reports will continue to be available during the 
migration, but there may be momentary inconsistencies in the 
PEM-extracted data and fields. Note that these are read-only fields in 
the CCADB.



The most noticeable changes will be:

1) Certificate Serial Number
New value is upper case. (e.g. old: 35def4cf, new: 35DEF4CF)

2) SHA-1 Fingerprint and SHA-256 Fingerprint
Removing the colons.
OLD: 
08:29:7A:40:47:DB:A2:36:80:C7:31:DB:6E:31:76:53:CA:78:48:E1:BE:BD:3A:0B:01:79:A7:07:F9:2C:F1:78 


NEW: 08297A4047DBA23680C731DB6E317653CA7848E1BEBD3A0B0179A707F92CF178

3) "Certificate ID" field will be replaced by a new "Subject + SPKI 
SHA256" field, and a new "SPKI SHA256" field will be added.

Removing the colons.
OLD: 
4F:31:A6:06:59:45:EA:BC:6A:45:CB:AD:72:D8:0A:20:A4:40:0E:55:05:B9:2A:0C:4C:F1:F6:C1:A3:10:92:9F 


NEW: FF5680CD73A5703DA04817A075FD462506A73506C4B81A1583EF549478D26476

4) New Signature Hash Algorithm values
NEW Values:
ecdsaWithSHA256
ecdsaWithSHA384
MD5WithRSA
SHA1WithRSA
SHA256WithRSA
SHA384WithRSA
SHA512WithRSA

5) New Key Usage values
NEW Values:
CRL Sign
Digital Signature
Non Repudiation
Key Encipherment
Certificate Sign
Key Agreement

6) New Extended Key Usage values
NEW Values:
ExtKeyUsageOCSPSigning
ExtKeyUsageIPSECEndSystem
ExtKeyUsageIPSECTunnel
ExtKeyUsageIPSECUser
ExtKeyUsageClientAuth
ExtKeyUsageCodeSigning
ExtKeyUsageEmailProtection
ExtKeyUsageServerAuth
ExtKeyUsageTimeStamping
ExtKeyUsageMicrosoftServerGatedCrypto
ExtKeyUsageNetscapeServerGatedCrypto

7) Technically Constrained
Checkbox will be updated according to Mozilla's current policy (e.g. EKU 
*and* Name Constraints)


I will appreciate your patience this week, during this migration.

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 2018 Audit Reminder Emails
Date: Tue, 19 Jun 2018 19:00:17 + (GMT)


Mozilla: Audit Reminder
Root Certificates:
   Atos TrustedRoot 2011
Standard Audit: 
https://www.mydqs.com/kunden/kundendatenbank.html?aoemydqs%5BrequestId%5D=europev2-DQS-00DCD7AE71E211E7B653005056A04F41-_v2%5BdownloadKey%5D=91bdb1288df96a7e719d7ebcad82dc822d5b1a65%5Baction%5D=downloadDocument=f4c93332780df1788265

Audit Statement Date: 2017-06-14
BR Audit: 
https://www.mydqs.com/kunden/kundendatenbank.html?aoemydqs%5BrequestId%5D=europev2-DQS-00DCD7AE71E211E7B653005056A04F41-_v2%5BdownloadKey%5D=91bdb1288df96a7e719d7ebcad82dc822d5b1a65%5Baction%5D=downloadDocument=f4c93332780df1788265

BR Audit Statement Date: 2017-06-14
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Chambers of Commerce Root
   Chambers of Commerce Root - 2008
   Global Chambersign Root
   Global Chambersign Root - 2008
Standard Audit: https://cert.webtrust.org/SealFile?seal=2283=pdf
Audit Statement Date: 2017-07-10
BR Audit: https://cert.webtrust.org/SealFile?seal=2284=pdf
BR Audit Statement Date: 2017-07-10
EV Audit: https://cert.webtrust.org/SealFile?seal=2285=pdf
EV Audit Statement Date: 2017-07-10
CA Comments: null



Mozilla: Audit Reminder
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
   UTN-USERFirst-Client Authentication and Email
   USERTrust RSA Certification Authority
Standard Audit: https://cert.webtrust.org/SealFile?seal=2270=pdf
Audit Statement Date: 2017-06-02
BR Audit: https://cert.webtrust.org/SealFile?seal=2274=pdf
BR Audit Statement Date: 2017-06-02
BR Audit:
BR Audit Statement Date:
EV Audit: https://cert.webtrust.org/SealFile?seal=2272=pdf
EV Audit Statement Date: 2017-06-02
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   ComSign CA**

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


Standard Audit: 
https://bug1368471.bmoattachments.org/attachment.cgi?id=8872330

Audit Statement Date: 2017-04-26
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Government Root Certification Authority - Taiwan
Standard Audit: https://cert.webtrust.org/SealFile?seal=2252=pdf
Audit Statement Date: 2017-05-24
BR Audit: https://cert.webtrust.org/SealFile?seal=2253=pdf
BR Audit Statement Date: 2017-05-24
CA Comments: null



Mozilla: Audit Reminder
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://www.harica.gr/documents/HARICA-ETSI_CERTIFICATE_AUTH_W_ANNEX_290617-7.pdf

Audit Statement Date: 2017-06-29
BR Audit: 
https://www.harica.gr/documents/HARICA-ETSI_CERTIFICATE_AUTH_W_ANNEX_290617-7.pdf

BR Audit Statement Date: 2017-06-29
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   SwissSign Platinum CA - G2
   SwissSign Silver CA - G2
Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8861552
Audit Statement Date: 2017-03-30
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8861552
BR Audit Statement Date: 2017-03-30
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Sonera Class2 CA
   TeliaSonera Root CA v1
Standard Audit: 
https://support.partnergate.sonera.com/download/CA/WebTrust-Audit-Report-2017-06-30.pdf

Audit Statement Date: 2017-06-30
BR Audit: 
https://support.partnergate.sonera.com/download/CA/WebTrust-BR-Audit-Report-2017-06-30.pdf

BR Audit Statement Date: 2017-06-30
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Deutsche Telekom Root CA 2
   T-TeleSec GlobalRoot Class 2
   T-TeleSec GlobalRoot Class 3
Standard Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/Browser_Audit_Attestation_2017_V2.2_s.pdf

Audit Statement Date: 2017-06-30
BR Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/6760UE_s.pdf

BR Audit Statement Date: 2017-07-31
BR Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/6761UE_s.pdf

BR Audit Statement Date: 2017-07-31
EV Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/6761UE_s.pdf

EV Audit Statement Date: 2017-07-31
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Certum Trusted Network CA 2
   Certum CA
   Certum Trusted Network CA
Standard Audit: https://cert.webtrust.org/SealFile?seal=2301=pdf
Audit Statement Date: 2017-07-05
BR Audit: https://cert.webtrust.org/SealFile?seal=2298=pdf
BR Audit Statement Date: 2017-08-05
EV Audit: https://cert.webtrust.org/SealFile?seal=2296=pdf
EV Audit Statement Date: 2017-07-05
CA Comments: null




___

Plan to update CCADB PEM extraction tool

[Kathleen Wilson via dev-security-policy]

All,

We are working towards updating the tool that we use in the CCADB to 
parse PEM data and fill in the corresponding fields in the CCADB. The 
new tool is in the TLS Observatory:


https://github.com/mozilla/tls-observatory

Example:
curl https://tls-observatory.services.mozilla.com/api/v1/certificate -F 
certificate=@/tmp/certificate.pem


There are some differences in the data that will result when we switch 
to the new tool. Please let me know if you foresee problems with any of 
these changes.


1) Certificate Serial Number
New value is upper case. (e.g. old: 35def4cf, new: 35DEF4CF)
The new data should be more correct in regards to handling of leading zeros.

2) SHA-1 Fingerprint and SHA-256 Fingerprint
Removing the colons.
OLD: 
08:29:7A:40:47:DB:A2:36:80:C7:31:DB:6E:31:76:53:CA:78:48:E1:BE:BD:3A:0B:01:79:A7:07:F9:2C:F1:78

NEW: 08297A4047DBA23680C731DB6E317653CA7848E1BEBD3A0B0179A707F92CF178

3) Certificate ID
OLD: hash(Subject + SPKI), with colons
NEW: hash(SPKI), no colons
OLD: 
4F:31:A6:06:59:45:EA:BC:6A:45:CB:AD:72:D8:0A:20:A4:40:0E:55:05:B9:2A:0C:4C:F1:F6:C1:A3:10:92:9F

NEW: FF5680CD73A5703DA04817A075FD462506A73506C4B81A1583EF549478D26476

4) Signature Hash Algorithm

OLD Values:
ecdsaWithSHA256
ecdsaWithSHA384
md5WithRSAEncryption
sha1WithRSAEncryption
sha256WithRSAEncryption
sha384WithRSAEncryption
sha512WithRSAEncryption


NEW Values:
ecdsaWithSHA256
ecdsaWithSHA384
MD5WithRSA
SHA1WithRSA
SHA256WithRSA
SHA384WithRSA
SHA512WithRSA

5) Key Usage

OLD Values:
cRLSign
digitalSignature
nonRepudiation
keyAgreement
keyEncipherment
keyCertSign

NEW Values:
CRL Sign
Digital Signature
Non Repudiation
Key Encipherment
Certificate Sign
Key Agreement


6) Extended Key Usage

OLD Values:
1.3.6.1.5.5.7.3.9
1.3.6.1.5.5.7.3.5
1.3.6.1.5.5.7.3.6
1.3.6.1.5.5.7.3.7
clientAuth
codeSigning
emailProtection
serverAuth
1.2.840.113583.1.1.5
msSGC
nsSGC

NEW Values:
ExtKeyUsageOCSPSigning
ExtKeyUsageIPSECEndSystem
ExtKeyUsageIPSECTunnel
ExtKeyUsageIPSECUser
ExtKeyUsageClientAuth
ExtKeyUsageCodeSigning
ExtKeyUsageEmailProtection
ExtKeyUsageServerAuth
ExtKeyUsageTimeStamping
ExtKeyUsageMicrosoftServerGatedCrypto
ExtKeyUsageNetscapeServerGatedCrypto


7) Technically Constrained
Checkbox will be updated according to Mozilla's current policy (e.g. EKU 
*and* Name Constraints)


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

Re: Plan to update CCADB PEM extraction tool

[Kathleen Wilson via dev-security-policy]

I would like to replace the old "Certificate ID" field with the 
following two fields, because they are useful in different situations, 
and the new field names are clear about what the values are.


SPKI SHA256
Subject + SPKI SHA256


Also, I am seeing differences in the following fields for a few certs -- 
the certs that have multiple values for CN, O, and OU. Please let me 
know if you foresee any problems with such deltas.


For example:

Issuer Common Name NEW: Posta CA Root
Issuer Common Name OLD: Configuration

Subject Common Name NEW: Experian Root CA
Subject Common Name OLD: Configuration

Subject Organization Unit NEW: Symantec Trust Network, Class 2 Managed 
PKI Individual Subscriber CA

Subject Organization Unit OLD: Symantec Trust Network

Subject Organization NEW: Leidos, PKI
Subject Organization OLD: Leidos


Thanks,
Kathleen

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

Re: DRAFT November 2017 CA Communication

[Kathleen Wilson via dev-security-policy]

On Wednesday, October 25, 2017 at 2:05:33 PM UTC-7, Andrew Ayer wrote:
> Hi Kathleen,
> 
> I suggest being explicit about which CAA errata Mozilla allows.
> 
> For CNAME, it's erratum 5065.
> 
> For DNAME, it's erratum 5097.
> 
> Link to errata: https://www.rfc-editor.org/errata_search.php?rfc=6844
> 

I added the link, and added a "TO DO" note regarding specifying the exact 
errata.

Looking forward to further discussion about which errata should be allowed.

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

Changes to CA Program - Q1 2018

[Kathleen Wilson via dev-security-policy]

All,

I would like to thank Aaron Wu for all of his help on our CA Program, 
and am sorry to say that his last day at Mozilla will be January 12. I 
have appreciated all of Aaron’s work, and it has been a pleasure to work 
with him.


I will be re-assigning all of the root inclusion/update Bugzilla Bugs 
back to me, and I will take back responsibility for the high-level 
verification of the CA-provided data for root inclusion/update requests. 
I will also take back responsibility for verifying CA annual updates, 
and we will continue to work to improve that process and automation via 
the CCADB.


Wayne Thayer, Gerv Markham, and Ryan Sleevi have already taken 
responsibility for the CA Incident bugs 
(https://wiki.mozilla.org/CA/Incident_Dashboard). Thankfully, many of 
you members of the CA Community are helping with this effort.


Wayne and Devon O’Brien will take responsibility for ensuring that 
thorough reviews of CA root inclusion/update requests happen (see 
below), and Wayne will be responsible for the discussion phase of CA 
root inclusion/update requests. We greatly appreciate all of the input 
that you all provide during the discussions of these requests, and are 
especially grateful for the thorough reviews that have been performed 
and documented, with special thanks to Ryan Sleevi, Andrew Whalley, and 
Devon O’Brien.


I think this is a good time for us to make some changes to Mozilla’s 
Root Inclusion Process to improve the effectiveness of the public 
discussion phase by performing the detailed CP/CPS review prior to the 
public discussion. The goal of this change is to focus the discussion 
period on gathering community input and to allow the process to continue 
when no objections are raised.


As such, I propose that we make the following changes to
https://wiki.mozilla.org/CA/Application_Process#Process_Overview

~~ PROPOSED CHANGES ~~

Step 1: A representative of the CA submits the request via Bugzilla and 
provides the information a listed in 
https://wiki.mozilla.org/CA/Information_Checklist.


* Immediate change: None

* Future change: CAs will directly input their Information Checklist 
data into the CCADB.
All root inclusion/update requests will begin with a Bugzilla Bug, as we 
do today. However, we will create a process by which CAs will be 
responsible for entering and updating their own data in the CCADB for 
their request.


Step 2: A representative of Mozilla verifies the information provided by 
the CA.


* Immediate change: None
This will continue to be a high-level review to make sure that all of 
the required data has been provided, per the Information Checklist, and 
that the required tests have been performed.


* Future change: Improvements/automation in CCADB for verifying this data.

Step 3: A representative of Mozilla adds the request to the queue for 
public discussion.


* Immediate change: Replace this step as follows.
NEW Step 3: A representative of Mozilla or of the CA Community (as 
agreed by a Mozilla representative) thoroughly reviews the CA’s 
documents, and adds a Comment in the Bugzilla Bug about their findings. 
If the CA has everything in order, then the Comment will be that the 
request may proceed, and the request will be added to the queue for 
public discussion. Otherwise the Comment will list actions that the CA 
must complete. This may include, but is not limited to fixing 
certificate content, updating process, updating the CP/CPS, and 
obtaining new audit statements. The list of actions will be categorized 
into one of the following 3 groups:

  --- 1: Must be completed before this request may proceed.
  --- 2: Must be completed before this request may be approved, but the 
request may continue through the public discussion step in parallel with 
the CA completing their action items.
  --- 3: Must be completed before the CA’s next annual audit, but the 
request may continue through the rest of the approval/inclusion process.


Step 4: Anyone interested in the CA's application participates in 
discussions of CA requests currently in discussion in the 
mozilla.dev.security.policy forum.


* Immediate Change: Delete this step from the wiki page, because it is a 
general statement that does not belong here.


Step 5: When the application reaches the head of the queue, a 
representative of Mozilla starts the public discussion for the CA in the 
mozilla.dev.security.policy forum.
We prefer that at least two independent parties review and comment upon 
each application.


* Immediate change: Due to the change in Step 3, this step becomes more 
of a time-limited comment period, during which CA Community members may 
raise concern or questions. But if no one posts any concerns in the 
discussion forum, then that will be interpreted as meaning that the CA 
Community does not have concern about the request. So, after the 
specified time, if no concerns are raised, then the discussion will be 
closed, and the request will move on to the approval phase.

Re: Changes to CA Program - Q1 2018

[Kathleen Wilson via dev-security-policy]

Is the same process used for existing CAs that need to add a new root and new 
CAs applying for the first time?


Yes.

From
https://wiki.mozilla.org/CA/Application_Process#Process_Overview
""
The same process is used to request:
- Root certificate inclusion for all CAs, even if the CA already has 
root certificates included in Mozilla's root store

- Turning on additional trust bits for an already-included root certificate
- Enabling EV treatment for an already-included root certificate
- Including a renewed version of an already-included root certificate
""

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

Re: Changes to CA Program - Q1 2018

[Kathleen Wilson via dev-security-policy]

On 1/10/18 10:52 AM, Doug Beattie wrote:

Thanks Kathleen.  I only asked because you are trying to reduce the manpower for 
processing applications, and if a CA was already in the program there might not be a need 
to do as much.  But on the other hand, this forces us to all comply with those pesky set 
of questions in "CA/Forbidden or Problematic Practices" that we've ignored and 
forces a formal review of the CPS.


Correct, the root inclusion/update process is this way on purpose, so 
that CAs have to evaluate their practices and documentation, and fix 
their problems with compliance to Mozilla's policy and the BRs.


Thanks,
Kathleen

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

Add Wayne Thayer as Peer of Mozilla's CA Certificates and CA Certificate Policy modules

[Kathleen Wilson via dev-security-policy]

All,

I propose adding Wayne Thayer as a peer[1] of Mozilla's CA Certificates 
Module[2] and CA Certificate Policy Module[3]. As you know, Wayne and I 
are distributing the job of running Mozilla's CA Program between us, so 
he will be actively working 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: Audit Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

On 1/4/18 3:53 AM, Kurt Roeckx wrote:

On 2018-01-04 01:36, Kathleen Wilson wrote:


Mozilla: Audit Reminder
Root Certificates:
    AC Raíz Certicámara S.A.
Standard Audit: https://cert.webtrust.org/SealFile?seal=2120=pdf
Audit Statement Date: 2016-09-15
CA Comments: null


The audit period of that is 2015-07-01 to 2016-04-30. They clearly 
overdue, instead of just a reminder.



Kurt



There are two root certs with
Certificate Issuer Common Name: AC Raíz Certicámara S.A.
Certificate Issuer Organization: Sociedad Cameral de Certificación 
Digital - Certicámara S.A.


One is included in Mozilla's program with only the Email trust bit 
enabled. The other is not yet included in Mozilla's program 
(https://bugzilla.mozilla.org/show_bug.cgi?id=1281002).


There had been a mistake in the way that the Audit Case was handled, so 
the root cert included in Mozilla's program had not been updated with 
the current audit statement.

https://cert.webtrust.org/SealFile?seal=2333=pdf

I have resolved this discrepency.

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

Re: Changes to CA Program - Q1 2018

[Kathleen Wilson via dev-security-policy]

On 1/9/18 4:23 PM, Kathleen Wilson wrote:
I will be re-assigning all of the root inclusion/update Bugzilla Bugs 
back to me, 


Done


and I will take back responsibility for the high-level 
verification of the CA-provided data for root inclusion/update requests. 



I hope to begin work on this by next week. It will take me a few weeks 
to catch up, so I appreciate your patience.



I will also take back responsibility for verifying CA annual updates, 


Done.


and we will continue to work to improve that process and automation via 
the CCADB.


We have added buttons to Audit Cases, in an effort to make it easier for 
CAs to enter all of their annual update information: 'Add/Update Root 
Cases', 'Edit Test Websites', etc.


CAs, please let me know if you have other ideas about how to make your 
data entry for annual updates easier. Note that the buttons above were 
added based on feedback from CAs entering their data.


http://ccadb.org/cas/updates




I propose that we make the following changes to
https://wiki.mozilla.org/CA/Application_Process#Process_Overview



The wiki page has been updated, and the supporting wiki pages have also 
been updated.


As always, I will appreciate your constructive feedback on the changes.

Thanks,
Kathleen


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

New Reports for CAA Identifiers and Problem Reporting Mechanisms

[Kathleen Wilson via dev-security-policy]

Just FYI that two new public reports are now available via the 
https://wiki.mozilla.org/CA/Included_CAs wiki page. One for Problem 
Reporting Mechanisms, and one for CAA identifiers.


Here's the direct links to the new reports:

https://ccadb-public.secure.force.com/mozilla/ProblemReportingMechanismsReport

https://ccadb-public.secure.force.com/mozilla/CAAIdentifiersReport

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

Re: CCADB Report: AllCertificateRecordsCSVFormat

[Kathleen Wilson via dev-security-policy]

On 11/15/17 1:48 PM, Kathleen Wilson wrote:

All,

The following report lists data for all root and intermediate cert 
records in the CCADB.


https://ccadb-public.secure.force.com/mozilla/AllCertificateRecordsCSVFormat 



A link to this report is here:
http://ccadb.org/resources

Cheers,
Kathleen




Just FYI that the following two columns have been added to the 
AllCertificateRecordsCSVFormat report.

1) Parent Salesforce Record ID
2) Parent SHA-256 Fingerprint

Cheers,
Kathleen


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

Tracking Receipt of BR Self Assessments

[Kathleen Wilson via dev-security-policy]

All,

I am tracking the date that I received a BR Self Assessment from each CA 
here:


https://docs.google.com/spreadsheets/d/1Lmdkl3gTpKyBgZwL_6j5ivClBXiGMUnZyAVJDTHtjO4/edit?usp=sharing

The purpose of this exercise is to ensure that every CA in our program 
is fully aware and complying with the current CA/Browser Forum Baseline 
Requirements. And to ensure that CAs are updating their CP/CPS documents 
accordingly.


https://cabforum.org/baseline-requirements-documents/

I do not plan to publish these BR Self Assessments, but I am checking 
them to make sure the CA has done them and to see what their CP/CPS 
update plans are.


Please check the spreadsheet for your CA to make sure I have correctly 
noted receipt of your BR Self Assessment.


If the date is empty for your CA, then please re-send your BR Self 
Assessment to me via email.


Thanks,
Kathleen

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

Re: ccadb.org

[Kathleen Wilson via dev-security-policy]

On 1/30/18 6:19 AM, Gervase Markham wrote:

On 30/01/18 00:48, James Burton wrote:

I was doing research on the ccadb.org site and was surprised to find that
the site is running only in HTTP and is not using HTTPS. Now, I understand
that GitHub pages don't support HTTPS for custom domains but you could
always use CloudFlare for HTTPS support in the meantime until GitHub
enables HTTPS for custom domains.


The Cloudflare solution turns out not to be ideal for Mozilla IT. They
have instead proposed another solution using AWS and Nubis, which is
being implemented in the (infrastructure-confidential) bug
https://bugzilla.mozilla.org/show_bug.cgi?id=1409786 . I've pinged the
bug so hopefully something should happen soon.

Gerv




All,

At 6pm PST on Thursday, February 8th, we will begin the migration of 
ccadb.org to https.


It is possible that during this migration users may receive errors when 
trying to access the ccadb.org site.


Cheers,
Kathleen


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

Re: ccadb.org

[Kathleen Wilson via dev-security-policy]

On 2/7/18 11:41 AM, Kathleen Wilson wrote:

All,

At 6pm PST on Thursday, February 8th, we will begin the migration of 
ccadb.org to https.


It is possible that during this migration users may receive errors when 
trying to access the ccadb.org site.



All,

Something went wrong, so the changes had to be rolled back.

Stay tuned...

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

Gerv - Peer Emeritus

[Kathleen Wilson via dev-security-policy]

All,

I have had the tremendous opportunity to work with Gerv Markham on the 
CA Program for many years, and am extremely grateful to Gerv for his 
countless valuable and lasting contributions to the CA world.


Gerv has decided to step away from work at this time, to focus on his 
family[1]. We will miss Gerv's participation in this 
mozilla.dev.security.policy forum and the CA/Browser Forum.


With a heavy heart I will be moving Gerv from Peer to Peer Emeritus 
status for Mozilla's CA Certificates Module[2] and CA Certificate Policy 
Module [3].


Many thanks to Gerv for being such a fantastic participant and leader in 
the CA world, and such a energetic and inspiring person to work with.


Kathleen

[1] https://blog.gerv.net/2018/02/going-home/
[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: Audit Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

Summary of audit statements that are due:

 Forwarded Message 
Subject: Summary of February 2018 Audit Reminder Emails
Date: Tue, 20 Feb 2018 20:00:05 + (GMT)

Mozilla: Audit Reminder
Root Certificates:
   ISRG Root X1
Standard Audit: https://cert.webtrust.org/SealFile?seal=2193=pdf
Audit Statement Date: 2017-02-07
BR Audit: https://cert.webtrust.org/SealFile?seal=2194=pdf
BR Audit Statement Date: 2017-02-07
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Staat der Nederlanden EV Root CA
   Staat der Nederlanden Root CA - G3
   Staat der Nederlanden Root CA - G2
Standard Audit: https://cert.webtrust.org/SealFile?seal=2204=pdf
Audit Statement Date: 2017-03-03
BR Audit: https://cert.webtrust.org/SealFile?seal=2204=pdf
BR Audit Statement Date: 2017-03-03
EV Audit: https://cert.webtrust.org/SealFile?seal=2204=pdf
EV Audit Statement Date: 2017-03-03
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   certSIGN ROOT CA
Standard Audit: 
https://www.certsign.ro/certsign_en/files/certSIGN_Webtrust_CA_8.02.2017.pdf

Audit Statement Date: 2017-02-08
BR Audit: 
https://www.certsign.ro/certsign_en/files/certSIGN_Webtrust_CA_8.02.2017.pdf

BR Audit Statement Date: 2017-02-08
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Symantec Class 1 Public Primary Certification Authority - G4**
   Symantec Class 2 Public Primary Certification Authority - G4**
   Symantec Class 2 Public Primary Certification Authority - G6**
   VeriSign Class 1 Public Primary Certification Authority - G3**
   VeriSign Class 2 Public Primary Certification Authority - G3**
   VeriSign Class 3 Public Primary Certification Authority - G3**
   VeriSign Class 3 Public Primary Certification Authority - G4**
   VeriSign Class 3 Public Primary Certification Authority - G5**
   VeriSign Universal Root Certification Authority**
   Symantec Class 1 Public Primary Certification Authority - G6**

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


Standard Audit: 
https://www.symantec.com/content/en/us/about/media/repository/18_Symantec_STN_WTCA_period_end_11-30-2016.pdf

Audit Statement Date: 2017-02-28
BR Audit:
BR Audit Statement Date:
BR Audit: 
https://www.symantec.com/content/en/us/about/media/repository/21_Symantec_STN_WTBR_period_end_11-30-2016.pdf

BR Audit Statement Date: 2017-02-28
EV Audit:
EV Audit Statement Date:
EV Audit: 
https://www.symantec.com/content/en/us/about/media/repository/24_Symantec_STN_WTEV_period_end_11-30-2016.pdf

EV Audit Statement Date: 2017-02-28
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Hongkong Post Root CA 1
Standard Audit: https://cert.webtrust.org/SealFile?seal=2208=pdf
Audit Statement Date: 2017-02-28
BR Audit: 
http://www.hongkongpost.gov.hk/product/cps/ecert/img/HKPCA_WebTrust_BR_2016-17.pdf

BR Audit Statement Date: 2017-02-28
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Class 2 Primary CA
Standard Audit: 
https://bug1297034.bmoattachments.org/attachment.cgi?id=8849236

Audit Statement Date: 2017-01-14
BR Audit: https://bug1297034.bmoattachments.org/attachment.cgi?id=8849236
BR Audit Statement Date: 2017-01-14
EV Audit: https://bug1297034.bmoattachments.org/attachment.cgi?id=8849236
EV Audit Statement Date: 2017-01-14
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   TWCA Global Root CA
   TWCA Root Certification Authority
Standard Audit: https://cert.webtrust.org/SealFile?seal=2197=pdf
Audit Statement Date: 2017-02-16
BR Audit: https://cert.webtrust.org/SealFile?seal=2195=pdf
BR Audit Statement Date: 2017-02-16
EV Audit: https://cert.webtrust.org/SealFile?seal=2196=pdf
EV Audit Statement Date: 2017-02-16
CA Comments: null



Mozilla: Audit Reminder
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=8862399

Audit Statement Date: 2017-03-01
BR Audit: https://bug1360184.bmoattachments.org/attachment.cgi?id=8862399
BR Audit Statement Date: 2017-03-01
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı H5
Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8828490
Audit Statement Date: 2016-12-31
BR Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/6749UE_s.pdf

BR Audit Statement Date: 2016-12-31
CA Comments: null



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

CCADB - Audit Letter Validation (ALV)

[Kathleen Wilson via dev-security-policy]

All,

I have begun receiving questions about the Audit Letter Validation (ALV) 
results in CCADB Audit Cases, so here is some information about it.


CAs and Root Store Operators who are logged into the CCADB will find in 
the Audit Case page a button called "Audit Letter Validation (ALV)". You 
can click on this button, even after an Audit Case is closed. You will 
get a page with title "Audit Letter Validation Results", which will list 
the audit statement URLs, which root certificates were indicated to be 
in scope of the audit statements (via Root Cases), and a list of the 
resulting errors returned by ALV. After the results return, you can 
click on the "Print Report" button to get a summary.


ALV is a program provided by Microsoft that automatically parses audit 
statements, looking for specific information and comparing the 
information provided in the Audit Cases and corresponding Root Cases 
with the information in the provided audit statements. The audit 
statements must be in PDF format, and it is preferred that they are 
text-based instead of image-based. Though ALV does also attempt to parse 
images.


A few things to note:

1) ALV is still in testing phase, so our Audit Case process does not 
currently require CAs to click on the button and resolve all errors. Us 
root store operators (Karina and I) are using each Audit Case to test 
and provide feedback to the ALV team.


2) ALV still has some bugs that the Microsoft team are working on, such 
as only looking for the SHA-256 Fingerprints in an audit statement if 
the Root Case indicated the audit statement applies to that root cert.


3) We still need to figure out the clean/qualified part of ALV -- want 
to fail when the audit statement has modified opinions or such. But want 
to pass when no problems noted. The point is to inform root store 
operators when we need to look more closely at an audit statement, and 
record a comment about problems that were noted by the auditors.


4) When we feel that ALV is ready for CAs, we plan to update the Audit 
Case process to require CAs to click on the ALV button and resolve or 
explain all resulting errors before they will submit their Audit Cases 
to us root store operators for final review.


5) After we get ALV working well for root certs, we plan to also use it 
for intermediate certificates.


Thanks,
Kathleen

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

Re: CCADB - Audit Letter Validation (ALV)

[Kathleen Wilson via dev-security-policy]

On 2/15/18 10:24 AM, Kathleen Wilson wrote:

All,

I have begun receiving questions about the Audit Letter Validation (ALV) 
results in CCADB Audit Cases, so here is some information about it.




ALV looks for the things listed in Mozilla's and Microsoft's root store 
policies...


Mozilla's audit statement requirements:
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#public-audit-information

Microsoft's audit statement requirements:
https://social.technet.microsoft.com/wiki/contents/articles/31635.microsoft-trusted-root-certificate-program-audit-requirements.aspx#E_Audit_Attestation




___
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]

Wishing all of you a happy 2018!

Below is the summary of the audit reminder email that was automatically 
sent by the CCADB in December.


PS: I am back at work as of today, but I will appreciate your patience 
while to catch up on my email inbox. If there is anything urgent, you 
might want to prepend URGENT to the subject and re-send to me.



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

Mozilla: Audit Reminder
Root Certificates:
   TrustCor RootCert CA-2
   TrustCor RootCert CA-1
   TrustCor ECA-1
Standard Audit: https://cert.webtrust.org/SealFile?seal=2169=pdf
Audit Statement Date: 2016-12-15
BR Audit: https://cert.webtrust.org/SealFile?seal=2163=pdf
BR Audit Statement Date: 2016-12-15
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   EE Certification Centre Root CA**

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


Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8826692
Audit Statement Date: 2016-11-25
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8826692
BR Audit Statement Date: 2016-11-25
CA Comments: null



Mozilla: Your root is in danger of being removed
Root Certificates:
   Autoridad de Certificacion Firmaprofesional CIF A62634068**

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


Standard Audit: https://cert.webtrust.org/SealFile?seal=2032=pdf
Audit Statement Date: 2016-04-11
BR Audit: https://bug521439.bmoattachments.org/attachment.cgi?id=8809981
BR Audit Statement Date: 2016-08-05
EV Audit: https://bug521439.bmoattachments.org/attachment.cgi?id=8809982
EV Audit Statement Date: 2016-08-05
CA Comments: https://bugzilla.mozilla.org/show_bug.cgi?id=1412950 
Misunderstanding when switching from WebTrust to eIDAS/ETSI audit - 
resulted in point-in-time audit that Mozilla has not accepted. On 
October 31 CA requested 90 days to get period-of-time audits.




Mozilla: Audit Reminder
Root Certificates:
   CA Disig Root R2
Standard Audit: https://eidas.disig.sk/pdf/Audit2016_report.pdf
Audit Statement Date: 2016-10-26
BR Audit: https://eidas.disig.sk/pdf/Audit2016_report.pdf
BR Audit Statement Date: 2016-10-26
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   AC Raíz Certicámara S.A.
Standard Audit: https://cert.webtrust.org/SealFile?seal=2120=pdf
Audit Statement Date: 2016-09-15
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   D-TRUST Root CA 3 2013**

** 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/en/6768UE_s.pdf

Audit Statement Date: 2016-11-21
BR Audit:
BR Audit Statement Date:
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   TUBITAK Kamu SM SSL Kok Sertifikasi - Surum 1
Standard Audit: 
https://bug1262809.bmoattachments.org/attachment.cgi?id=8819839

Audit Statement Date: 2016-12-19
BR Audit: https://bug1262809.bmoattachments.org/attachment.cgi?id=8819839
BR Audit Statement Date: 2016-12-19
CA Comments: null



Mozilla: Overdue Audit Statements
Root Certificates:
   OpenTrust Root CA G1**
   OpenTrust Root CA G2**
   Certplus Root CA G1**
   Class 2 Primary CA
   OpenTrust Root CA G3**
   Certplus Root CA G2**

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


Standard Audit: 
https://bug1297034.bmoattachments.org/attachment.cgi?id=8783476

Audit Statement Date: 2016-08-19
Standard Audit: 
https://bug1297034.bmoattachments.org/attachment.cgi?id=8849236

Audit Statement Date: 2017-01-14
BR Audit: https://bug1297034.bmoattachments.org/attachment.cgi?id=8783476
BR Audit Statement Date: 2016-08-19
BR Audit: https://bug1297034.bmoattachments.org/attachment.cgi?id=8849236
BR Audit Statement Date: 2017-01-14
EV Audit: https://bug1297034.bmoattachments.org/attachment.cgi?id=8783476
EV Audit Statement Date: 2016-08-19
EV Audit: https://bug1297034.bmoattachments.org/attachment.cgi?id=8849236
EV Audit Statement Date: 2017-01-14
CA Comments: https://bugzilla.mozilla.org/show_bug.cgi?id=1297034 Did 
not find reference to "Class 2 Primary CA" in the 2016 audit statements. 
Update: Audit of Class 2 Primary CA completed mid-October. Waiting for 
auditor to write attestation letter.




Mozilla: Audit Reminder
Root Certificates:
   Secure Global CA
   SecureTrust CA
   XRamp Global Certification Authority
Standard Audit: https://cert.webtrust.org/SealFile?seal=2138=pdf
Audit Statement Date: 2016-11-18
BR Audit: https://cert.webtrust.org/SealFile?seal=2139=pdf
BR Audit Statement Date: 2016-11-18
EV Audit: https://cert.webtrust.org/SealFile?seal=2140=pdf
EV Audit Statement Date: 2016-11-18
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   TÜRKTRUST Elektronik Sertifika Hizmet Sa?lay?c?s? H5
Standard Audit: 

Fond Farewell to Gerv Markham

[Kathleen Wilson via dev-security-policy]

Dear Fellow Mozillians,

It is with deep sorrow that we share the news that our friend and 
colleague, Gerv Markham, passed away on July 27, 2018. Along with the 
many others whom he worked alongside over his time at Mozilla, we will 
remember Gerv as caring, honest, inquisitive, opinionated, energetic, 
and a lot of fun to work with! He enjoyed and looked forward to meeting 
with people in person, and loved diving into the details. He was often 
the first to pick up the phone to talk to people to get to the core of a 
situation. He was also quick to be helpful, going out of his way to 
provide assistance where needed. He would identify things that were in 
need of repair, meet with the owners to find out if they needed help, 
and dive right in to do the work.


Previously from Gerv: “It's been eighteen years since I first entered 
the world of Mozilla, on a program of constructing reduced layout test 
cases for early Gecko builds in order to earn a dino plushie (I got 
two!). Both I and the project have come a long way since then, but an 
ever-present companion has been my cancer, with which I was diagnosed in 
2001.”


Eighteen years is a remarkable length of time to fight against incurable 
illness, and we are proud for the fighting Gerv managed to do throughout 
those years to advance Mozilla's mission.


Over the years of Gerv’s tenure with Mozilla, he worked on public 
policy, certificate authority (CA) root program, community governance, 
MPL, licensing, usability, security, and Bugzilla. He attended every 
CA/Browser Forum face-to-face meeting that he could, and the CA/Browser 
Forum extended the attached commendation to him.


It has been an honor to work with Gerv, and it is with very fond 
memories that we say goodbye to our wonderful friend and colleague, Gerv 
Markham.


Fond Farewell,

Kathleen Wilson, Wayne Thayer, JC Jones, and Chris Riley (among many more)


PS: Here is the text from the CA/Browser Forum Commendation that is 
mentioned above.

~~
The CA/Browser Forum and its members gratefully extend to Gervase 
Markham their heartfelt commendation and appreciation
For his extraordinary leadership and skill as a founding member of the 
Forum in 2005 and as a Mozilla representative and a leading Forum 
participant from 2005–2018, and
For his superb work in promoting higher standards for Certification 
Authorities, and

For his ceaseless efforts to improve security for users on the internet, and
For sharing his deep knowledge of TLS and PKI with his fellow Forum 
members, and
For his constant innovation and improvement to the Mozilla processes 
applicable to CAs around the world, and
For his skills during Forum meetings and teleconferences so that all 
could participate on an equal basis and members’ time was well spent, and
For his ability to bridge differences of opinion among members to reach 
solutions that could be supported by all, and
For his tact and diplomacy in helping Certification Authorities and 
Browsers meet their mutual goals, and
For his patience, wit, sincerity, honesty, pleasant demeanor, and 
everlasting good cheer, and

For his superior guidance, advice, and management style.
-- For these and many other accomplishments we hereby affirm our deep 
appreciation, commendation, and congratulations to Gerv, and sincerely 
extend our best wishes to him and his family. --

Dated this 22nd day of March, 2018.
ADOPTED UNANIMOUSLY BY THE MEMBERS OF THE CA / BROWSER FORUM
~~
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

How to submit WebTrust audits in CCADB

[Kathleen Wilson via dev-security-policy]

All,

In their effort to better protect WebTrust seals, CPA Canada has made it 
so we can no longer access WebTrust pdf files directly from the CCADB.


I received the following response when inquiring about this.
“”
Thank you for contacting Chartered Professional Accountants of Canada.
You can no longer link directly to PDF documents. You will need to go to 
the registered website where the seal is provided and click on the seal 
to obtain the document (e.g. audit report).
Also, we are now enforcing the domain requirement when a seal is opened. 
 Domain enforcement is essential to the program to prevent fraudulent 
use. It ensures that the WebTrust seals will only function on the 
certificate authority’s websites.
If a seal is opened from a non-registered domain or other source (e.g. 
email, internal lists, etc.) the seal will not load and will display a 
notice indicating that the domain is not valid.

“”

Therefore, for the foreseeable future, please do the following when 
creating an Audit Case in the CCADB for WebTrust audits.


1) Make the PDFs of the audit statements available directly on your CA's 
website.

OR
Upload your audit statement PDF files to Bugzilla, as described here:
https://ccadb.org/cas/fields#uploading-documents

2) For the audit statement link in your CCADB Audit Case either provide 
the URL to the PDF on your CA's website, or use the link to the document 
in Bugzilla.


3) Add a Audit Case Comment to indicate the URL where the WebTrust seals 
may be found on your CA’s website.


4) When you run the Audit Letter Validation (ALV), you can ignore the 
“Cleaned=Fail” ALV result. I will check the seal on your website 
manually, and add a comment to the Audit Case.



Also, the cert.webtrust.org audit links that are currently in the root 
cert records and the intermediate cert records in the CCADB no longer 
work either. Fortunately we started archiving audit statements this 
year. So you can scroll down to the “File Archive…” section of the 
record, and you will be able to find the stored audit pdfs.


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 2018 Audit Reminder Emails
Date: Tue, 21 Aug 2018 19:00:10 + (GMT)

Mozilla: Audit Reminder
Root Certificates:
   AC Raíz Certicámara S.A.
Standard Audit: https://cert.webtrust.org/SealFile?seal=2333=pdf
Audit Statement Date: 2017-08-09
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Certinomis - Root CA
Standard Audit: 
https://bug937589.bmoattachments.org/attachment.cgi?id=8898169

Audit Statement Date: 2017-07-24
BR Audit: https://bug937589.bmoattachments.org/attachment.cgi?id=8898169
BR Audit Statement Date: 2017-07-24
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   E-Tugra Certification Authority
Standard Audit: 
https://www.e-tugra.com.tr/Portals/6/Documents/LSTIAL_ETugra_2017.pdf

Audit Statement Date: 2017-09-09
BR Audit: 
https://www.e-tugra.com.tr/Portals/6/Documents/LSTIAL_ETugra_2017.pdf

BR Audit Statement Date: 2017-09-09
EV Audit: 
https://www.e-tugra.com.tr/Portals/6/Documents/LSTIAL_ETugra_2017.pdf

EV Audit Statement Date: 2017-09-09
CA Comments: null



Mozilla: Audit Reminder
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://cert.webtrust.org/SealFile?seal=2332=pdf
Audit Statement Date: 2017-08-31
BR Audit: https://cert.webtrust.org/SealFile?seal=2332=pdf
BR Audit Statement Date: 2017-08-31
EV Audit: https://cert.webtrust.org/SealFile?seal=2332=pdf
EV Audit Statement Date: 2017-08-31
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   ACCVRAIZ1
Standard Audit: https://cert.webtrust.org/SealFile?seal=2299=pdf
Audit Statement Date: 2017-07-28
BR Audit: https://cert.webtrust.org/SealFile?seal=2300=pdf
BR Audit Statement Date: 2017-07-28
CA Comments: Per CA request, Root CA Generalitat Valenciana will be 
removed via https://bugzilla.mozilla.org/show_bug.cgi?id=1272158




Mozilla: Audit Reminder
Root Certificates:
   IdenTrust Commercial Root CA 1**
   IdenTrust Public Sector Root CA 1**
   DST Root CA X3**

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


Standard Audit: https://cert.webtrust.org/SealFile?seal=2331=pdf
Audit Statement Date: 2017-08-31
BR Audit: https://cert.webtrust.org/SealFile?seal=2334=pdf
BR Audit Statement Date: 2017-09-18
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Izenpe.com
Standard Audit: 
http://www.izenpe.eus/contenidos/informacion/auditorias_acreditaciones/en_def/adjuntos/6757_Izenpe_Browser_Attestation_2017.pdf

Audit Statement Date: 2017-07-25
BR Audit: 
http://www.izenpe.eus/contenidos/informacion/auditorias_acreditaciones/en_def/adjuntos/6757_Izenpe_Browser_Attestation_2017.pdf

BR Audit Statement Date: 2017-07-25
EV Audit: 
http://www.izenpe.eus/contenidos/informacion/auditorias_acreditaciones/en_def/adjuntos/6757_Izenpe_Browser_Attestation_2017.pdf

EV Audit Statement Date: 2017-07-25
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   OpenTrust Root CA G1
   OpenTrust Root CA G2
   Certplus Root CA G1
   Class 2 Primary CA
   OpenTrust Root CA G3
   Certplus Root CA G2
Standard Audit: 
https://bug1297034.bmoattachments.org/attachment.cgi?id=8916590

Audit Statement Date: 2017-07-24
BR Audit: https://bug1297034.bmoattachments.org/attachment.cgi?id=8916590
BR Audit Statement Date: 2017-07-24
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   SECOM Trust.net - Security Communication RootCA1
   Security Communication RootCA2
Standard Audit: https://cert.webtrust.org/SealFile?seal=2321=pdf
Audit Statement Date: 2017-08-31
BR Audit: https://cert.webtrust.org/SealFile?seal=2323=pdf
BR Audit Statement Date: 2017-08-31
EV Audit: https://cert.webtrust.org/SealFile?seal=2322=pdf
EV Audit Statement Date: 2017-08-31
CA Comments: null



Mozilla: Overdue Audit Statements
Root Certificates:
   SwissSign Platinum CA - G2**

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


Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8861552
Audit Statement Date: 2017-03-30
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8861552
BR Audit Statement Date: 2017-03-30
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Visa eCommerce Root
Standard Audit: http://enroll.visaca.com/WTCA%20eComm.pdf
Audit Statement Date: 2017-07-26
BR Audit: http://enroll.visaca.com/WTBR%20eComm.pdf
BR Audit Statement Date: 2017-07-26
CA Comments: null



Mozilla: Audit Reminder
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://www.ssl.com/app/uploads/2017/07/SSL-COM-WTCA-Indp-Accountant-Report-and-Mgmt-Assertion-FINAL-2017.pdf

Audit Statement Date: 2017-07-27
BR Audit: 

Re: Audit Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of July 2018 Audit Reminder Emails
Date: Tue, 17 Jul 2018 19:00:10 + (GMT)

Mozilla: Audit Reminder
Root Certificates:
   LuxTrust Global Root 2
Standard Audit: 
https://www.luxtrust.lu/upload/data/repository/attestation_letter_luxtrust_2017_s.pdf

Audit Statement Date: 2017-07-24
BR Audit: 
https://www.luxtrust.lu/upload/data/repository/attestation_letter_luxtrust_2017_s.pdf

BR Audit Statement Date: 2017-07-24
EV Audit: 
https://www.luxtrust.lu/upload/data/repository/attestation_letter_luxtrust_2017_s.pdf

EV Audit Statement Date: 2017-07-24
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Atos TrustedRoot 2011
Standard Audit: 
https://www.mydqs.com/kunden/kundendatenbank.html?aoemydqs%5BrequestId%5D=europev2-DQS-00DCD7AE71E211E7B653005056A04F41-_v2%5BdownloadKey%5D=91bdb1288df96a7e719d7ebcad82dc822d5b1a65%5Baction%5D=downloadDocument=f4c93332780df1788265

Audit Statement Date: 2017-06-14
BR Audit: 
https://www.mydqs.com/kunden/kundendatenbank.html?aoemydqs%5BrequestId%5D=europev2-DQS-00DCD7AE71E211E7B653005056A04F41-_v2%5BdownloadKey%5D=91bdb1288df96a7e719d7ebcad82dc822d5b1a65%5Baction%5D=downloadDocument=f4c93332780df1788265

BR Audit Statement Date: 2017-06-14
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Chambers of Commerce Root
   Chambers of Commerce Root - 2008
   Global Chambersign Root
   Global Chambersign Root - 2008
Standard Audit: https://cert.webtrust.org/SealFile?seal=2283=pdf
Audit Statement Date: 2017-07-10
BR Audit: https://cert.webtrust.org/SealFile?seal=2284=pdf
BR Audit Statement Date: 2017-07-10
EV Audit: https://cert.webtrust.org/SealFile?seal=2285=pdf
EV Audit Statement Date: 2017-07-10
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   AC Raíz Certicámara S.A.
Standard Audit: https://cert.webtrust.org/SealFile?seal=2333=pdf
Audit Statement Date: 2017-08-09
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Certinomis - Root CA
Standard Audit: 
https://bug937589.bmoattachments.org/attachment.cgi?id=8898169

Audit Statement Date: 2017-07-24
BR Audit: https://bug937589.bmoattachments.org/attachment.cgi?id=8898169
BR Audit Statement Date: 2017-07-24
CA Comments: null



Mozilla: Audit Reminder
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
   UTN-USERFirst-Client Authentication and Email
   USERTrust RSA Certification Authority
Standard Audit: https://cert.webtrust.org/SealFile?seal=2270=pdf
Audit Statement Date: 2017-06-02
BR Audit: https://cert.webtrust.org/SealFile?seal=2274=pdf
BR Audit Statement Date: 2017-06-02
BR Audit:
BR Audit Statement Date:
EV Audit: https://cert.webtrust.org/SealFile?seal=2272=pdf
EV Audit Statement Date: 2017-06-02
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   GlobalSign
   GlobalSign
   GlobalSign Root CA
   GlobalSign Extended Validation CA - SHA256 - G2
Standard Audit: https://cert.webtrust.org/SealFile?seal=2287=pdf
Audit Statement Date: 2017-07-26
BR Audit: https://cert.webtrust.org/SealFile?seal=2338=pdf
BR Audit Statement Date: 2017-09-22
EV Audit: https://cert.webtrust.org/SealFile?seal=2288=pdf
EV Audit Statement Date: 2017-07-26
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   ACCVRAIZ1
Standard Audit: https://cert.webtrust.org/SealFile?seal=2299=pdf
Audit Statement Date: 2017-07-28
BR Audit: https://cert.webtrust.org/SealFile?seal=2300=pdf
BR Audit Statement Date: 2017-07-28
CA Comments: Per CA request, Root CA Generalitat Valenciana will be 
removed via https://bugzilla.mozilla.org/show_bug.cgi?id=1272158




Mozilla: Audit Reminder
Root Certificates:
   Izenpe.com
Standard Audit: 
http://www.izenpe.eus/contenidos/informacion/auditorias_acreditaciones/en_def/adjuntos/6757_Izenpe_Browser_Attestation_2017.pdf

Audit Statement Date: 2017-07-25
BR Audit: 
http://www.izenpe.eus/contenidos/informacion/auditorias_acreditaciones/en_def/adjuntos/6757_Izenpe_Browser_Attestation_2017.pdf

BR Audit Statement Date: 2017-07-25
EV Audit: 
http://www.izenpe.eus/contenidos/informacion/auditorias_acreditaciones/en_def/adjuntos/6757_Izenpe_Browser_Attestation_2017.pdf

EV Audit Statement Date: 2017-07-25
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   OpenTrust Root CA G1
   OpenTrust Root CA G2
   Certplus Root CA G1
   Class 2 Primary CA
   OpenTrust Root CA G3
   Certplus Root CA G2
Standard Audit: 
https://bug1297034.bmoattachments.org/attachment.cgi?id=8916590

Audit Statement Date: 2017-07-24
BR Audit: https://bug1297034.bmoattachments.org/attachment.cgi?id=8916590
BR Audit Statement Date: 2017-07-24
EV Audit: https://bug1297034.bmoattachments.org/attachment.cgi?id=8916590
EV Audit Statement Date: 2017-07-24
CA Comments: null

Re: Add Wayne Thayer as Peer of Mozilla's CA Certificates and CA Certificate Policy modules

[Kathleen Wilson via dev-security-policy]

On 1/16/18 2:03 PM, Kathleen Wilson wrote:

All,

I propose adding Wayne Thayer as a peer[1] of Mozilla's CA Certificates 
Module[2] and CA Certificate Policy Module[3]. As you know, Wayne and I 
are distributing the job of running Mozilla's CA Program between us, so 
he will be actively working 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 Wayne Thayer 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: ccadb.org

[Kathleen Wilson via dev-security-policy]

On 2/9/18 7:52 AM, Kathleen Wilson wrote:

On 2/7/18 11:41 AM, Kathleen Wilson wrote:

All,

At 6pm PST on Thursday, February 8th, we will begin the migration of 
ccadb.org to https.


It is possible that during this migration users may receive errors 
when trying to access the ccadb.org site.



All,

Something went wrong, so the changes had to be rolled back.

Stay tuned...

Kathleen



The team is going to attempt to migrate ccadb.org from http to https on 
the evening of Thursday, March 8. It is possible that during this 
migration users may receive errors when trying to access the ccadb.org site.


A fix has been implemented for the problem that was encountered the last 
time the migration was attempted.


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

Re: Mozilla Security Blog re Symantec TLS Certs

[Kathleen Wilson via dev-security-policy]

As I didn't write the blog post, I certainly can't speak to the
intent 




The intent of the blog post was to let folks know about an error they 
may encounter when Firefox 60 goes into Beta. And to have a place to 
point folks to if they run into the error and ask about it.


It was *not* our intent to imply any deviation from the consensus proposal.

If clarification is needed, let's update the wiki page to add it:

https://wiki.mozilla.org/CA/Additional_Trust_Changes#Symantec

Please let me and Wayne know what changes you think should be made to 
the wiki page to clarify the changes.


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

Re: ccadb.org

[Kathleen Wilson via dev-security-policy]

The ccadb.org site is now https.

Please let me know if you run into any problems with the ccadb.org site.

Thanks for your patience.

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

Mozilla Security Blog re Symantec TLS Certs

[Kathleen Wilson via dev-security-policy]

All,

Wayne and I have posted a Mozilla Security Blog regarding the current 
plan for distrusting the Symantec TLS certs.


https://blog.mozilla.org/security/2018/03/12/distrust-symantec-tls-certificates/

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]

Here's the summary of the audit reminder email that was sent last 
Tuesday, while I was on Spring Break.


Kathleen

 Forwarded Message 
Subject:Summary of April 2018 Audit Reminder Emails
Date:   Tue, 17 Apr 2018 19:00:32 + (GMT)
From:   Mozilla CA Program Manager 
To: kwil...@mozilla.com 


Mozilla: Audit Reminder
Root Certificates:
   GDCA TrustAUTH R5 ROOT
Standard Audit: https://cert.webtrust.org/SealFile?seal=2231=pdf
Audit Statement Date: 2017-04-14
BR Audit: https://cert.webtrust.org/SealFile?seal=2232=pdf
BR Audit Statement Date: 2017-04-14
EV Audit: https://cert.webtrust.org/SealFile?seal=2233=pdf
EV Audit Statement Date: 2017-04-14
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   SZAFIR ROOT CA2**

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


Standard Audit: https://cert.webtrust.org/SealFile?seal=2239=pdf
Audit Statement Date: 2017-04-12
BR Audit: https://cert.webtrust.org/SealFile?seal=2239=pdf
BR Audit Statement Date: 2017-04-12
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   ComSign CA
Standard Audit: 
https://bug1368471.bmoattachments.org/attachment.cgi?id=8872330

Audit Statement Date: 2017-04-26
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   SecureSign RootCA11
Standard Audit: https://cert.webtrust.org/SealFile?seal=2251=pdf
Audit Statement Date: 2017-05-10
BR Audit: https://bug1369520.bmoattachments.org/attachment.cgi?id=8873589
BR Audit Statement Date: 2017-05-10
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Baltimore CyberTrust Root
   Cybertrust Global Root
   DigiCert Assured ID Root CA
   DigiCert Assured ID Root G2
   DigiCert Assured ID Root G3
   DigiCert High Assurance EV Root CA
   DigiCert Trusted Root G4
Standard Audit: https://cert.webtrust.org/SealFile?seal=2228=pdf
Audit Statement Date: 2017-04-13
BR Audit: https://cert.webtrust.org/SealFile?seal=2229=pdf
BR Audit Statement Date: 2017-04-13
EV Audit: https://cert.webtrust.org/SealFile?seal=2230=pdf
EV Audit Statement Date: 2017-04-13
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   SwissSign Platinum CA - G2
   SwissSign Silver CA - G2
Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8861552
Audit Statement Date: 2017-03-30
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8861552
BR Audit Statement Date: 2017-03-30
CA Comments: null



Mozilla: Audit Reminder
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=8862399

Audit Statement Date: 2017-03-01
BR Audit: https://bug1360184.bmoattachments.org/attachment.cgi?id=8862399
BR Audit Statement Date: 2017-03-01
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Amazon Root CA 3**
   Amazon Root CA 2**
   Starfield Services Root Certificate Authority - G2**
   Amazon Root CA 1**
   Amazon Root CA 4**

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


Standard Audit: https://cert.webtrust.org/SealFile?seal=2217=pdf
Audit Statement Date: 2017-03-28
BR Audit: https://cert.webtrust.org/SealFile?seal=2218=pdf
BR Audit Statement Date: 2017-03-28
EV Audit: https://cert.webtrust.org/SealFile?seal=2219=pdf
EV Audit Statement Date: 2017-03-28
CA Comments: null





___
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 2018 Audit Reminder Emails
Date: Tue, 20 Mar 2018 19:00:18 + (GMT)

Mozilla: Audit Reminder
Root Certificates:
   GDCA TrustAUTH R5 ROOT
Standard Audit: https://cert.webtrust.org/SealFile?seal=2231=pdf
Audit Statement Date: 2017-04-14
BR Audit: https://cert.webtrust.org/SealFile?seal=2232=pdf
BR Audit Statement Date: 2017-04-14
EV Audit: https://cert.webtrust.org/SealFile?seal=2233=pdf
EV Audit Statement Date: 2017-04-14
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   SZAFIR ROOT CA2
Standard Audit: https://cert.webtrust.org/SealFile?seal=2239=pdf
Audit Statement Date: 2017-04-12
BR Audit: https://cert.webtrust.org/SealFile?seal=2239=pdf
BR Audit Statement Date: 2017-04-12
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   certSIGN ROOT CA**

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


Standard Audit: 
https://www.certsign.ro/certsign_en/files/certSIGN_Webtrust_CA_8.02.2017.pdf

Audit Statement Date: 2017-02-08
BR Audit: 
https://www.certsign.ro/certsign_en/files/certSIGN_Webtrust_CA_8.02.2017.pdf

BR Audit Statement Date: 2017-02-08
CA Comments: Previous audit statement date was same as audit period end 
date, Feb 8 2017. The 2018 audit period end date is Feb 7 2018, which 
means CertSign has until early May 2018 to provide their new audit 
statement.




Mozilla: Audit Reminder
Root Certificates:
   Baltimore CyberTrust Root
   Cybertrust Global Root
   DigiCert Assured ID Root CA
   DigiCert Assured ID Root G2
   DigiCert Assured ID Root G3
   DigiCert High Assurance EV Root CA
   DigiCert Trusted Root G4
Standard Audit: https://cert.webtrust.org/SealFile?seal=2228=pdf
Audit Statement Date: 2017-04-13
BR Audit: https://cert.webtrust.org/SealFile?seal=2229=pdf
BR Audit Statement Date: 2017-04-13
EV Audit: https://cert.webtrust.org/SealFile?seal=2230=pdf
EV Audit Statement Date: 2017-04-13
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Hongkong Post Root CA 1
Standard Audit: https://cert.webtrust.org/SealFile?seal=2208=pdf
Audit Statement Date: 2017-02-28
BR Audit: 
http://www.hongkongpost.gov.hk/product/cps/ecert/img/HKPCA_WebTrust_BR_2016-17.pdf

BR Audit Statement Date: 2017-02-28
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Class 2 Primary CA
Standard Audit: 
https://bug1297034.bmoattachments.org/attachment.cgi?id=8849236

Audit Statement Date: 2017-01-14
BR Audit: https://bug1297034.bmoattachments.org/attachment.cgi?id=8849236
BR Audit Statement Date: 2017-01-14
EV Audit: https://bug1297034.bmoattachments.org/attachment.cgi?id=8849236
EV Audit Statement Date: 2017-01-14
CA Comments: null



Mozilla: Audit Reminder
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://cert.webtrust.org/SealFile?seal=2223=pdf
Audit Statement Date: 2017-03-31
BR Audit: https://cert.webtrust.org/SealFile?seal==pdf
BR Audit Statement Date: 2017-03-31
EV Audit: https://cert.webtrust.org/SealFile?seal=2221=pdf
EV Audit Statement Date: 2017-03-31
CA Comments: 
https://www.wisekey.com/investors_press-release/wisekey-sixwihn-signs-letter-of-intent-to-acquire-quovadis-consolidating-certification-authority-power-for-eidas-and-iot




Mozilla: Audit Reminder
Root Certificates:
   SwissSign Platinum CA - G2
   SwissSign Silver CA - G2
Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8861552
Audit Statement Date: 2017-03-30
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8861552
BR Audit Statement Date: 2017-03-30
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   TWCA Global Root CA
   TWCA Root Certification Authority
Standard Audit: https://cert.webtrust.org/SealFile?seal=2197=pdf
Audit Statement Date: 2017-02-16
BR Audit: https://cert.webtrust.org/SealFile?seal=2195=pdf
BR Audit Statement Date: 2017-02-16
EV Audit: https://cert.webtrust.org/SealFile?seal=2196=pdf
EV Audit Statement Date: 2017-02-16
CA Comments: null



Mozilla: Audit Reminder
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=8862399

Audit Statement Date: 2017-03-01
BR Audit: https://bug1360184.bmoattachments.org/attachment.cgi?id=8862399
BR Audit Statement Date: 2017-03-01
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı H5
Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8828490
Audit Statement Date: 2016-12-31
BR Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/6749UE_s.pdf

BR Audit Statement Date: 2016-12-31
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
  

Re: Audit Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

On 3/20/18 12:43 PM, Kurt Roeckx wrote:

On Tue, Mar 20, 2018 at 12:07:54PM -0700, Kathleen Wilson via 
dev-security-policy wrote:

Mozilla: Audit Reminder
Root Certificates:
Class 2 Primary CA
Standard Audit:
https://bug1297034.bmoattachments.org/attachment.cgi?id=8849236
Audit Statement Date: 2017-01-14
BR Audit: https://bug1297034.bmoattachments.org/attachment.cgi?id=8849236
BR Audit Statement Date: 2017-01-14
EV Audit: https://bug1297034.bmoattachments.org/attachment.cgi?id=8849236
EV Audit Statement Date: 2017-01-14
CA Comments: null


The audit period was 2015-10-14 to 2016-10-14, we should already
have received a new audit statement.


Kurt



Bug filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1447497

Thanks,
Kathleen

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

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Kathleen Wilson via dev-security-policy]

Based on the input into this discussion so far, I propose to add the 
following section to the Required part of this wiki page:

https://wiki.mozilla.org/CA/Required_or_Recommended_Practices

We can consider adding text about this directly to Mozilla's Root Store 
Policy later. (I'll file the request/issue in github.)


-- Proposed Text --
Section Heading: CP/CPS Structured According to RFC 3647

CP/CPS documents must be structured according to RFC 3647. This 
requirement is stated in section 2.2 of the CA/Browser Forum Baseline 
Requirements, with the effective of 31 May 2018. Further, CP/CPS 
documents should include every component and subcomponent, and the 
placement of information should be aligned with the BRs; e.g. domain 
validation practices should be documented in section 3.2.2.4 of the CA’s 
CP/CPS.


The words "No Stipulation" mean that the particular document imposes no 
requirements related to that section.


Any CPS that falls within the scope of Mozilla’s program must not use 
the words “No stipulation” unless the corresponding section in the 
CA/Browser Forum Baseline Requirements state “No stipulation”, “Not 
applicable”, or is blank. The words “Not applicable” are acceptable to 
indicate that the CA’s policies forbid the practice that is the title of 
the section. Language similar to “We do not perform section>” is preferred. If a full description of a section is repeated 
elsewhere in the document, language similar to “Refer to Section 1.2.3” 
is preferred.


Examples:
- If your CA does not allow a particular domain validation method to be 
used, then the CP or CPS should say that, e.g. "This method of domain 
validation is not used".
- The BRs do not allow certificate suspension, so the CA’s CPS must 
state that certificate suspension is not allowed, and then the other 
sections related to suspension should say “Not applicable”.
- If your CA does not issue SSL certs containing IP addresses, then 
section 3.2.2.5, ‘Authentication for an IP Address’ in your CP or CPS 
should say that such certificate issuance is not allowed; e.g. “No IP 
address certificates are issued under this CPS.”



I will appreciate your constructive feedback on this.

Thanks,
Kathleen



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

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Kathleen Wilson via dev-security-policy]

I have added the following section to the Required Practices wiki page:

https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#BR_Commitment_to_Comply_statement_in_CP.2FCPS

I will continue to appreciate feedback on this update.

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

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Kathleen Wilson via dev-security-policy]

On 10/15/18 11:01 AM, Kathleen Wilson wrote:

I have added the following section to the Required Practices wiki page:

https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#BR_Commitment_to_Comply_statement_in_CP.2FCPS 



I will continue to appreciate feedback on this update.

Thanks,
Kathleen



Oops... here's the correct link:

https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Structured_According_to_RFC_3647




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

Re: CCADB System Upgrades October 15, 8am-6pm Pacific Time

[Kathleen Wilson via dev-security-policy]

All,

The CCADB system upgrades are in progress, so there will be limited 
functionality today. Best to avoid logging into CCADB today if you can.


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 2018 Audit Reminder Emails
Date: Tue, 16 Oct 2018 19:00:37 + (GMT)

Mozilla: Audit Reminder
Root Certificates:
   AC Raíz Certicámara S.A.
Standard Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221203

Audit Statement Date: 2017-08-09
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Certinomis - Root CA
Standard Audit: 
https://bug937589.bmoattachments.org/attachment.cgi?id=8898169

Audit Statement Date: 2017-07-24
BR Audit: https://bug937589.bmoattachments.org/attachment.cgi?id=8898169
BR Audit Statement Date: 2017-07-24
CA Comments: null



Mozilla: Audit Reminder
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: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221042

Audit Statement Date: 2017-08-31
BR Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221042

BR Audit Statement Date: 2017-08-31
EV Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221042

EV Audit Statement Date: 2017-08-31
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   ACCVRAIZ1
Standard Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221168

Audit Statement Date: 2017-07-28
BR Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221169

BR Audit Statement Date: 2017-07-28
CA Comments: Per CA request, Root CA Generalitat Valenciana will be 
removed via https://bugzilla.mozilla.org/show_bug.cgi?id=1272158




Mozilla: Audit Reminder
Root Certificates:
   NetLock Arany (Class Gold) Főtanúsítvány
Standard Audit: 
http://www.netlock.hu/docs/dokumentumok/Certificate%20ETSI%20ENG.pdf

Audit Statement Date: 2017-10-05
BR Audit: 
http://www.netlock.hu/docs/dokumentumok/Certificate%20ETSI%20ENG.pdf

BR Audit Statement Date: 2017-10-05
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   CFCA EV ROOT
Standard Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221153

Audit Statement Date: 2017-11-10
BR Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221154

BR Audit Statement Date: 2017-11-10
EV Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221155

EV Audit Statement Date: 2017-11-10
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   GlobalSign
   GlobalSign
Standard Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221087

Audit Statement Date: 2017-10-31
BR Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221088

BR Audit Statement Date: 2017-11-01
CA Comments: null




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

Re: CCADB System Upgrades October 15, 8am-6pm Pacific Time

[Kathleen Wilson via dev-security-policy]

The CCADB system updates are complete, and access has been restored to 
normal.


Please send me email if you run into any 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

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Kathleen Wilson via dev-security-policy]

On 10/18/18 2:03 PM, Joanna Fox wrote:

https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Structured_According_to_RFC_3647


For clarification on this statement, "Any CPS that falls within the scope of 
Mozilla’s program must not use the words “No stipulation” unless the corresponding 
section in the CA/Browser Forum Baseline Requirements state “No stipulation”, “Not 
applicable”, or is blank."

Is the intent to use No stipulation”, “Not applicable”, or blank 
interchangeably?



No. The intent of that statement was to limit the sections for which the 
CA's CP/CPS may use the words "No stipulation".


Do you have a suggestion about how to make this more clear?

Note that just before that sentence is:
"The words "No Stipulation" mean that the particular document imposes no 
requirements related to that section."


And the following sentence says:
"The words “Not applicable” are acceptable to indicate that the CA’s 
policies forbid the practice that is the title of the section."


To me, those mean very different things.


We did not define what a blank section means...

I think that a blank section means the same thing as "No stipulation". 
Should we require that sections not be left blank?


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

Re: New Module Owner for CA Certificate Policy

[Kathleen Wilson via dev-security-policy]

I have made this change:
https://wiki.mozilla.org/Modules/All#Mozilla_CA_Certificate_Policy

Thanks,
Kathleen

On 10/13/18 9:39 AM, Kathleen Wilson wrote:

All, I posted the following in the mozilla.governance forum.

Please feel free to comment here in m.d.s.policy, if you would like.

~~

I’m proposing to make Wayne Thayer the new owner of the “CA Certificate 
Policy” module. In his role at Mozilla, Wayne has been driving updates 
to Mozilla’s Root Store Policy and has been enforcing Mozilla’s policies 
governing Certification Authorities (CAs) for the past year. Wayne led 
the effort to release versions 2.6 and 2.6.1 of Mozilla’s Root Store 
Policy[1], has helped resolve over 70 CA compliance bugs[2], and is 
actively pursuing resolution to over 50 open CA compliance bugs[3].


There are two modules related to Mozilla’s CA Program which govern the 
default set of certificates in Network Security Services (NSS) and 
distributed in Mozilla’s software products. They are:


1) Mozilla CA Certificate Policy[4]
Description: Definition and enforcement of policies governing 
Certification Authorities, their root certificates included in Mozilla 
software products, and intermediate and end-entity certificates within 
those CA hierarchies.

Current Owner: Kathleen Wilson -- Proposed Owner: Wayne Thayer
Current Peer(s): Wayne Thayer -- Proposed Peer: Kathleen Wilson

2) CA Certificates[5]
Description: Determine which root certificates should be included in 
Mozilla software products, which trust bits should be set on them, and 
which of them should be enabled for EV treatment. Evaluate requests from 
Certification Authorities (CAs) for inclusion or removal of root 
certificates, and for updating trust bit settings or enabling EV 
treatment for already included root certificates.

Owner: Kathleen Wilson  -- no change
Peer(s): Ryan Sleevi, Wayne Thayer -- no change

Thanks,
Kathleen

[1] https://blog.mozilla.org/security/2018/07/02/root-store-policy-updated/
[2] https://wiki.mozilla.org/CA/Closed_Incidents
[3] https://wiki.mozilla.org/CA/Incident_Dashboard
[4] https://wiki.mozilla.org/Modules/All#Mozilla_CA_Certificate_Policy
[5] https://wiki.mozilla.org/Modules/All#CA_Certificates

~~



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

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Kathleen Wilson via dev-security-policy]

I have updated the section as follows:
- Removed the sentence that was trying to limit the use of "No 
Stipulation". Hopefully the clarification about what these words mean is 
sufficient.

- Added bullet points
- Added "Sections MUST not be left blank. ..."

https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Structured_According_to_RFC_3647


I continue to appreciate your feedback on this new section.

Thanks,
Kathleen


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

New Module Owner for CA Certificate Policy

[Kathleen Wilson via dev-security-policy]

All, I posted the following in the mozilla.governance forum.

Please feel free to comment here in m.d.s.policy, if you would like.

~~

I’m proposing to make Wayne Thayer the new owner of the “CA Certificate 
Policy” module. In his role at Mozilla, Wayne has been driving updates 
to Mozilla’s Root Store Policy and has been enforcing Mozilla’s policies 
governing Certification Authorities (CAs) for the past year. Wayne led 
the effort to release versions 2.6 and 2.6.1 of Mozilla’s Root Store 
Policy[1], has helped resolve over 70 CA compliance bugs[2], and is 
actively pursuing resolution to over 50 open CA compliance bugs[3].


There are two modules related to Mozilla’s CA Program which govern the 
default set of certificates in Network Security Services (NSS) and 
distributed in Mozilla’s software products. They are:


1) Mozilla CA Certificate Policy[4]
Description: Definition and enforcement of policies governing 
Certification Authorities, their root certificates included in Mozilla 
software products, and intermediate and end-entity certificates within 
those CA hierarchies.

Current Owner: Kathleen Wilson -- Proposed Owner: Wayne Thayer
Current Peer(s): Wayne Thayer -- Proposed Peer: Kathleen Wilson

2) CA Certificates[5]
Description: Determine which root certificates should be included in 
Mozilla software products, which trust bits should be set on them, and 
which of them should be enabled for EV treatment. Evaluate requests from 
Certification Authorities (CAs) for inclusion or removal of root 
certificates, and for updating trust bit settings or enabling EV 
treatment for already included root certificates.

Owner: Kathleen Wilson  -- no change
Peer(s): Ryan Sleevi, Wayne Thayer -- no change

Thanks,
Kathleen

[1] https://blog.mozilla.org/security/2018/07/02/root-store-policy-updated/
[2] https://wiki.mozilla.org/CA/Closed_Incidents
[3] https://wiki.mozilla.org/CA/Incident_Dashboard
[4] https://wiki.mozilla.org/Modules/All#Mozilla_CA_Certificate_Policy
[5] https://wiki.mozilla.org/Modules/All#CA_Certificates

~~

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

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Kathleen Wilson via dev-security-policy]

On 10/15/18 12:48 AM, Pedro Fuentes wrote:

Hello,
I've a question closely related to this. I'd appreciate guidance.

I'm refactoring our CP & CPS documents considering that a CA can issue 
different types of certificates, so there would be multiple CP and one CPS.

My strategy is that if the stipulation is defined in one of the document (CP or 
CPS), then the other document can refer to the other (CPS or CP).

So, for example, as the CPS will support/implement different CP, for certain aspects (i.e. 
suspension), I'd like to refer to the CP as source, with the text "As stipulated in the 
appropriate CP". Like wise, in certain cases the stipulation could be defined in the CPS, so 
the CP would have the text "As stipulated in the CPS". This means that someone evaluating 
the practices for SSL certificates would have to consider jointly the CP of SSL certificates and 
the CPS, while someone evaluating personal certificates for email should consider the CP for S/MIME 
certificates and the CPS.

I used this in the past while writing some docs for customers... Would this be 
cross-referencing still acceptable?

Thanks,
Pedro



Yes, cross-referencing is still acceptable, as long as it is very clear 
which root certificates each CP and CPS document governs.


Thanks,
Kathleen


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

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Kathleen Wilson via dev-security-policy]

I have updated this section in the wiki page again as follows:
- Changed the word 'must' to 'should' for items that are not currently 
in Mozilla's Root Store Policy or the BRs. We plan to change these back 
to 'must' after Wayne updates Mozilla's Root Store Policy regarding this 
topic.
- Added notes/warnings that Mozilla's root store policy may be updated 
soon to forbid use of blank sections and "No Stipulation".
- Added bullet point about clarifying in the CP/CPS when certain 
sections (like private key generation and escrow) only apply to certain 
types of certificates.


https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Structured_According_to_RFC_3647

Thanks,
Kathleen

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

What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?

[Kathleen Wilson via dev-security-policy]

All,

I would like to create some written rules about using "No Stipulation" 
in CP and CPS documents; e.g. what it means, and when it is OK to be used.


First, I will appreciate your thoughts about what the term "No 
Stipulation" means. e.g. does it mean one or all of the following?

 "No rules defined for this section"
 "This section is not applicable"
 "This section is not allowed"
 "This section is not used"

Can "No Stipulation" mean different things based on the context of the 
section?

For example
"1.3.5 Other Participants
No stipulation."
Does that mean “no other participants are allowed”?

Here is what RFC 3647 says about the term:
""
While many topics are identified, it is not necessary for a CP or a
   CPS to include a concrete statement for every such topic.  Rather, a
   particular CP or CPS may state "no stipulation" for a component,
   subcomponent, or element on which the particular CP or CPS imposes no
   requirements or makes no disclosure.  In this sense, the list of
   topics can be considered a checklist of topics for consideration by
   the CP or CPS writer.

   It is recommended that each and every component and subcomponent be
   included in a CP or CPS, even if there is "no stipulation"; this will
   indicate to the reader that a conscious decision was made to include
   or exclude a provision concerning that topic.  This drafting style
   protects against inadvertent omission of a topic, while facilitating
   comparison of different certificate policies or CPSs, e.g., when
   making policy mapping decisions.
""

It seems a little ambiguous to me, so I would like to have a written 
statement about what "No Stipulation" means within CP and CPS documents, 
especially in regards to SSL certificate issuance.


Here are two examples that I've seen recently.

== Example 1 ==
In this situation, the CA has one CP that covers different types of 
roots, so the CPS for the different roots has the details. There is no 
further detailed public documentation beyond the CPS.


In the CA's CP:
3.1.2 Need for Names to be Meaningful
No Stipulation
3.1.5 Uniqueness of Names
No Stipulation
3.2.2.1 Identity
No Stipulation
3.2.2.2 DBA/Tradename
No Stipulation
3.2.2.3 Verification of Country
No Stipulation
3.2.2.4 Validation of Domain Authorization or Control
No Stipulation
3.2.2.4.1 Validating the Applicant as a Domain Contact
No Stipulation
3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact
No Stipulation
3.2.2.4.3 Phone Contact with Domain Contact
No Stipulation
3.2.2.4.4 Constructed Email to Domain Contact
No Stipulation
3.2.2.4.5 Domain Authorization Document
No Stipulation
3.2.2.4.6 Agreed-Upon Change to Website
No Stipulation
3.2.2.4.7 DNS Change
No Stipulation
3.2.2.4.8 IP Address
No Stipulation
3.2.2.4.9 Test Certificate
No Stipulation
3.2.2.4.10 TLS Using a Random Number
No Stipulation
3.2.2.4.11 Any Other Method
This method has been retired and MUST NOT be used.
3.2.2.4.12 Validating Applicant as a Domain Contact
No Stipulation
3.2.2.5 Authentication for an IP Address
No Stipulation
3.2.2.6 Wildcard Domain Validation
No Stipulation
3.2.2.7 Data Source Accuracy
No Stipulation
3.2.2.8 CAA Records
No Stipulation
3.2.3 Authentication of Individual Identity
No Stipulation
3.2.4 Non-Verified Subscriber Information
No Stipulation
4.7.4 Notification of New Certificate Issuance to Subscriber
No stipulation
4.9.7 CRL Issuance Frequency
No Stipulation.
4.9.10 On-Line Revocation Checking Requirements
No Stipulation
5.4.6 Audit Log Accumulation System (Internal vs. External)
No Stipulation
6.1.5 Key Sizes
No Stipulation
6.2.3 Private Key Escrow
No Stipulation
6.2.5 Private Key Archival
No Stipulation
6.2.6 Private Key Transfer into or from a Cryptographic Module
No Stipulation
6.2.9 Deactivating Private Keys
No Stipulation
6.3.2 Certificate Operational Periods and Key Pair Usage Periods
No Stipulation
6.7 NETWORK SECURITY CONTROLS
No stipulation

The relevant CPS has the following sections with No Stipulation:
3.1.5 Uniqueness of Names
No Stipulation
3.2.2.5 Authentication for an IP Address
No Stipulation
3.2.2.6 Wildcard Domain Validation
No Stipulation
4.7.4 Notification of New Certificate Issuance to Subscriber
No Stipulation
5.4.6 Audit Log Accumulation System (Internal vs. External)
No Stipulation
6.2.3 Private Key Escrow
No Stipulation
6.2.5 Private Key Archival
No Stipulation
6.2.6 Private Key Transfer into or from a Cryptographic Module
No Stipulation
6.2.9 Deactivating Private Keys
No Stipulation

In this example you can see that the CA clarifies in the CPS which 
domain validation methods can be used.


I'm not sure how to interpret the sections listed above that have "No 
Stipulation" in both the CP and the CPS.


For instance, when I see "3.2.2.5 Authentication for an IP Address" with 
"No Stipulation" in the CPS, it is not clear to me if the CA does not 
allow for IP Addresses to be included in SSL certs, or if the CA just 
allows any form of verification of IP Addresses.




== 

CCADB System Upgrades October 15, 8am-6pm Pacific Time

[Kathleen Wilson via dev-security-policy]

All,

We will be doing system upgrades to the CCADB on Monday, October 15, 
8am-6pm Pacific Time. There will be limited functionality during that time.


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

Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS

[Kathleen Wilson via dev-security-policy]

Oh, so rather than trying to define what "No Stipulation" means and when 
it can be used, we could take a different approach -- list the sections 
that cannot contain "No Stipulation" in the CPS.



On 10/9/18 12:31 PM, Brown, Wendy (10421) wrote:

Tim  -

I think that statement leaves out the next paragraph of RFC3647:
In a CP, it is possible to leave certain components, subcomponents, and/or 
elements unspecified, and to stipulate that the required information will be 
indicated in a policy qualifier, or the document to which a policy qualifier 
points. Such CPs can be considered parameterized definitions. The set of 
provisions should reference or define the required policy qualifier types and 
should specify any applicable default values.

I think normally the policy qualifier points to a CPS, but it might be some 
other document.
But in any case if both CP & CPS say "No stipulation" in regards to something that 
Mozilla cares about like what validation methods are supported for TLS certificates, then it is very 
hard to evaluate that set of "disclosed business practices" to determine if the CA operates 
in accord with the BRs or Mozilla's policy.
I think there may be some sections of a CP/CPS that are less critical, but in terms of any 
section that is critical to the evaluation for inclusion in a particular trust store, I would 
expect one of the 2 documents to clearly state the operational practices of the CA rather 
than just stating "No Stipulation" in both CP & CPS, unless the Policy 
Qualifier in issued certificates points to some other document that contains that information.

Again - just my personal opinion.

 wendy




___
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 2018 Audit Reminder Emails
Date: Tue, 20 Nov 2018 20:00:09 + (GMT)

Mozilla: Audit Reminder
Root Certificates:
   TrustCor RootCert CA-2
   TrustCor RootCert CA-1
   TrustCor ECA-1
Standard Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221175

Audit Statement Date: 2017-12-15
BR Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221176

BR Audit Statement Date: 2017-12-15
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   EE Certification Centre Root CA
Standard Audit: 
https://sk.ee/upload/files/AA2017112401_Audit%20Attestation_final.pdf

Audit Statement Date: 2017-11-24
BR Audit: 
https://sk.ee/upload/files/AA2017112401_Audit%20Attestation_final.pdf

BR Audit Statement Date: 2017-11-24
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Certinomis - Root CA
Standard Audit: 
https://bug937589.bmoattachments.org/attachment.cgi?id=8898169

Audit Statement Date: 2017-07-24
BR Audit: https://bug937589.bmoattachments.org/attachment.cgi?id=8898169
BR Audit Statement Date: 2017-07-24
CA Comments: null



Mozilla: Audit Reminder
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/AA2017120703_Browser_Auidt_Attestation_s.pdf

Audit Statement Date: 2017-12-07
Standard Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2017120702_Browser_Audit_Attestation_s.pdf

Audit Statement Date: 2017-12-07
Standard Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2017120701_Browser_Audit_Atestation_s.pdf

Audit Statement Date: 2017-12-07
BR Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2017120703_Browser_Auidt_Attestation_s.pdf

BR Audit Statement Date: 2017-12-07
BR Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2017120702_Browser_Audit_Attestation_s.pdf

BR Audit Statement Date: 2017-12-07
BR Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2017120701_Browser_Audit_Atestation_s.pdf

BR Audit Statement Date: 2017-12-07
EV Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2017120701_Browser_Audit_Atestation_s.pdf

EV Audit Statement Date: 2017-12-07
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   TUBITAK Kamu SM SSL Kok Sertifikasi - Surum 1
Standard Audit: 
https://bug1262809.bmoattachments.org/attachment.cgi?id=8937952

Audit Statement Date: 2017-12-08
BR Audit: https://bug1262809.bmoattachments.org/attachment.cgi?id=8937952
BR Audit Statement Date: 2017-12-08
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Microsec e-Szigno Root CA 2009
Standard Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2017121401_Browser_Audit_Attestation_s.pdf

Audit Statement Date: 2017-12-14
BR Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2017121402_Browser_Audit_Attestation_s.pdf

BR Audit Statement Date: 2017-12-14
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Class 2 Primary CA
Standard Audit: 
https://bug1297034.bmoattachments.org/attachment.cgi?id=8916590

Audit Statement Date: 2017-07-24
BR Audit: https://bug1297034.bmoattachments.org/attachment.cgi?id=8916590
BR Audit Statement Date: 2017-07-24
CA Comments:
https://bugzilla.mozilla.org/show_bug.cgi?id=1465629
https://bugzilla.mozilla.org/attachment.cgi?id=9024032
Need CA to create Audit Case in CCADB



Mozilla: Audit Reminder
Root Certificates:
   SwissSign Gold CA - G2
Standard Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2017113001_Browser_Audit_Attestation_s.pdf

Audit Statement Date: 2017-11-30
BR Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2017113001_Browser_Audit_Attestation_s.pdf

BR Audit Statement Date: 2017-11-30
EV Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2017113001_Browser_Audit_Attestation_s.pdf

EV Audit Statement Date: 2017-11-30
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Secure Global CA
   SecureTrust CA
   XRamp Global Certification Authority
Standard Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221135

Audit Statement Date: 2017-11-17
BR Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221136

BR Audit Statement Date: 2017-11-17
EV Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221137

EV Audit Statement Date: 2017-11-17
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   CFCA EV ROOT
Standard Audit: 

Re: Audit Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of September 2018 Audit Reminder Emails
Date: Tue, 18 Sep 2018 19:00:14 + (GMT)

Mozilla: Audit Reminder
Root Certificates:
   AC Raíz Certicámara S.A.
Standard Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221203

Audit Statement Date: 2017-08-09
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Certinomis - Root CA
Standard Audit: 
https://bug937589.bmoattachments.org/attachment.cgi?id=8898169

Audit Statement Date: 2017-07-24
BR Audit: https://bug937589.bmoattachments.org/attachment.cgi?id=8898169
BR Audit Statement Date: 2017-07-24
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   E-Tugra Certification Authority
Standard Audit: 
https://www.e-tugra.com.tr/Portals/6/Documents/LSTIAL_ETugra_2017.pdf

Audit Statement Date: 2017-09-09
BR Audit: 
https://www.e-tugra.com.tr/Portals/6/Documents/LSTIAL_ETugra_2017.pdf

BR Audit Statement Date: 2017-09-09
EV Audit: 
https://www.e-tugra.com.tr/Portals/6/Documents/LSTIAL_ETugra_2017.pdf

EV Audit Statement Date: 2017-09-09
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Go Daddy Class 2 CA
   Go Daddy Root Certificate Authority - G2
   Starfield Class 2 CA
   Starfield Root Certificate Authority - G2
Standard Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221042

Audit Statement Date: 2017-08-31
BR Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221042

BR Audit Statement Date: 2017-08-31
EV Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221042

EV Audit Statement Date: 2017-08-31
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   ACCVRAIZ1
Standard Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221168

Audit Statement Date: 2017-07-28
BR Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221169

BR Audit Statement Date: 2017-07-28
CA Comments: Per CA request, Root CA Generalitat Valenciana will be 
removed via https://bugzilla.mozilla.org/show_bug.cgi?id=1272158




Mozilla: Audit Reminder
Root Certificates:
   Izenpe.com
Standard Audit: 
http://www.izenpe.eus/contenidos/informacion/auditorias_acreditaciones/en_def/adjuntos/6757_Izenpe_Browser_Attestation_2017.pdf

Audit Statement Date: 2017-07-25
BR Audit: 
http://www.izenpe.eus/contenidos/informacion/auditorias_acreditaciones/en_def/adjuntos/6757_Izenpe_Browser_Attestation_2017.pdf

BR Audit Statement Date: 2017-07-25
EV Audit: 
http://www.izenpe.eus/contenidos/informacion/auditorias_acreditaciones/en_def/adjuntos/6757_Izenpe_Browser_Attestation_2017.pdf

EV Audit Statement Date: 2017-07-25
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   NetLock Arany (Class Gold) Főtanúsítvány
Standard Audit: 
http://www.netlock.hu/docs/dokumentumok/Certificate%20ETSI%20ENG.pdf

Audit Statement Date: 2017-10-05
BR Audit: 
http://www.netlock.hu/docs/dokumentumok/Certificate%20ETSI%20ENG.pdf

BR Audit Statement Date: 2017-10-05
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   OpenTrust Root CA G1
   OpenTrust Root CA G2
   Certplus Root CA G1
   Class 2 Primary CA
   OpenTrust Root CA G3
   Certplus Root CA G2
Standard Audit: 
https://bug1297034.bmoattachments.org/attachment.cgi?id=8916590

Audit Statement Date: 2017-07-24
BR Audit: https://bug1297034.bmoattachments.org/attachment.cgi?id=8916590
BR Audit Statement Date: 2017-07-24
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   SECOM Trust.net - Security Communication RootCA1
   Security Communication RootCA2
Standard Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221101

Audit Statement Date: 2017-08-31
BR Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221098

BR Audit Statement Date: 2017-08-31
EV Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221100

EV Audit Statement Date: 2017-08-31
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Visa eCommerce Root**

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


Standard Audit: http://enroll.visaca.com/WTCA%20eComm.pdf
Audit Statement Date: 2017-07-26
BR Audit: http://enroll.visaca.com/WTBR%20eComm.pdf
BR Audit Statement Date: 2017-07-26
CA Comments: null



Mozilla: Audit Reminder
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**

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


Standard Audit: 

Re: Audit Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

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

Mozilla: Audit Reminder
Root Certificates:
   TrustCor RootCert CA-2
   TrustCor RootCert CA-1
   TrustCor ECA-1
Standard Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221175

Audit Statement Date: 2017-12-15
BR Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221176

BR Audit Statement Date: 2017-12-15
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   EE Certification Centre Root CA**

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


Standard Audit: 
https://sk.ee/upload/files/AA2017112401_Audit%20Attestation_final.pdf

Audit Statement Date: 2017-11-24
BR Audit: 
https://sk.ee/upload/files/AA2017112401_Audit%20Attestation_final.pdf

BR Audit Statement Date: 2017-11-24
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Certigna
   Certigna Root CA
Standard Audit: 
https://bug1265683.bmoattachments.org/attachment.cgi?id=8947405

Audit Statement Date: 2018-01-12
BR Audit: https://bug1265683.bmoattachments.org/attachment.cgi?id=8947405
BR Audit Statement Date: 2018-01-12
CA Comments: null



Mozilla: Overdue Audit Statements
Root Certificates:
   Certinomis - Root CA**

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


Standard Audit: 
https://bug937589.bmoattachments.org/attachment.cgi?id=8898169

Audit Statement Date: 2017-07-24
BR Audit: https://bug937589.bmoattachments.org/attachment.cgi?id=8898169
BR Audit Statement Date: 2017-07-24
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Microsec e-Szigno Root CA 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/AA2017121401_Browser_Audit_Attestation_s.pdf

Audit Statement Date: 2017-12-14
BR Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2017121402_Browser_Audit_Attestation_s.pdf

BR Audit Statement Date: 2017-12-14
CA Comments: null



Mozilla: Overdue Audit Statements
Root Certificates:
   Class 2 Primary CA**

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


Standard Audit: 
https://bug1297034.bmoattachments.org/attachment.cgi?id=8916590

Audit Statement Date: 2017-07-24
BR Audit: https://bug1297034.bmoattachments.org/attachment.cgi?id=8916590
BR Audit Statement Date: 2017-07-24
CA Comments: https://bugzilla.mozilla.org/show_bug.cgi?id=1465629



Mozilla: Audit Reminder
Root Certificates:
   SwissSign Gold CA - G2**

** 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/AA2017113001_Browser_Audit_Attestation_s.pdf

Audit Statement Date: 2017-11-30
BR Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2017113001_Browser_Audit_Attestation_s.pdf

BR Audit Statement Date: 2017-11-30
EV Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2017113001_Browser_Audit_Attestation_s.pdf

EV Audit Statement Date: 2017-11-30
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Secure Global CA**
   SecureTrust CA**
   XRamp Global Certification Authority**

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


Standard Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221135

Audit Statement Date: 2017-11-17
BR Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221136

BR Audit Statement Date: 2017-11-17
EV Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221137

EV Audit Statement Date: 2017-11-17
CA Comments: null




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

Add columns to IncludedCACertificate reports for expired and revoked test websites

[Kathleen Wilson via dev-security-policy]

All,

I would like to add two columns ("Test Website - Expired" and "Test 
Website - Revoked") to the following reports:


https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport

https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReportCSVFormat

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

Please let me know ASAP if you foresee any reason why this change should 
not be implemented.


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

Audit Reminders for Intermediate Certs

[Kathleen Wilson via dev-security-policy]

All,

CCADB sends email on the first Tuesday of each month to CAs with 
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.


https://wiki.mozilla.org/CA/Email_templates#Outdated_Audit_Statements_for_Intermediate_Certificates

Below is the summary of the email that was sent today.

Kathleen

 Forwarded Message 
Subject: Summary of April 2019 Outdated Audit Statements for 
Intermediate Certs

Date: Tue, 2 Apr 2019 14:00:24 + (GMT)


CA Owner: Government of The Netherlands, PKIoverheid (Logius)
   - Certificate Name: MinIenW PKIoverheid Organisatie Services CA - G3
SHA-256 Fingerprint: 
16C94A8CCC15C983825B5BD3F2DC68D694C8A320F2328ECD8C9CA57DE51DA0E5

Standard Audit Period End Date (mm/dd/): 11/15/2017

   - Certificate Name: MinIenW PKIoverheid Organisatie Persoon CA - G3
SHA-256 Fingerprint: 
0664F1D1A7355700201D2F4431DC43B0BCEAB129A8CABFD4ED87D04341EF

Standard Audit Period End Date (mm/dd/): 11/15/2017

   - Certificate Name: MinIenM Organisatie CA - G2
SHA-256 Fingerprint: 
BDD191FD3B4AC34B4D2F62EFAFBD07CEAB6581BCFE6C129F5916F1892FBD5394

Standard Audit Period End Date (mm/dd/): 11/15/2017

   - Certificate Name: MinIenM Autonome Apparaten CA - G2
SHA-256 Fingerprint: 
3B011284D8EBE902841CEC48F9D7F18BEF71BA404835717D5D2BEF5655710793

Standard Audit Period End Date (mm/dd/): 11/15/2017





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/06/2017
BR Audit Period End Date (mm/dd/): 12/06/2017

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

Standard Audit Period End Date (mm/dd/): 12/07/2017
BR Audit Period End Date (mm/dd/): 12/07/2017

   - Certificate Name: MULTICERT SSL Certification Authority 001
SHA-256 Fingerprint: 
06A57D1CD5879FBA2135610DD8D725CC268D2A6DE8A463D424C4B9DA89848696

Standard Audit Period End Date (mm/dd/): 12/19/2017
BR Audit Period End Date (mm/dd/): 12/19/2017





CA Owner: DigiCert
   - Certificate Name: ABN AMRO CA - G2
SHA-256 Fingerprint: 
AF6BFC9FF646FA900FEA0D79B89932304E27F84CC9E261BDE52B0EC04CF5AD85

Standard Audit Period End Date (mm/dd/): 05/24/2017

   - Certificate Name: ABN AMRO CA - G2
SHA-256 Fingerprint: 
B91AF4B7FFC8DB435304212030724BECB2F23686552149FD671339C9528A65F9

Standard Audit Period End Date (mm/dd/): 05/24/2017

   - Certificate Name: ABN AMRO Test CA - G2
SHA-256 Fingerprint: 
52D90CEF761E2458A8B51638EF0A0513584EBA986E740C573AD2A73882818EE9

Standard Audit Period End Date (mm/dd/): 05/24/2017

   - Certificate Name: Philips Extranet CA - G4
SHA-256 Fingerprint: 
E20AFEA72530C529D4046852144A267337221C5BE303528C07EF640BCAD6F091

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

   - Certificate Name: Shell Information Technology International CA - G3
SHA-256 Fingerprint: 
91603DADB54CBCDEDD43805EA7A272EB31DF8444775064A01821C2B650890DCE

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


Comment: Incident Report for these outdated audit statements
https://bugzilla.mozilla.org/show_bug.cgi?id=1539296



CA Owner: Entrust
   - Certificate Name: LAWtrust2048 CA2
SHA-256 Fingerprint: 
4957DED341054641139CBAB3B96006545D094D449590FB08AE9A78D05A40BD83

Standard Audit Period End Date (mm/dd/): 12/31/2017





CA Owner: QuoVadis
   - Certificate Name: VR IDENT SSL CA 2016
SHA-256 Fingerprint: 
FD3E44280C8DCBE8CF8CF55511E0669C8537945DA1FA7468C0EA52B686DD5B68

Standard Audit Period End Date (mm/dd/): 12/31/2017
BR Audit Period End Date (mm/dd/): 12/31/2017

   - Certificate Name: VR IDENT EV SSL CA 2016
SHA-256 Fingerprint: 
55B0CD2CCAD18E25977D906DAC9FA8B8643D7A258E7B3837F1157A13AC19D187

Standard Audit Period End Date (mm/dd/): 12/31/2017
BR Audit Period End Date (mm/dd/): 12/31/2017
EV SSL Audit Period End Date (mm/dd/): 12/31/2017





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

Re: New report: Intermediate CA Certificates with their own audit statements

[Kathleen Wilson via dev-security-policy]

Copy-paste correction:

2) Intermediate CA Certificates with their own audit statements (CSV)
https://ccadb-public.secure.force.com/mozilla/IntermediateCertsSeparateAuditsCSV


On 3/27/19 11:50 AM, Kathleen Wilson wrote:

All,

Just FYI that we have added the following two reports to 
wiki.mozilla.org/CA/Intermediate_Certificates


1) Intermediate CA Certificates with their own audit statements (HTML)
https://ccadb-public.secure.force.com/mozilla/IntermediateCertsSeparateAudits 



2) Intermediate CA Certificates with their own audit statements (CSV)
https://ccadb-public.secure.force.com/mozilla/PublicIntermediateCertsRevokedWithPEMCSV 



These reports are Filtered By:
CA Owner/Certificate Record Type equals Intermediate Certificate
AND Revocation Status equals Not Revoked
AND Mozilla Root Status for the root cert equals Included,Change Requested
AND Audits Same as Parent equals False
AND Valid To (GMT) greater than TODAY
AND Technically Constrained equals False


I plan to add an "Audit Letter Validation (ALV)" button to the 
intermediate certificate records in the CCADB. Then I will add columns 
to these reports to indicate the ALV results and when the ALV was last 
run on the record.


Thanks,
Kathleen

PS: There is already an Incident Report for the KPN outdated audit 
statements that you will notice in these reports.

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



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

New report: Intermediate CA Certificates with their own audit statements

[Kathleen Wilson via dev-security-policy]

All,

Just FYI that we have added the following two reports to 
wiki.mozilla.org/CA/Intermediate_Certificates


1) Intermediate CA Certificates with their own audit statements (HTML)
https://ccadb-public.secure.force.com/mozilla/IntermediateCertsSeparateAudits

2) Intermediate CA Certificates with their own audit statements (CSV)
https://ccadb-public.secure.force.com/mozilla/PublicIntermediateCertsRevokedWithPEMCSV

These reports are Filtered By:
CA Owner/Certificate Record Type equals Intermediate Certificate
AND Revocation Status equals Not Revoked
AND Mozilla Root Status for the root cert equals Included,Change Requested
AND Audits Same as Parent equals False
AND Valid To (GMT) greater than TODAY
AND Technically Constrained equals False


I plan to add an "Audit Letter Validation (ALV)" button to the 
intermediate certificate records in the CCADB. Then I will add columns 
to these reports to indicate the ALV results and when the ALV was last 
run on the record.


Thanks,
Kathleen

PS: There is already an Incident Report for the KPN outdated audit 
statements that you will notice in these reports.

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

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

CCADB access for new CAs

[Kathleen Wilson via dev-security-policy]

All,

As you know, CAs who currently have access to the CCADB are now able to 
directly enter and update their Root Inclusion Cases [1].


I would like to extend this capability to new CAs, so I propose that we 
add the description in the following document to a web page in 
https://ccadb.org/cas/


https://docs.google.com/document/d/1QW2-7OeOVAU3D-68jgZon7Nd7fnpV6jivQwYclLpoyA/edit?usp=sharing

The DRAFT web form for new CAs to request access is here:
https://ccadb-public.secure.force.com/mozilla/AccessRequestForm

Note: Any data entered now will be considered test data, and will be 
deleted without processing. I will post a comment here in m.d.s.p when 
it is ready for real data.


Details: The web form will cause a "Lead" object to be created in the 
CCADB. Us root store operators will then evaluate the Lead to determine 
if a new CA Owner object and Contact should be created, and if a CCADB 
CA Community License should be issued to the Contact.


As always, I will greatly appreciate your constructive and thoughtful 
feedback on this new process, instructions, and web form.


Thanks,
Kathleen


[1] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/QFoDRCWXthU/PaFYkUOwCAAJ

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

Column added to AllCertificateRecordsCSVFormat report - CP/CPS Last Updated Date

[Kathleen Wilson via dev-security-policy]

All,

The following report has been updated to add a column for "CP/CPS Last 
Updated Date".


http://ccadb-public.secure.force.com/mozilla/AllCertificateRecordsCSVFormat

Regards,
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]

Here's the summary of Mozilla's audit reminder emails that were sent 
last Tuesday. (I was on vacation last week).


Note that per previous discussion, the date logic for sending these 
emails has been updated, and is documented here:


https://wiki.mozilla.org/CA/Email_templates#Audit_Reminder_Email_Templates

- Audit Reminder is sent when previous Audit Period End date is 1 year 
plus 31 days to 93 days old.


- Overdue Notice is sent when previous Audit Period End date is 1 year 
plus 93 days to 150 days old.


- Danger of being removed warning is sent when previous Audit Period End 
date is older than 1 year plus 150 days.


Thanks,
Kathleen

 Forwarded Message 
Subject: Summary of February 2019 Audit Reminder Emails
Date: Tue, 19 Feb 2019 20:00:52 + (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://bugzilla.mozilla.org/attachment.cgi?id=8958479
Standard Audit Period End Date: 2017-12-31
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8958475
BR Audit Period End Date: 2017-12-31
EV Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8958477
EV Audit Period End Date: 2017-12-31
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Krajowa Izba Rozliczeniowa S.A. (KIR)
Root Certificates:
   SZAFIR ROOT CA2
Standard Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221051

Standard Audit Period End Date: 2017-12-18
BR Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221052

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



Mozilla: Audit Reminder
CA Owner: Buypass
Root Certificates:
   Buypass Class 2 Root CA
   Buypass Class 3 Root CA
Standard Audit: 
https://bug1359516.bmoattachments.org/attachment.cgi?id=8956295

Standard Audit Period End Date: 2017-11-30
BR Audit: https://bug1359516.bmoattachments.org/attachment.cgi?id=8956295
BR Audit Period End Date: 2017-11-30
EV Audit: https://bug1359516.bmoattachments.org/attachment.cgi?id=8956295
EV Audit Period End Date: 2017-11-30
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Government of Hong Kong (SAR), Hongkong Post, Certizen
Root Certificates:
   Hongkong Post Root CA 1
Standard Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221045

Standard Audit Period End Date: 2017-12-31
BR Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221044

BR Audit Period End Date: 2017-12-31
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: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221092

Standard Audit Period End Date: 2017-12-31
BR Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221093

BR Audit Period End Date: 2017-12-31
EV Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221094

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



Mozilla: Audit Reminder
CA Owner: Taiwan-CA Inc. (TWCA)
Root Certificates:
   TWCA Global Root CA
   TWCA Root Certification Authority
Standard Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221109

Standard Audit Period End Date: 2017-12-31
BR Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221112

BR Audit Period End Date: 2017-12-31
EV Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=22

EV Audit Period End Date: 2017-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.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2018041201_Audit_Attestation_s.pdf

Standard Audit Period End Date: 2018-01-12
BR Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2018041201_Audit_Attestation_s.pdf

BR Audit Period End Date: 2018-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: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221192

Standard Audit Period End Date: 2018-01-15
BR Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221193

BR Audit Period End Date: 2018-01-15
EV Audit: 

Re: DarkMatter Concerns

[Kathleen Wilson via dev-security-policy]

All,

Thank you to those of you that have been providing thoughtful and 
constructive input into this discussion. I have been carefully reading 
and contemplating all of the messages posted in the 
mozilla.dev.security.policy forum.


As the owner of Mozilla’s CA Certificates Module[1] and in an effort to 
respond to Matthew’s concerns about transparency[2], I would like to 
share my current thoughts about DarkMatter’s intermediate certificates 
and root inclusion request. I will make a decision after this discussion 
has run its full course.


I appreciate that representatives of DarkMatter are participating in 
this discussion, and reiterate that I have not yet come to a decision. I 
would also like to remind everyone that we have not yet started the 
public discussion phase of DarkMatter’s root inclusion request. This 
discussion is separate from Mozilla’s root inclusion process, but will 
determine if the process will continue for DarkMatter’s root inclusion 
request. If this discussion concludes that DarkMatter’s intermediate 
certificates should be added to OneCRL, then the root inclusion request 
will be closed. However, if this discussion concludes that DarkMatter’s 
intermediate certificates should not be added to OneCRL, then 
DarkMatter’s root inclusion request will continue to follow the normal 
process.


== Regarding DarkMatter’s current intermediate certificates ==

The current DarkMatter intermediate certificates are not constrained or 
technically controlled by the parent CA, as was confirmed by a 
representative of DigiCert[3]. This means that currently DarkMatter has 
all of the certificate issuance capability of a root certificate that is 
directly included in Mozilla’s root store. This is why we are having 
this discussion to determine if DarkMatter’s current intermediate 
certificates should be added to OneCRL.


In my opinion, there are other options for DarkMatter. For example, a CA 
who is currently included in Mozilla’s program such as Digicert, could 
issue DarkMatter new intermediate certificates that are owned and 
controlled by DigiCert and for which DigiCert performs additional domain 
validation before issuance of end-entity certs in that CA hierarchy. I 
think that an option like this would provide sufficient oversight of 
DarkMatter’s certificate issuance, if we decide to add DarkMatter’s 
current intermediate certificates to OneCRL.


== Regarding DarkMatter’s root inclusion request ==

Since I began working on Mozilla’s CA Program in 2008 I have rarely seen 
this much interest and opinions from the media and general public on 
root inclusion requests, even though all of our process is performed in 
the open[4]  and includes a public discussion phase[5]. In my opinion, 
we should pay attention to the messages we're receiving, and subject 
this CA to additional scrutiny.


As others have already pointed out[6] DarkMatter’s root inclusion 
request is reminiscent of CNNIC’s root inclusion request in 2009 [7] and 
their request to include an additional root in 2012 [8]. As Ryan 
reminded us[9] in his excellent analysis, the decisions about the 
inclusion of the CNNIC root certificates was based on “a rigid 
application of policy”. In one of my posts[10] about CNNIC’s root 
inclusion requests I stated:
“There was a lot of discussion about government, politics, legal 
jurisdiction, what-if scenarios, and people’s opinions about the Chinese 
government. While I sympathize with people’s feelings about this, 
Mozilla’s root program is based on policy and evidence. While CNNIC has 
provided all of the required information to demonstrate their compliance 
with Mozilla’s CA Certificate Policy, no usable evidence has been 
provided to show non-compliance with Mozilla’s CA Certificate Policy.”


As we all know, in 2015 Mozilla revoked trust in CNNIC certificates[11] 
after discussion[12] in this forum regarding the discovery that an 
intermediate CA under the CNNIC root was used to mis-issue TLS 
certificates for some domains, and subsequently used for MiTM. In that 
case, rigid application of the policy left our users at risk. This was 
an important learning experience for us.


Root inclusion requests rarely receive this much attention. Another one 
that we have been reminded of is TeliaSonera’s root inclusion 
discussion[13], in which I stated: “Typically this would have been 
considered a very standard request, but this discussion turned into a 
political sounding board. Approval of this root-renewal request means 
that the CA complies with Mozilla’s CA Certificate Policy and provides 
annual audit statements attesting to their compliance. It in no way 
reflects my opinion, or that of Mozilla, on the actions of the owner of 
the CA in regards to their non-CA related businesses and practices.”


Unlike CNNIC, TeliaSonera still has root certificates in Mozilla’s root 
store. Similar to many CAs in our program, TeliaSonera has had some 
compliance problems[14], but (to my knowledge) 

Re: Audit Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

Here's the summary of Mozilla's audit reminder emails that were sent 
today by the CCADB.


Reminder: The date logic for sending these emails is documented in the 
following wiki page.


https://wiki.mozilla.org/CA/Email_templates#Audit_Reminder_Email_Templates

- Audit Reminder is sent when previous Audit Period End date is 1 year 
plus 31 days to 93 days old.


- Overdue Notice is sent when previous Audit Period End date is 1 year 
plus 93 days to 150 days old.


- Danger of being removed warning is sent when previous Audit Period End 
date is older than 1 year plus 150 days.



 Forwarded Message 
Subject: Summary of March 2019 Audit Reminder Emails
Date: Tue, 19 Mar 2019 19:00:09 + (GMT)


Mozilla: Audit Reminder
CA Owner: Krajowa Izba Rozliczeniowa S.A. (KIR)
Root Certificates:
   SZAFIR ROOT CA2
Standard Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221051

Standard Audit Period End Date: 2017-12-18
BR Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221052

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



Mozilla: Audit Reminder
CA Owner: certSIGN
Root Certificates:
   certSIGN ROOT CA
Standard Audit: 
https://www.certsign.ro/certsign/files/certSIGN-Webtrust-CA-Report-2018.pdf

Standard Audit Period End Date: 2018-02-08
BR Audit: 
https://www.certsign.ro/certsign/files/certSIGN-Webtrust-CA-SSL-Report-2018.pdf

BR Audit Period End Date: 2018-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: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221092

Standard Audit Period End Date: 2017-12-31
BR Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221093

BR Audit Period End Date: 2017-12-31
EV Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221094

EV Audit Period End Date: 2017-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.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2018041201_Audit_Attestation_s.pdf

Standard Audit Period End Date: 2018-01-12
BR Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2018041201_Audit_Attestation_s.pdf

BR Audit Period End Date: 2018-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: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221192

Standard Audit Period End Date: 2018-01-15
BR Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221193

BR Audit Period End Date: 2018-01-15
EV Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221194

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




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

Change in Mozilla's Root Inclusion Request Process

[Kathleen Wilson via dev-security-policy]

All,

As of today, CAs who already have access to the CCADB should create 
their new root inclusion requests (for Mozilla's program) as follows:


1) Create a Root Inclusion Bugzilla Bug.
https://wiki.mozilla.org/CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request

2) Provide all of the required information via a Root Inclusion Case in 
the CCADB.

https://wiki.mozilla.org/CA/Information_Checklist#Create_a_Root_Inclusion_Case

3) Click on the 'Get URLs' button in the Root Inclusion Case and copy 
the line that begins with "Mozilla Root Inclusion Case Information:" 
into a Comment in the Bugzilla Bug.
e.g. Mozilla Root Inclusion Case Information: 
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0341


This will trigger step 2 of Mozilla's root inclusion process.
https://wiki.mozilla.org/CA/Application_Process#Process_Overview

Thanks,
Kathleen

PS: We are working on a process for how a new CA can request access to 
the CCADB. For now, CAs who do not currently have access to the CCADB 
will continue to download the Google Doc, fill it in, and attach it to 
the bug.

https://wiki.mozilla.org/CA/Information_Checklist#Example_and_Template


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

Re: Changing Date Checks in Audit Reminder Emails

[Kathleen Wilson via dev-security-policy]

On 2/6/19 2:53 PM, Kathleen Wilson wrote:

So here's the updated proposal:

1) If
(1 year + 31 days) < (today - Audit Period End Date) <= (1 year + 93 days)
Send Courtesy Audit Reminder
https://wiki.mozilla.org/CA/Email_templates#Courtesy_Audit_Reminder_Email_Template 



2) If
(1 year + 93 days) < (today - Audit Period End Date) <= (1 year + 150 days)
Send Overdue Audit Reminder
https://wiki.mozilla.org/CA/Email_templates#Overdue_Audit_Statement_Email_Template 



3) If
(1 year + 150 days) < (today - Audit Period End Date)
Send Danger of being Removed notice
https://wiki.mozilla.org/CA/Email_templates#Failure_to_Provide_Audit_Statement_Email_Template 




These changes have been implemented, so the audit reminder emails that 
will be sent next Tuesday will reflect this new logic.


I also added this information to the wiki page:
https://wiki.mozilla.org/CA/Email_templates#Audit_Reminder_Email_Templates

- Audit Reminder is sent when previous Audit Period End date is 1 year 
plus 31 days to 93 days old.


- Overdue Notice is sent when previous Audit Period End date is 1 year 
plus 93 days to 150 days old.


- Danger of being removed warning is sent when previous Audit Period End 
date is older than 1 year plus 150 days.


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

Re: Changing Date Checks in Audit Reminder Emails

[Kathleen Wilson via dev-security-policy]

Thanks Wayne and Kurt for your input.

So here's the updated proposal:

1) If
(1 year + 31 days) < (today - Audit Period End Date) <= (1 year + 93 days)
Send Courtesy Audit Reminder
https://wiki.mozilla.org/CA/Email_templates#Courtesy_Audit_Reminder_Email_Template

2) If
(1 year + 93 days) < (today - Audit Period End Date) <= (1 year + 150 days)
Send Overdue Audit Reminder
https://wiki.mozilla.org/CA/Email_templates#Overdue_Audit_Statement_Email_Template

3) If
(1 year + 150 days) < (today - Audit Period End Date)
Send Danger of being Removed notice
https://wiki.mozilla.org/CA/Email_templates#Failure_to_Provide_Audit_Statement_Email_Template


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

Changing Date Checks in Audit Reminder Emails

[Kathleen Wilson via dev-security-policy]

All,

As you know, CCADB sends audit reminder emails regarding root certs in 
Mozilla's program on the 3rd Tuesday of each month.


We are going to update the date checks for determining when the email 
gets sent, so that rather than keying off of the Audit Statement Date, 
the check will key off of the Audit Period End date.


I will appreciate input on what the date ranges should be.

Here's the current logic with just the change to use Audit Period End Date.

1) If
(1 year - 30 days) < Audit Period End Date <= (1 year + 120 days)
Send Courtesy Audit Reminder
https://wiki.mozilla.org/CA/Email_templates#Courtesy_Audit_Reminder_Email_Template

2) If
(1 year + 120 days) < Audit Period End Date <= (1 year + 240 days)
Send Overdue Audit Reminder
https://wiki.mozilla.org/CA/Email_templates#Overdue_Audit_Statement_Email_Template

3) If
(1 year + 240 days) < Audit Period End Date
Send Danger of being Removed notice
https://wiki.mozilla.org/CA/Email_templates#Failure_to_Provide_Audit_Statement_Email_Template


For you reference, previous audit reminder email summaries are here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/IjgFwzGI_H0/8J8LZNlaDgAJ

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

Blog: Common CA Database (CCADB) promotes Transparency and Collaboration

[Kathleen Wilson via dev-security-policy]

All,

I posted the following to the Mozilla Security Blog to explain what the 
CCADB is and why it is important.


https://blog.mozilla.org/security/2019/04/15/common-ca-database-ccadb/

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 2019 Outdated Audit Statements for Intermediate 
Certs

Date: Tue, 4 Jun 2019 14: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/06/2017
BR Audit Period End Date (mm/dd/): 12/06/2017

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

Standard Audit Period End Date (mm/dd/): 12/07/2017
BR Audit Period End Date (mm/dd/): 12/07/2017

Comment: Incident Report for these outdated audit statements
https://bugzilla.mozilla.org/show_bug.cgi?id=1549861



CA Owner: Sectigo
   - Certificate Name: D-TRUST CA 2-1 2015
SHA-256 Fingerprint: 
081998D3D9F7E4CD9DA6A429470BF5D44280325244FA0E01EE5F972CA19F4852

Standard Audit Period End Date (mm/dd/): 02/19/2018





CA Owner: DigiCert
   - Certificate Name: Siemens Internet CA V1.0
SHA-256 Fingerprint: 
67E5B507C861CE7180BC3DB7D37D2F5CAE755831E212E32225F6294694B2EA49

Standard Audit Period End Date (mm/dd/): 02/25/2018
BR Audit Period End Date (mm/dd/): 02/25/2018

   - Certificate Name: Siemens Internet CA V1.0
SHA-256 Fingerprint: 
24E56F48604446D8A8373B43CA29D1A1C49772E5AABA8BA7C17662BD60DA8DF6

Standard Audit Period End Date (mm/dd/): 02/25/2018
BR Audit Period End Date (mm/dd/): 02/25/2018

   - Certificate Name: Siemens Issuing CA Multipurpose 2013
SHA-256 Fingerprint: 
89D2EBFBAFD59C6A1C83EC6C035316145704F895363370D015B8F62595A0497A

Standard Audit Period End Date (mm/dd/): 02/25/2018

   - Certificate Name: Siemens Internet CA V1.0
SHA-256 Fingerprint: 
3EBF5FFEC582D27C693D1BC30104A63BBBFC3652C78A95027E91B7F88DAC6345

Standard Audit Period End Date (mm/dd/): 02/25/2018
BR Audit Period End Date (mm/dd/): 02/25/2018

   - Certificate Name: Siemens Issuing CA EE Enc 2013
SHA-256 Fingerprint: 
F5629F8E16AA288B21CF253225FAB8A9CE15C468781C1E74284079728EFF2FDA

Standard Audit Period End Date (mm/dd/): 02/25/2018
BR Audit Period End Date (mm/dd/): 02/25/2018





CA Owner: Entrust
   - Certificate Name: LAWtrust2048 CA2
SHA-256 Fingerprint: 
4957DED341054641139CBAB3B96006545D094D449590FB08AE9A78D05A40BD83

Standard Audit Period End Date (mm/dd/): 12/31/2017

Comment: Incident Report for this outdated audit statement
https://bugzilla.mozilla.org/show_bug.cgi?id=1549862




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

CCADB CA Task List on Homepage

[Kathleen Wilson via dev-security-policy]

For those of you with access to the CCADB...

There is now a CCADB CA Task list on your homepage. This gets updated 
every time you go to your CCADB homepage, either upon login, or by 
clicking on the 'Home' tab.


Here is an example of what it looks like.
~~
Summary (Click on the arrows to see the details)
Root Certs with Outdated Audit Statements: 1
Intermediate Certs with Outdated Audit Statements: 2
Intermediate Certs with no audit information provided: 3
Intermediate Certs with no CP/CPS information provided: 4
Contacts who may be obsolete: 1

-> Provide updated Audit Statements for these Root Certs
 Instructions: Create an Audit Case to submit updated audits for root 
certs, as described here: https://ccadb.org/cas/updates



-> Provide updated Audit Statements for these Intermediate Certs
 Instructions: Directly edit each intermediate cert record to provide 
updated audit information.



-> Provide Audit Information for these Intermediate Certs
 Instructions: Directly edit each intermediate cert record to provide 
audit information or select the "Audits Same as Parent" box.



-> Provide Audit Information for these Intermediate Certs
 Instructions: Directly edit each intermediate cert record to provide 
CP/CPS information or select the "CP/CPS Same as Parent" box.



-> Determine which of these Contacts are Obsolete
 Instructions: Send email to supp...@ccadb.org to indicate obsolete 
users who no longer need access to the CCADB.


~~

When everything is zero, it looks like the following. Detailed 
sub-sections are only shown when non-zero.

~~
Summary
Root Certs with Outdated Audit Statements: 0
Intermediate Certs with Outdated Audit Statements: 0
Intermediate Certs with no audit information provided: 0
Intermediate Certs with no CP/CPS information provided: 0
Contacts who may be obsolete: 0
~~


Please check it out, and let me know if you have any questions or 
feedback 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 Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of June 2019 Audit Reminder Emails
Date: Tue, 18 Jun 2019 19:00:30 + (GMT)

Mozilla: Audit Reminder
CA Owner: LuxTrust
Root Certificates:
   LuxTrust Global Root 2
Standard Audit: 
https://www.lsti-certification.fr/images/LSTI--11085-57-AL-V1.0_LUXTRUST.pdf

Standard Audit Period End Date: 2018-03-30
BR Audit: 
https://www.lsti-certification.fr/images/LSTI--11085-57-AL-V1.0_LUXTRUST.pdf

BR Audit Period End Date: 2018-03-30
EV Audit: 
https://www.lsti-certification.fr/images/LSTI--11085-57-AL-V1.0_LUXTRUST.pdf

EV Audit Period End Date: 2018-03-30
CA Comments: null



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/AptifyAttachmentHandler.ashx?AttachmentID=221269

Standard Audit Period End Date: 2018-04-30
BR Audit: 
https://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221270

BR Audit Period End Date: 2018-04-30
EV Audit: 
https://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221271

EV Audit Period End Date: 2018-04-30
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Autoridad de Certificacion Firmaprofesional
Root Certificates:
   Autoridad de Certificacion Firmaprofesional CIF A62634068
Standard Audit: 
https://bug1412950.bmoattachments.org/attachment.cgi?id=9018966

Standard Audit Period End Date: 2018-03-27
BR Audit: https://bug1412950.bmoattachments.org/attachment.cgi?id=9018971
BR Audit Period End Date: 2018-03-27
EV Audit: https://bug1412950.bmoattachments.org/attachment.cgi?id=9018971
EV Audit Period End Date: 2018-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://bugzilla.mozilla.org/attachment.cgi?id=8995928
Standard Audit Period End Date: 2018-04-13
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8995930
BR Audit Period End Date: 2018-04-13
EV Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8995931
EV Audit Period End Date: 2018-04-13
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
   UTN-USERFirst-Client Authentication and Email
   USERTrust RSA Certification Authority
Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8989406
Standard Audit Period End Date: 2018-03-31
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8989407
BR Audit Period End Date: 2018-03-31
BR Audit:
BR Audit Period End Date:
EV Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8989408
EV Audit Period End Date: 2018-03-31
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert)
Root Certificates:
   EC-ACC**

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


Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=9013271
Standard Audit Period End Date: 2018-03-28
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=9013273
BR Audit Period End Date: 2018-03-28
CA Comments: null



Mozilla: Audit Reminder
CA Owner: DigiCert
Root Certificates:
   Baltimore CyberTrust Root
   Cybertrust Global Root
   DigiCert Assured ID Root CA
   DigiCert Assured ID Root G2
   DigiCert Assured ID Root G3
   DigiCert Trusted Root G4
Standard Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221124

Standard Audit Period End Date: 2018-03-31
BR Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221125

BR Audit Period End Date: 2018-03-31
EV Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221126

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



Mozilla: Overdue Audit Statements
CA Owner: Entrust
Root Certificates:
   Entrust Root Certification Authority - EC1**
   Entrust Root Certification Authority - G2**
   AffirmTrust Commercial**
   AffirmTrust Networking**
   AffirmTrust Premium**
   AffirmTrust Premium ECC
   Entrust Root Certification Authority**
   Entrust.net Certification Authority (2048)**

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


Standard Audit: 
https://www.entrustdatacard.com/-/media/documentation/licensingandagreements/entrust_wforca_2018.pdf

Standard Audit Period End Date: 2018-02-28
Standard Audit: 
https://www.affirmtrust.com/wp-content/uploads/2018-AFT-CA-Report.pdf

Standard Audit Period End Date: 2018-02-28
BR 

Re: Policy 2.7 Proposal: Clarify Revocation Requirements for S/MIME Certificates

[Kathleen Wilson via dev-security-policy]

On 5/10/19 5:46 PM, Wayne Thayer wrote:

I've attempted to update section 6 to incorporate revocation requirements
for S/MIME certificates:

https://github.com/mozilla/pkipolicy/commit/15ad5b9180903b92b8f638c219740c0fb6ba0637

Note: since much of this language is copied directly from the BRs, if we
decide to adopt it, the policy will also need to comply with the Creative
Commons Attribution 4.0 International license used by the BRs.

I will greatly appreciate everyone's review and comments on this proposed
change.



The proposed changes look OK to me.

But I would also be fine with the new section 6.2 regarding revocation 
of S/MIME certs just re-using the revocation text that we used to have 
in our policy (which had been removed in an effort to remove redundancy 
with the BRs).


https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md#6-revocation

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 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

[Kathleen Wilson via dev-security-policy]

On 5/13/19 10:24 AM, Wayne Thayer wrote:

The BRs forbid delegation of domain and IP address validation to third
parties. However, the BRs don't forbid delegation of email address
validation nor do they apply to S/MIME certificates.

Delegation of email address validation is already addressed by Mozilla's
Forbidden Practices [1] state:

"Domain and Email validation are core requirements of the Mozilla's Root
Store Policy and should always be incorporated into the issuing CA's
procedures. Delegating this function to 3rd parties is not permitted."

I propose that we move this statement (changing "the Mozilla's Root Store
Policy" to "this policy") into policy section 2.2 "Validation Practices".

This is https://github.com/mozilla/pkipolicy/issues/175

I will appreciate everyone's input on this proposal.

- Wayne

[1]
https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Delegation_of_Domain_.2F_Email_Validation_to_Third_Parties




All,

As the person who filed the Github issue for this, I would like to 
provide some background and my opinion.


Currently the 'Delegation of Domain / Email Validation to Third Parties' 
section of the 'Forbidden Practices' page says:

"This is forbidden by the Baseline Requirements, section 1.3.2.
Domain and Email validation are core requirements of the Mozilla's Root 
Store Policy and should always be incorporated into the issuing CA's 
procedures. Delegating this function to 3rd parties is not permitted."


Based on the way that section is written, it appears that domain 
validation (and the BRs) was the primary consideration, and that the 
Email part of it was an afterthought, or added later. Historically, my 
attention has been focused on TLS certs, so it is possible that the 
ramifications of adding Email validation to this section was not fully 
thought through.


I don't remember who added this email validation text or when, but I can 
tell you that when I review root inclusion requests I have only been 
concerned about making sure that domain validation is not being 
delegated to 3rd parties. It wasn't until a representative of a CA 
brought this to my attention that I realized that there has been a 
difference in text on this wiki page versus the rules I have been trying 
to enforce. That is when I filed the github issue.


I propose that we can resolve this discrepancy for now by removing "/ 
Email Validation" from the title of the section and removing "and Email" 
from the contents of the section.


Unless we believe there are significant security reasons to add our own 
S/MIME required/forbidden practices at this time, my preference is to 
wait for the CA/Browser Forum to create the S/MIME Working Group, and 
for that group to identify the S/MIME baseline requirements. Then we can 
add policy and required/forbidden practices based on the S/MIME BRs 
provided by that group.


I do realize that my proposal is unfair to CAs who have been diligently 
following this section of this wiki page. Your diligence is appreciated, 
and your contributions to this discussion will also be appreciated.


Thanks,
Kathleen
















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

Changes to ccadb.org site and report links

[Kathleen Wilson via dev-security-policy]

All,

We've made the following changes to the ccadb.org site.

1) The general links providing data for all CAs and certs in the CCADB 
have been updated from "mozilla" to "ccadb". In particular the first 
three links in the General section on the Resources tab have been updated.

https://ccadb.org/resources#general
* All certs (root and intermediate) in CCADB (CSV)
* List of CA problem reporting mechanisms (email, etc.)
* List of CAA Identifiers

The new links:
http://ccadb-public.secure.force.com/ccadb/AllCertificateRecordsCSVFormat
https://ccadb-public.secure.force.com/ccadb/AllProblemReportingMechanismsReport
https://ccadb-public.secure.force.com/ccadb/AllCAAIdentifiersReport

The old links still work, but please migrate to the new links at your 
convenience.



2) A new page has been added to the "For CAs" tab called "Request 
Access". This new page includes a link to a form that can be used for 
CAs to request access to the CCADB when they are in the root inclusion 
process for Mozilla's or Microsoft's programs. A submitted form creates 
a Lead in the CCADB that normally will be processed by me (for Mozilla) 
or Karina (for Microsoft). Once verified and approved, the Lead will 
generate the new CA Owner record and corresponding Primary Point of Contact.


As always, I appreciate your thoughtful and constructive feedback on the 
CCADB.


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

Re: Certinomis Issues

[Kathleen Wilson via dev-security-policy]

On 5/16/19 4:39 PM, Wayne Thayer wrote:

On Thu, May 16, 2019 at 4:23 PM Wayne Thayer  wrote:

I will soon file a bug requesting removal of the “Certinomis - Root CA”

from NSS.

This is https://bugzilla.mozilla.org/show_bug.cgi?id=1552374



Thank you to Wayne and all of you who have investigated concerns about 
the recent activities and operations of the CA Certinomis. I have 
appreciated the thoughtful consideration that you have put into the 
investigation and discussion.


I approved Bugzilla Bug #1552374, for the removal of the following root 
certificate in NSS 3.45 and Firefox 69 [1].


Common Name: Certinomis - Root CA
SHA-1 Fingerprint: 9D70BB01A5A4A018112EF71C01B932C534E788A8
SHA-256 Fingerprint: 
2A99F5BC1174B73CBB1D620884E01C34E51CCB3978DA125F0E33268883BF4158

Trust Bits: Websites
This root is *not* enabled for EV treatment

As Wayne previously explained[2], Certinomis may apply for inclusion of 
a new root certificate, and the new root certificate may be cross-signed 
by a currently included CA under certain conditions.


Thanks,
Kathleen

[1] https://wiki.mozilla.org/Release_Management/Calendar
[2] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/rmU311hOIIc/oYuxQJbEAQAJ

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