Re: Audit Reminder Email Summary
Forwarded Message Subject: Summary of February 2017 Audit Reminder Emails Date: Tue, 21 Feb 2017 20:00:51 + (GMT) Mozilla: Audit Reminder Root Certificates: ISRG Root X1 Standard Audit: https://cert.webtrust.org/SealFile?seal=1987=pdf Audit Statement Date: 2015-12-15 BR Audit: https://cert.webtrust.org/SealFile?seal=1988=pdf BR Audit Statement Date: 2015-12-15 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=2010=pdf Audit Statement Date: 2016-03-02 BR Audit: https://cert.webtrust.org/SealFile?seal=2010=pdf BR Audit Statement Date: 2016-03-02 EV Audit: https://cert.webtrust.org/SealFile?seal=2010=pdf EV Audit Statement Date: 2016-03-02 CA Comments: null Mozilla: Audit Reminder Root Certificates: SZAFIR ROOT CA2 Standard Audit: https://cert.webtrust.org/SealFile?seal=2018=pdf Audit Statement Date: 2016-03-18 BR Audit: https://cert.webtrust.org/SealFile?seal=2018=pdf BR Audit Statement Date: 2016-03-18 CA Comments: null Mozilla: Audit Reminder Root Certificates: certSIGN ROOT CA Standard Audit: https://www.certsign.ro/certsign_en/files/certSIGN_Webtrust_CA.pdf Audit Statement Date: 2016-02-08 BR Audit: https://www.certsign.ro/certsign_en/files/certSIGN_Webtrust_CA.pdf BR Audit Statement Date: 2016-02-08 CA Comments: null Mozilla: Audit Reminder Root Certificates: Cybertrust Global Root Standard Audit: https://cert.webtrust.org/SealFile?seal=2165=pdf Audit Statement Date: 2016-10-24 BR Audit: https://cert.webtrust.org/SealFile?seal=2016=pdf BR Audit Statement Date: 2016-03-18 EV Audit: https://cert.webtrust.org/SealFile?seal=2166=pdf EV Audit Statement Date: 2016-10-24 CA Comments: null Mozilla: Audit Reminder Root Certificates: D-TRUST Root Class 3 CA 2 2009 D-TRUST Root Class 3 CA 2 EV 2009 Standard Audit: https://www.tuvit.de/data/content_data/tuevit_en/6765UE_s.pdf Audit Statement Date: 2016-01-20 Standard Audit: https://www.tuvit.de/data/content_data/tuevit_en/6766UE_s.pdf Audit Statement Date: 2016-01-20 BR Audit: https://www.tuvit.de/data/content_data/tuevit_en/6765UE_s.pdf BR Audit Statement Date: 2016-01-20 BR Audit: https://www.tuvit.de/data/content_data/tuevit_en/6766UE_s.pdf BR Audit Statement Date: 2016-01-20 EV Audit: https://www.tuvit.de/data/content_data/tuevit_en/6766UE_s.pdf EV Audit Statement Date: 2016-01-20 CA Comments: null Mozilla: Audit Reminder Root Certificates: ACEDICOM Root Standard Audit: https://cert.webtrust.org/SealFile?seal=1958=pdf Audit Statement Date: 2015-11-03 BR Audit: https://cert.webtrust.org/SealFile?seal=1958=pdf BR Audit Statement Date: 2015-11-03 CA Comments: null Mozilla: Audit Reminder Root Certificates: Hongkong Post Root CA 1 Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8732899 Audit Statement Date: 2016-02-26 BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8746166 BR Audit Statement Date: 2016-03-31 CA Comments: null Mozilla: Audit Reminder Root Certificates: StartCom Certification Authority StartCom Certification Authority StartCom Certification Authority G2 Standard Audit: https://www.startssl.com/ey-webtrust.pdf Audit Statement Date: 2016-03-18 BR Audit: https://www.startssl.com/ey-webtrust-br.pdf BR Audit Statement Date: 2016-03-18 EV Audit: https://www.startssl.com/ey-webtrust-ev.pdf EV Audit Statement Date: 2016-03-18 CA Comments: null Mozilla: Audit Reminder Root Certificates: SwissSign Gold CA - G2 SwissSign Platinum CA - G2 SwissSign Silver CA - G2 Standard Audit: https://bug343756.bmoattachments.org/attachment.cgi?id=8781268 Audit Statement Date: 2016-03-18 BR Audit: https://bug343756.bmoattachments.org/attachment.cgi?id=8781268 BR Audit Statement Date: 2016-03-18 EV Audit: https://bug343756.bmoattachments.org/attachment.cgi?id=8781268 EV Audit Statement Date: 2016-03-18 CA Comments: null Mozilla: Audit Reminder Root Certificates: TWCA Global Root CA TWCA Root Certification Authority Standard Audit: https://cert.webtrust.org/SealFile?seal=1981=pdf Audit Statement Date: 2016-02-15 BR Audit: https://cert.webtrust.org/SealFile?seal=1985=pdf BR Audit Statement Date: 2016-02-15 EV Audit: https://cert.webtrust.org/SealFile?seal=1986=pdf EV Audit Statement Date: 2016-02-15 CA Comments: null Mozilla: Audit Reminder Root Certificates: Trustis Limited - Trustis FPS Root CA Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8745582 Audit Statement Date: 2016-02-03 BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8745582 BR Audit Statement Date: 2016-02-03 CA Comments: null Mozilla: Audit Reminder Root Certificates: CA WoSign ECC Root Certification Authority of WoSign G2 CA ? Certification Authority of WoSign Standard Audit:
Re: Next CA Communication
On Tuesday, March 21, 2017 at 7:17:26 AM UTC-7, Gervase Markham wrote: > On 17/03/17 11:30, Gervase Markham wrote: > > The URL for the draft of the next CA Communication is here: > > https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S00G3K2 > > A few more wording tweaks on the current version: > > * Action 1 says: "Date must be before June 1, 2017". That gives CAs 2 > months to make a CP/CPS update. Do we normally allow a bit more than > that for non-urgent updates? Say, 3 months? Updated to "Date must be before July 21, 2017." (3 months from when survey must be completed) > > * "I understand that our CP/CPS documents shall be updated each year" -> > "I understand that our CP/CPS documents should be reviewed and the > version number incremented each year" Action 2 option updated to: "I understand that our CP/CPS documents must be reviewed annually to ensure continued compliance with the CA/Browser Forum's Baseline Requirements, and that at least the version number should be incremented each year." > > * Action 8: "Our current policy is...". In hindsight, this is ambiguous > - it could be Mozilla's policy, and the CA is just affirming they > understand it. Instead say "The current policy of our CA is...". Done. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Next CA Communication
On Tuesday, March 21, 2017 at 5:51:29 AM UTC-7, Kurt Roeckx wrote: > On 2017-03-21 12:51, Jakob Bohm wrote: > > On 21/03/2017 10:09, Kurt Roeckx wrote: > >> Action 6 says: I've updated action #6, but it still might not be clear. Here's the new draft: ACTION 6: QUALIFIED AUDIT STATEMENTS When an auditor finds non-compliance with the audit criteria, the audit statement should clearly indicate the word “qualified”, and clearly identify the controls that failed. The auditor should provide qualified reports for all time periods until the problems have been fixed. Period-of-time audit statements are required to cover audit periods that are less than one year and are contiguous. In other words, there should never be a time gap between the audit periods indicated in period-of-time audit statements. Point-in-time audit statements may be used to confirm that all of the problems that the auditor previously identified in a qualified audit statement have been corrected. However, a point-in-time assessment does *not* replace the period-of-time assessment. (Required) ~~ Please let me know if you have suggestions about how to make this more clear. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Next CA Communication
On Tuesday, March 21, 2017 at 11:34:30 AM UTC-7, Gervase Markham wrote: > On 21/03/17 10:16, Gervase Markham wrote: > > On 17/03/17 11:30, Gervase Markham wrote: > >> The URL for the draft of the next CA Communication is here: > >> https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S00G3K2 > > > > A few more wording tweaks on the current version: > > In Action 1, we should replace: > > "However, if additional methods of domain validation are added to > section 3.2.2.4 of the BRs in the future, they will also be permitted." > > with: > > "Mozilla expects that all missing methods will be restored to the > Baseline Requirements in the near future. Once that happens, we will > return to the practice of requiring conformance to the latest version of > the BRs." > > (The CAB Forum PAG is about to resolve itself; happily, all participants > have agreed to license their patents under a CAB Forum RF license. It's > now just a question of getting a ballot done to add back the missing > methods. Yay :-) > > Gerv Glad to hear that. Second paragraph of Action 1 now says: ~~ Note that version 1.4.2 of the BRs does not contain all 10 of these methods, but it does contain section 3.2.2.4.11, "Other Methods", so the subsections of version 3.2.2.4 that are marked "Reserved" in version 1.4.2 of the BRs are still BR-compliant under version 1.4.2. By Mozilla policy, CAs are not permitted to rely on the "Other Methods" section to use methods of domain validation that are not among the 10 listed in section 3.2.2.4 of version 1.4.1 of the BRs. Mozilla expects that all of the methods for doing domain validation that are missing in version 1.4.2 of the BRs will be restored to a forthcoming version of the BRs, so we will once again be able to accept all of the methods of domain validation listed in the latest version of the BRs. ~~ Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Automated email reminders about intermediate certs missing audit or CP/CPS
All, Within the next few days, we plan to start sending automated email reminders to CAs about their intermediate cert records in the Common CA Database that are missing audit or CP/CPS information. The email template is here: https://wiki.mozilla.org/CA:Email_templates#Disclosure_Incomplete_Email_Template Please let me know if you have any feedback on this. Also, what would be a good frequency for sending these email reminders? Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Guang Dong Certificate Authority (GDCA) root inclusion request
All, This request is to include the "GDCA TrustAUTH R5 ROOT" certificate, turn on the Websites trust bit, and enabled EV treatment. In order to help get this discussion moving again, I asked GDCA to provide a side-by-side comparison of the latest version of the BRs with their CP/CPS documents. They provided this BR-self-assessment here: https://bugzilla.mozilla.org/attachment.cgi?id=8851230 The documents that were evaluated in this self-assessment are available on the CA's website. All of these documents contain both the original text in Chinese, and the translation into English. Document Repository: https://www.gdca.com.cn/customer_service/knowledge_universe/cp_cps/ GDCA CP v1.5: https://www.gdca.com.cn/customer_service/knowledge_universe/cp_cps/CPCPS-GDCA1.5GDCA-CP-V1.5/ GDCA CPS v4.4: https://www.gdca.com.cn/customer_service/knowledge_universe/cp_cps/CPCPS-GDCA4.4GDCA-CPS-V4.4/ GDCA EV CP v1.3: https://www.gdca.com.cn/customer_service/knowledge_universe/cp_cps/CPCPS-GDCA-EV1.3GDCA-EV-CP-V1.3/ GDCA EV CPS v1.4: https://www.gdca.com.cn/customer_service/knowledge_universe/cp_cps/CPCPS-GDCA-EV1.4GDCA-EV-CPS-V1.4/ I will greatly appreciate it if you all would take another look at this CA's request, review their self-assessment, and respond in this discussion to let me know if you believe that this CA has addressed all of your questions or concerns. Also, I would like to make this BR-self-assessment a standard part of Mozilla's root inclusion/change process. I will draft what that will look like, and start a separate discussion about it. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
DRAFT - BR Self Assessments
All, As mentioned in the GDCA discussion[1], I would like to add a step to Mozilla's CA Inclusion/Update Request Process[2] in which the CA performs a self-assessment about their compliance with the CA/Browser Forum's Baseline Requirements. A draft of this new step is here: https://wiki.mozilla.org/CA:BRs-Self-Assessment It includes a link to a template for CA's BR Self Assessment, which is a Google Doc: https://docs.google.com/spreadsheets/d/1ni41Czial_mggcax8GuCBlInCt1mNOsqbEPzftuAuNQ/edit?usp=sharing Here's how I am considering introducing this new step. Of course, this only applies to CAs who are requesting the Websites trust bit. + For the CAs currently in the queue for discussion, I would ask them to perform this BR Self Assessment before I would start their discussion. + For CAs currently in the Information Verification phase, I would ask them to perform this BR Self Assessment before we would continue with Information Verification. + For new requests, we would have the BR Self Assessment be the very first step. I would greatly appreciate your feedback on adding this step to the root inclusion/update process, the wiki page draft, and the template. Thanks, Kathleen [1] https://groups.google.com/d/msg/mozilla.dev.security.policy/kB2JrygK7Vk/Kk7Le2F7CQAJ [2] https://wiki.mozilla.org/CA ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT - BR Self Assessments
On Wednesday, March 29, 2017 at 2:00:05 PM UTC-7, Jeremy Rowley wrote: > ... > An extension on this could be to have CAs annually file an updated mapping > with their WebTrust audit. That way it's a reminder that the CA needs to > notify Mozilla of changes in their process and keeps the CAs thinking about > updating practices to stay in-line with the baseline requirements. Plus, a > practice like that would provide better notice to the public on CA policy > changes and how CAs are responding to new threats. > Oh! I like that idea! The timing is good, as we are just now switching over to the new annual process: https://wiki.mozilla.org/CA:CommonCADatabase#How_To_Provide_Annual_Updates I could also say something about it in the CA Communication we are getting ready to send. Does anyone see a reason why we should *not* require a new BR-self-assessment annually from every CA with the Websites trust bit enabled? I think CAs could just attach it to their original root inclusion bug each year. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Automated email reminders about intermediate certs missing audit or CP/CPS
On Thursday, March 30, 2017 at 10:35:37 AM UTC-7, Kathleen Wilson wrote: > Within the next few days, we plan to start sending automated email reminders > to CAs about their intermediate cert records in the Common CA Database that > are missing audit or CP/CPS information. > > The email template is here: > https://wiki.mozilla.org/CA:Email_templates#Disclosure_Incomplete_Email_Template > We have deployed this to production, and the batch process is scheduled to run on the first and third Sunday of each month. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Next CA Communication
On Friday, March 24, 2017 at 3:11:17 AM UTC-7, Gervase Markham wrote: > On 23/03/17 23:07, Kathleen Wilson wrote: > > Second paragraph of Action 1 now says: ~~ Note that version 1.4.2 of > > the BRs does not contain all 10 of these methods, but it does contain > > section 3.2.2.4.11, "Other Methods", so the subsections of version > > 3.2.2.4 that are marked "Reserved" in version 1.4.2 of the BRs are > > still BR-compliant under version 1.4.2. By Mozilla policy, CAs are > > not permitted to rely on the "Other Methods" section to use methods > > of domain validation that are not among the 10 listed in section > > 3.2.2.4 of version 1.4.1 of the BRs. Mozilla expects that all of the > > methods for doing domain validation that are missing in version 1.4.2 > > of the BRs will be restored to a forthcoming version of the BRs, so > > we will once again be able to accept all of the methods of domain > > validation listed in the latest version of the BRs. ~~ > > That's not quite it, because the first bit is still confusing (my > fault), and the last para suggests we currently don't accept all methods > listed, which we do. Can we try the following? > > > Note that version 1.4.2 of the BRs does not contain all 10 of these > methods, but it does contain section 3.2.2.4.11, "Other Methods", so the > methods that were removed in version 1.4.2 of the BRs are still > BR-compliant under that version. By Mozilla policy, CAs are not > permitted to rely on the "Other Methods" section to use methods of > domain validation that are not among the 10 listed in section 3.2.2.4 of > version 1.4.1 of the BRs. As the IPR issues relating to these missing > methods have now been resolved, Mozilla expects that they will soon be > restored. Once they are, our policy will once again become that "we > accept all of the methods of domain validation explicitly listed in the > latest version of the BRs". > > Gerv Updated. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Next CA Communication
On Monday, March 20, 2017 at 10:59:41 AM UTC-7, Peter Bowen wrote: > On Mon, Mar 20, 2017 at 10:43 AM, Jeremy Rowley via > > [JR] This should be limited to SSL certs IMO. With client certs, you're > > going > > to get a lot more RAs that likely function under the standard or legal > > framework defining the certificate type. > > What if the question was scoped to "RAs that can do independent > validation of domain control" or some such? e.g. a classic "Enteprise > RA" set up where the CA's in-house RA confirms control of a public > suffix and then allows the Enterprise to internally confirm > certificate requests under the validated domain should not be counted > here. updated See action 9 here: https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S00G3K2 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Next CA Communication
On Monday, March 20, 2017 at 1:37:32 PM UTC-7, Jeremy Rowley wrote: > Something like: "Does your CA have any third-party Registration Authority > (RA)s program that the CA relies on to perform the domain validation > required under Section 3.2.2.4 of the Baseline Requirements." Updated ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Next CA Communication
On Monday, March 20, 2017 at 2:43:22 PM UTC-7, Gervase Markham wrote: > On 20/03/17 15:33, Kathleen Wilson wrote: > >> * Action 7: some of the BR Compliance bugs relate to CAs which are no > >> longer trusted, like StartCom. If StartCom does become a trusted CA > >> again, it will be with new systems which most likely do not have the > >> same bugs. Should we close the StartCom compliance bugs? > > > > Yes, I think that makes sense. > > OK, I've closed the StartCom and ANSSI bugs. Thanks! I also finished updating bugs: https://wiki.mozilla.org/CA/ca-bugs https://wiki.mozilla.org/CA_Bug_Triage#CA_Certificate_Issuance_Problems_and_Incidents > > >> * Action 8: Can we provide more structure here, by perhaps putting some > >> boilerplate text in the answer box or something like that? Or at least > >> list the sections and actions we expect to have been done? > > > > Changed to checkboxes and a follow-up text field. Please review. > > You've added a box: "All SHA-1 based TLS/SSL certificates chaining up to > our root certificates included in Mozilla’s CA Certificate Program have > either expired or been revoked." > > I don't think we _required_ revocation of all publicly-trusted SHA-1 > certs, did we? removed > > Also, the two about "all... certificates" might need to be changed to > "Our policy now is that all... certificates". Updated > > > See action 9 here: > > https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S00G3K2 > > You now need to remove the second bullet in this action, as it's > redundant with the reduced scope. > removed Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Next CA Communication
On Friday, March 17, 2017 at 9:17:07 AM UTC-7, Peter Bowen wrote: > I would replace this with: > > + Distinguished name and SHA-256 hash of the SubjectPublicKeyInfo of > each certificate issuer covered by the audit scope > + Clear indication of which in-scope certificate issuers are Root CAs > Is this OK? + Distinguished name (Certificate Subject Field) and SHA1 or SHA256 fingerprint of each certificate issuer covered by the audit scope + Clear indication of which in-scope certificate issuers are Root CAs We are looking for human-readable information, so want a name and a fingerprint. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Taiwan GRCA Root Renewal Request
All, My apologies for taking so long to get back to this discussion about the Government of Taiwan's (GRCA's) request to include their Government Root Certification Authority root certificate, and turn on the Websites and Email trust bits. Note that GRCA has suggested that this root be constrained to *.tw. To my knowledge, the questions and concerns raised about this request have been resolved. In particular: 1) There are several intermediate certificates that are technically capable of issuing TLS certificates, but have not been audited according to the BRs. We have resolved this particular situation in the past by having the CA get an audit statement saying that the intermediate certificate has not issued TLS certificates during the audit period. And requiring that the CA get such an audit statement annually. GRCA has provided the requested audit statement: https://www.google.com/url?q=https%3A%2F%2Fbug1065896.bmoattachments.org%2Fattachment.cgi%3Fid%3D8835815=D=1=AFQjCNH9syh0sbLxMj35bdC1TDeQslx32w 2) The new root certificate has the same exact full distinguished name as the old root certificate. My recommendation is that we allow it this time, but not for future root certs from this CA. So, if there are no further questions or comments about this CA's request, then I will close this discussion and recommend approval in the bug. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Include Renewed Kamu SM root certificate
Thanks to those of you who have reviewed and commented on this request from the Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM), to include the "TUBITAK Kamu SM SSL Kok Sertifikasi - Surum 1" root certificate, and enable the Websites trust bit. I believe that all of the questions and concerns that have been raised in this discussion have been resolved. If there are no further questions or concerns about this request, then I will close this discussion and recommend approval in the bug. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Include Renewed Kamu SM root certificate
On Wednesday, March 15, 2017 at 9:56:25 AM UTC-7, Kathleen Wilson wrote: > Thanks to those of you who have reviewed and commented on this request from > the Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM), to include > the "TUBITAK Kamu SM SSL Kok Sertifikasi - Surum 1" root certificate, and > enable the Websites trust bit. Thanks again to those of you who have reviewed this request, and to those of you who have participated in this discussion. I am now closing this discussion, and I will update the bug to recommend approval of this request. All further follow-up on this request should be in the bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1262809 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
Here's a summary of the audit reminder email that was sent today. Note that the email now tells CAs to provide their annual updates via the Common CA Database, as follows. "Please provide your annual updates via the Common CA Database (CCADB), as described here: https://wiki.mozilla.org/CA:CommonCADatabase#Updating_Audit_Information " Also note that for root certificates with the Websites trust bit enabled, the annual updates must include: 1) Current audit statements 2) Update CP/CPS documents* 3) Test websites (valid, revoked, expired)** * Section 2 of the BRs: The CA SHALL develop, implement, enforce, and *annually update* a Certificate Policy and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements. ** Section 2.2 of the BRs: The CA SHALL host test Web pages that allow Application Software Suppliers to test their software with Subscriber Certificates that chain up to each publicly trusted Root Certificate. At a minimum, the *CA SHALL host separate Web pages using Subscriber Certificates that are (i) valid, (ii) revoked, and (iii) expired.* Forwarded Message Subject:Summary of March 2017 Audit Reminder Emails Date: Tue, 21 Mar 2017 19:03:58 + (GMT) From: Mozilla CA Program Manager Mozilla: Audit Reminder Root Certificates: SZAFIR ROOT CA2 Standard Audit: https://cert.webtrust.org/SealFile?seal=2018=pdf Audit Statement Date: 2016-03-18 BR Audit: https://cert.webtrust.org/SealFile?seal=2018=pdf BR Audit Statement Date: 2016-03-18 CA Comments: null Mozilla: Audit Reminder Root Certificates: Autoridad de Certificacion Firmaprofesional CIF A62634068 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: BR and EV audits have happened, but there are action plans being presented to the auditors. Primary issues are use of UTF8 instead of PrintableString in jurisdictionOfIncorporation, and a recently repealed Spanish law that required privat Mozilla: Audit Reminder Root Certificates: Buypass Class 2 Root CA Buypass Class 3 Root CA Standard Audit: http://www.buypass.no/om-buypass/etsi-102-042/_attachment/33325?_download=true&_ts=14bc532b650 Audit Statement Date: 2016-03-23 BR Audit: http://www.buypass.no/om-buypass/etsi-102-042/_attachment/33325?_download=true&_ts=14bc532b650 BR Audit Statement Date: 2016-03-23 EV Audit: http://www.buypass.no/om-buypass/etsi-102-042/_attachment/33325?_download=true&_ts=14bc532b650 EV Audit Statement Date: 2016-03-23 CA Comments: null Mozilla: Audit Reminder Root Certificates: Cybertrust Global Root DigiCert Assured ID Root G2 DigiCert Assured ID Root G3 DigiCert Global Root G2 DigiCert Global Root G3 DigiCert High Assurance EV Root CA DigiCert Trusted Root G4 Standard Audit: https://cert.webtrust.org/SealFile?seal=2165=pdf Audit Statement Date: 2016-10-24 Standard Audit: https://cert.webtrust.org/SealFile?seal=2020=pdf Audit Statement Date: 2016-06-27 BR Audit: https://cert.webtrust.org/SealFile?seal=2016=pdf BR Audit Statement Date: 2016-03-18 BR Audit: https://cert.webtrust.org/SealFile?seal=2021=pdf BR Audit Statement Date: 2016-06-27 EV Audit: https://cert.webtrust.org/SealFile?seal=2166=pdf EV Audit Statement Date: 2016-10-24 EV Audit: https://cert.webtrust.org/SealFile?seal=2022=pdf EV Audit Statement Date: 2016-04-07 CA Comments: null Mozilla: Audit Reminder Root Certificates: Hongkong Post Root CA 1 Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8732899 Audit Statement Date: 2016-02-26 BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8746166 BR Audit Statement Date: 2016-03-31 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=2013=pdf Audit Statement Date: 2016-03-28 BR Audit: https://cert.webtrust.org/SealFile?seal=2011=pdf BR Audit Statement Date: 2016-03-28 EV Audit: https://cert.webtrust.org/SealFile?seal=2012=pdf EV Audit Statement Date: 2016-03-28 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 Gold CA - G2 SwissSign Platinum CA - G2 SwissSign Silver CA - G2 Standard Audit: https://bug343756.bmoattachments.org/attachment.cgi?id=8781268 Audit Statement Date: 2016-03-18 BR Audit: https://bug343756.bmoattachments.org/attachment.cgi?id=8781268 BR Audit
Re: Next CA Communication
On Tuesday, April 4, 2017 at 10:38:28 AM UTC-7, Kathleen Wilson wrote: > > The email has been sent, and the survey is open. > Published a security blog about it: https://blog.mozilla.org/security/2017/04/04/mozilla-releases-version-2-4-ca-certificate-policy/ Cheers, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT - BR Self Assessments
I updated https://wiki.mozilla.org/CA:BRs-Self-Assessment to add a section called 'Annual BR Self Assessment', which states: "CAs with included root certificates that have the Websites trust bit set must do an annual self-assessment of their compliance with the BRs, and must update their CP and CPS documents at least once every year." I added a section about this to the root inclusion/update Information Checklist: https://wiki.mozilla.org/CA:Information_checklist#Baseline_Requirements_Self_Assessement And I updated ACTION 2 of the CA Communication https://mozillacaprogram.secure.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a05o03WrzBC to include a link to this. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Next CA Communication
On Saturday, April 1, 2017 at 3:59:28 AM UTC-7, Gervase Markham wrote: > On 31/03/17 22:20, Kathleen Wilson wrote: > > Please let me know asap if you see any problems, typos, etc. in this > > version. > > Now that policy 2.4.1 has been published, we should update Action 3 to > say the following at the top: > > Versions 2.4 and 2.4.1 of Mozilla's CA Certificate Policy have been > published. Differences between 2.4 and 2.3 (published Dec 2016), > and between 2.4 and 2.2 (published July 2013) may be viewed on > Github. Version 2.4.1 contains exactly the same normative requirements > as version 2.4 but has been completely reorganized. Please review > version 2.4.1 policy and confirm that your CA complies with it. > > https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ still shows version 2.4. Shall I wait until it shows version 2.4.1 before I send the CA Communication? Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Next CA Communication
On Monday, April 3, 2017 at 2:21:14 PM UTC-7, Kathleen Wilson wrote: > All, > > I'm getting ready to send the April 2017 CA Communication email. > > I updated the wiki page to have the survey introduction text, and a > (read-only) link to the full survey: > https://wiki.mozilla.org/CA:Communications#April_2017 > > The survey in the Common CA Database is now open, with an expiration date of > May 1. > > The text for the mass email is ready (see below). I have it set to be sent to > the CA's email alias and CC'd to the Primary Points of Contact for each CA > currently included in Mozilla's program. > The email has been sent, and the survey is open. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Next CA Communication
I have moved the draft of the April 2017 CA Communication to production, so the link has changed to: https://mozillacaprogram.secure.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a05o03WrzBC It is also available here: https://wiki.mozilla.org/CA:Communications#April_2017 Note to CAs: The survey is now visible in the CCADB via the "CA Communications (Page)" tab, but DO NOT TAKE THE SURVEY YET. You will not be able to submit your survey answers until I update the "Expiration Date" to a date in the future. I will do this when the survey is ready to be sent. Notable changes in this version: 1) Added free text Comments boxes to many of the action items. 2) Added ACTION 14: CERTIFICATE VALIDITY PERIODS IN TLS/SSL CERTS 3) Updated the last two bullet points in ACTION 5... + The word "clean" must be included in audit statements for which no problems were noted. + For ETSI - the attestation should additionally state that the audit was a full audit, and must indicate which parts of the criteria applied (e.g. DVCP, OVCP, NCP, NCP+, LCP, EVCP, EVCP+, QCP-w, Part1 (General Requirements), Part 2 (Requirements for trust services Providers issuing EU qualified certificates)). 4) Moved the "respond by" date to April 28. Please let me know asap if you see any problems, typos, etc. in this version. I would like to send this CA Communication next week. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Extend deadline for April 2017 CA Communication?
All, I've been receiving requests from CAs for an extension to when they need to respond to the April 2017 CA Communication. https://wiki.mozilla.org/CA:Communications#April_2017 "To respond to this survey, login to the Common CA Database (CCADB), click on the 'CA Communications (Page)' tab, and select the 'April 2017 CA Communication' survey. Please enter your response by April 28, 2017." I propose that we extend the response date one week, to May 5, 2017. Please let me know if you foresee any problems with this. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Include Additional D-TRUST root certificate
Thank you to those of you who have reviewed this request, and to those of you who have participated in this discussion. I am now closing this discussion, and I will update the bug to recommend approval of this request from D-TRUST to include the D-TRUST Root CA 3 2013 root certificate and enable the Email trust bit. All further follow-up on this request should be in the bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1166723 Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Include Additional D-TRUST root certificate
On Wednesday, December 21, 2016 at 11:03:18 AM UTC-8, Kathleen Wilson wrote: > This request from D-TRUST is to included the ‘D-TRUST Root CA 3 2013’ root > certificate and enable the Email trust bit. > > D-TRUST GmbH is a subsidiary of Bundesdruckerei GmbH and is fully owned by > the German State. D-TRUST currently has two root certificates included in > Mozilla’s program. The ‘D-TRUST Root Class 3 CA 2 2009’ and ‘D-TRUST Root > Class 3 CA 2 EV 2009’ root certificates are currently enabled with the > Websites trust bit, and were included via Bugzilla bug #467891. In Europe > D-TRUST wants to promote the use of signed and encrypted email, so D-Trust is > offering different types of certificates for this use case: Personal, Team > and Device IDs. > > The request is documented in the following bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=1166723 > > All, D-Trust (a currently included CA, in good standing) is requesting that a new root certificate be included, but only to have the Email trust bit enabled for it. Therefore, I plan to close this discussion and recommend approval in the bug. Please reply asap if you have any concerns about this. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Include Renewed Kamu SM root certificate
Thank you Andrew and Ryan for your feedback on this request to include the "TUBITAK Kamu SM SSL Kok Sertifikasi - Surum 1" root certificate, and enable the Websites trust bit. Note that the new SHA-256 root certificate will replace the SHA1 “TÜBİTAK UEKAE Kök Sertifika Hizmet Sağlayıcısı - Sürüm 3” root certificate that is currently included, but expires on August 21, 2017. So, this CA will greatly appreciate prompt feedback from everyone. I have attached the updated version of the CPS (v1.0.1) to the bug: https://bug1262809.bmoattachments.org/attachment.cgi?id=8844549 Of course, all of this CA’s CPS changes will need to be propagated back to the Turkish version of the CPS, and to the CA's website. But let's see if there is any further feedback first. Andrew, does the updated CPS fully address your questions/concerns? Ryan, in regards to your feedback: 1) Domain Validation Methods For the CA, I recommend reviewing section 3.2.2.4 of version 1.4.1 of the CA/Browser Forum’s Baseline Requirements, because many of the relevant subsections are currently redacted in version 1.4.2 due to ongoing discussions in the CAB Forum. Nevertheless, the CA can review version 1.4.1 to further bolster their domain validation policies and practices. I am hoping that the CAB Forum will resolve the issues that caused the redaction of some sections of the BRs, such that a new version will be published by the end of March that has the same level of information about domain validation as version 1.4.1 of the BRs. Gerv and I plan to send a CA Communication around the end of March, and plan for one of the action items to require that CAs update their CP/CPS, because it should be updated annually. And also to update their domain validation practices and policies. 2) Qualified audit statement listing serial number generation deficiencies for the time period from September 30, 2016 to when it was fixed by the CA. There is a lag between when a BR is updated/adopted, and when the audit principles/criteria are adopted. So, I am not convinced that an audit during that time period would cover that particular control, and list it as an exception in the audit statement. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Next CA Communication
On Monday, April 3, 2017 at 10:13:22 AM UTC-7, Kathleen Wilson wrote: > https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ > still shows version 2.4. It's been updated to version 2.4.1. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Common CA Database updated with new logos
All, The Common CA Database has been updated with the new CCADB logos. This means that when you go to login to the CA Community, at https://mozillacacommunity.force.com you will see the full "Common CA Database" logo. (before it just had the old "mozilla" logo). And when you are logged into the CCADB you will notice that the logo in the top left corner of the window says "m | CCADB", instead of "mozilla". I do not have any say in the details of the logo, so feedback on it is not needed. This is just a heads-up in case you notice that it looks different than it used to, and want to make sure you're still going to the correct place. Cheers, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT - BR Self Assessments
On Saturday, April 22, 2017 at 5:25:35 AM UTC-7, wangs...@gmail.com wrote: > We have a question about completing the BR self assessment, > is it necessary that all the BRs requirements appear in > relevant sections of the CP/CPS? It is OK if the information is in different sections in the CP/CPS, just be sure to indicate which sections of the CP/CPS the information is in. > Or for some BRs requirements that are not specifically > disclosed in the CP/CPS, CAs can explain their rules and > practices to show that they meet or exceed these requirements? Per section 3.3 Mozilla's CA Certificate Policy: https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ "We rely on publicly disclosed documentation (e.g., in a Certificate Policy and Certification Practice Statement) to ascertain that our requirements are met." So, for the most part, the information must be available in publicly disclosed documentation that is available on the CA's website. And in the BR Self Assessment you need to clearly indicate which document and which section of the document shows that your CA meets the BR. There are items, such as the three test websites, that we can verify directly, so those items do not need to be in the CP/CPS documents. When you are doing your BR Self Assessment, if you find that the required information is not currently in your CP/CPS documents, then you may indicate what your CA currently does, how it is currently documented, that the next version of your CP/CPS will contain this information, and when the next version of your CP/CPS will be available. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Updating Bugzilla Product/Component groups for CA Program Bugs
All, This is just for informational purposes... I have filed Bug #1359112 to update the Bugzilla Product/Components for the CA Program Bugs. The bugs asks: ~~ Current Product: NSS Current Component Name: CA Certificates change to Product: NSS Component Name: CA Certificate Code Current Product: mozilla.org Current Component Name: CA Certificate Mis-Issuance Change to Product: NSS Component Name: CA Certificate Mis-Issuance Current Product: mozilla.org Current Component Name: CA Certificates Change to Product: NSS Component Name: CA Certificate Root Program ~~ So, the result will be that all CA Program related bugs will be in the NSS Product group in Bugzilla. And the NSS Product group will have the following Components: Build CA Certificate Code CA Certificate Mis-Issuance CA Certificate Root Program Documentation Libraries Test Tools This will impact saved Bugzilla searches regarding CA Program bugs. And wiki pages referring to the Bugzilla Product/Components regarding CA program bugs will need to be updated -- will try to take care of that soon after the change. Cheers, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DigiCert-Symantec Announcement
On Wednesday, August 2, 2017 at 2:13:40 PM UTC-7, Jeremy Rowley wrote: > Today, DigiCert and Symantec announced that DigiCert is acquiring the > Symantec CA assets, including the infrastructure, personnel, roots, and > platforms. At the same time, DigiCert signed a Sub CA agreement wherein we > will validate and issue all Symantec certs as of Dec 1, 2017. Thanks for posting this information here. Pointer to DigiCert's blog: https://www.digicert.com/blog/digicert-to-acquire-symantec-website-security-business/ > Two things I can say we plan on doing (following closing) to address > concerns are: > > a.We plan to segregate certs by type on each root. Going forward, we > will issue all SSL certs from a root while client and email come from > different roots. I would like to see all CAs move in this direction. > We also plan on limiting the number of organizations on > each issuing CA. We hope this will help address the "too big to fail" issue > seen with Symantec. By segregating end entities into roots and sub CAs, the > browsers can add affected Sub CAs to their CRL lists quickly and without > impacting the entire ecosystem. This plan is very much in flux, and we'd > love to hear additional recommendations. I greatly appreciate your consideration in this area! Perhaps there can be different subCAs for large organizations versus smaller/individual site operators (that might be covered as different brands). Of course, I'm always in favor of technically-constrained subCAs for the large organizations. And perhaps one (or more) of the subCAs can be dedicated to short-lived SSL certs, similar to Let's Encrypt? > b.Another thing we are doing is adding a validation OID to all of our > certificates that identifies which of the BR methods were used to issue the > cert. This way the entire community can readily identify which method was > used when issuing a cert and take action if a method is deemed weak or > insufficient. We think this is a huge improvement over the existing > landscape, and I'm very excited to see that OID rolled out. I would like to see all CAs move in this direction as well. Looks like you are going to be very busy! :-) Thanks, and good luck! Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: StartCom cross-signs disclosed by Certinomis
Jonathan, Thank you for bringing this to our attention. I have filed two bugs... 1) https://bugzilla.mozilla.org/show_bug.cgi?id=1386891 Certinomis: Cross-signing of StartCom intermediate certs, and delay in reporting it in CCADB 2) https://bugzilla.mozilla.org/show_bug.cgi?id=1386894 Add "StartCom BR SSL ICA” and "StartCom EV SSL ICA” intermediate certs to OneCRL We will look into this further, and will appreciate any further relevant information. I will also appreciate explanation from Certinomis and StartCom. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: StartCom cross-signs disclosed by Certinomis
All, I have conflicting opinions about this situation: On the one hand, I want to see better behavior, and am inclinded to add these two intermediate certs to OneCRL, and tell StartCom and Certinomis to start over and do things right. On the other hand, I'm not convinced yet that the issued non-BR-compliant certs are any worse than we've seen from other CAs for whom we tell them to fix the problem but do not add their relevant intermediate certs to OneCRL. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Remove old WoSign root certs from NSS
On Monday, July 10, 2017 at 12:47:31 PM UTC-7, Kathleen Wilson wrote: > I also think we should remove the old WoSign root certs from NSS. > > Reference: > https://wiki.mozilla.org/CA/Additional_Trust_Changes#WoSign > ~~ > Mozilla currently recommends not trusting any certificates issued by this CA > after October 21st, 2016. That recommendation covers the following roots: > > CN=CA 沃通根证书, OU=null, O=WoSign CA Limited, C=CN > CN=Certification Authority of WoSign, OU=null, O=WoSign CA Limited, C=CN > CN=Certification Authority of WoSign G2, OU=null, O=WoSign CA Limited, > C=CN > CN=CA WoSign ECC Root, OU=null, O=WoSign CA Limited, C=CN > > This restriction has been implemented in both in the Mozilla platform > security code (PSM), which is shared by the Mozilla applications (Firefox, > Thunderbird, etc.), and in addition, in the NSS library code, which is used > by applications that use the NSS certificate verification APIs. > ~~ > > Please let me know if you foresee any problems with removing these root certs > from NSS. > > Thanks, > Kathleen I have filed Bug #1387260 to remove the old WoSign root certificates. This will likely happen in the October batch of root changes. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: StartCom cross-signs disclosed by Certinomis
On Thursday, August 3, 2017 at 3:09:25 PM UTC-7, Kurt Roeckx wrote: > I would really like to see that they have at least opened a bug to > request the inclusion of that CA before it's cross-signed. Here's StartCom's current root inclusion request: https://bugzilla.mozilla.org/show_bug.cgi?id=1381406 > It should > have already all the requirements that Mozilla has for including the > root CA certificate before it's cross signed. Correct. That should be true for all subCAs that are cross-signed by currently-included CAs. > > I would prefer that it's even included in the Mozilla root store > before it's cross signed, That might not be fair, given how long Mozilla's root inclusion process takes, and that we don't require this of other CAs who are new to our program. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: StartCom cross-signs disclosed by Certinomis
On Thursday, August 3, 2017 at 4:34:27 PM UTC-7, Ryan Sleevi wrote: > I do hope you can clarify whether remediations apply to keys operated by > organizations, or whether they apply to the organization themselves. https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 says: "StartCom may apply for inclusion of new (replacement) root certificates[1] following Mozilla's normal root inclusion/change process[2] (minus waiting in the queue for the discussion), after they have completed all of the following action items, and shown that WoSign has no control (people or code) over StartCom." So, the remediations do apply to the organization. > If they apply to the organization, one would naturally expect they apply to > root inclusion or cross-signs, and the organization is no longer "treated > like a new CA," because they are no longer a new CA - they are an existing > one. > OK. Clearly I hadn't thought of it this way. > It is also worth noting that in the past, Mozilla directed other CAs that > cross-signing of their (new) roots would be expressly forbidden until the > corrective actions were taken and publicly reviewed. For example, allowing > CNNIC to be cross-signed prior to remediation would have defeated the entire > purpose of removal. In bug #1311832 there is a note about cross-signing: "[1] The new (replacement) root certificates may be cross-signed by the Affected Roots. However, the Affected Roots may *not* be cross-signed by the new (replacement) root certificates, because that would bring the concerns about the Affected Roots into the scope of the new roots. Due to the way we are implementing the distrust, the new root certificates must have a Subject Distinguished Name that does not overlap with the Subject Distinguished Names listed above." I don't see anything expressly forbidding cross-signing of new roots, but perhaps that was an oversight. > > In this larger light, it would also seem that StartCom, having misissued a > number of certificates already under their new hierarchy, which present a > risk to Mozilla users (revocation is neither an excuse nor a mitigation for > misissuance), should be required to take corrective steps and generate a new > hierarchy that is not, out of the gate, presenting risk to the overall > community due to its past misissuances. We can and should expect more of new > keys being included, because the compatibility risk of expecting adherence to > the Root Policy is non-existent. To me, this is very convincing that we should add the two StartCom intermediate certs to OneCRL. Along this line of discussion, I have not felt comfortable with StartCom's current root inclusion request (bug #1381406), because Hanno raised a concern about the private key used by the new root is also used by two intermediate certificates, one of them revoked. This doesn't see like good practice to me, and I'm not sure that Inigo's response is sufficient. So, I'm also wondering if I should close Bug #1381406 and request StartCom to start completely over with their new CA Hierarchy, and get it right, before creating their next root inclusion request. I will appreciate thoughtful and constructive feedback on this as well. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: High traffic on this list, and Mozilla root program involvement
All, While I understand the desire to normally have one Bugzilla Bug per root cause per CA, I do not have the bandwidth to do this. So, I am going to create one bug per CA that I find in the recent m.d.s.policy posts, and list all of the problems pertaining to that CA in their bug. Thanks to all of you for all of your efforts towards cleaning up the CA ecosystem. It has and will take a lot of work, but I greatly appreciate the forward momentum. For those of you awaiting response from me to your emails, please be patient as I am going to work on this for a while. (my inbox is a mess, so if there is anything urgent please put URGENT at the beginning of the email subject) Cheers, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Bugzilla Bugs re CA issuance of non-compliant certs
All, I have gone through the July/August posts in m.d.s.policy in order to determine which Bugzilla Bugs I should file. There are two outliers: ~~ ** Undisclosed intermediates, or those missing audits I have been working diligently on intermediate cert disclosures in the CCADB for many months now. I greatly appreciate the web pages that Rob Stradling created to help me with this effort!!! This has also included work on adding revoked intermediate certs to OneCRL, and I hope the other major root store operators will catch up on this: https://crt.sh/revoked-intermediates Anyways, I have been working on those separately and in contact with those CAs, so I do not plan to file separate bugs, beyond what I have already done or am doing. ** Common Name not in SAN https://groups.google.com/d/msg/mozilla.dev.security.policy/K3sk5ZMv2DE/4oVzlN1xBgAJ It is not clear to me if I need to add this item to the Bugzilla Bugs that I will be filing. Please let me know if you think I need to add this item to the bugs. ~~ Here’s a summary of the bugs that I plan to file as a result of the recent activity in m.d.s.policy. (one bug per CA listed below) My expectation is that the CAs will provide the following information in their bugs: 1) Confirmation that the CA has stopped issuance of certs with these problems. 2) Explanation about how/why the mistakes were made, and not caught/fixed earlier. 3) List of steps the CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when the CA expects to accomplish these things. 4) Updates to confirm when those steps have been completed. I do *NOT* necessarily expect the CAs to revoke all of these certificates. I expect the CAs to do a careful analysis of the situation and determine/explain whether or not they will revoke the certs or let the expire. If the choice is to let them expire, there needs to be good reasons and a timeline for when the bulks of certs will expire. We (Mozilla community) will evaluate such information and provide constructive feedback, and I or Gerv will add a comment in the bug to confirm if the plan (when not revoking) is acceptable, or to state if we/Mozilla will require revocation. Thanks, Kathleen == Actalis == Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position) https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ == Camerfirma == Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position) https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ URI in dNSName SAN https://groups.google.com/d/msg/mozilla.dev.security.policy/etp2Yz2fmM4/ayBTsfJnBgAJ == Certinomis == Invalidly long serial numbers (Serial Number > 20 Octets) https://groups.google.com/d/msg/mozilla.dev.security.policy/b33_4CyJbWI/74sItqcvBgAJ Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position) https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ == certSIGN == Invalid common name and invalid SAN dnsName https://groups.google.com/d/msg/mozilla.dev.security.policy/ETG72kifv4k/2BD-CVDDAAAJ == Comodo == Certificates with metadata-only subject fields (at least one subject field that only contains ASCII punctuation characters) https://groups.google.com/d/msg/mozilla.dev.security.policy/Sae5lpT02Ng/-lsC11JnBwAJ Prevent further issuance of certs with N/A and other metadata but revocation not necessary in this case. Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position) https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ == Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert) == Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position) https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ == D-TRUST == dNSName containing '/' https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/uD-Li1w1BgAJ Short / sequential-looking serial numbers https://groups.google.com/d/msg/mozilla.dev.security.policy/vl5eq0PoJxY/uD-Li1w1BgAJ https://groups.google.com/d/msg/mozilla.dev.security.policy/YequotPYLdc/J0K3lUyzBwAJ RESOLUTION: https://groups.google.com/d/msg/mozilla.dev.security.policy/UnR98QjWQQs/O-Hf5T4WBwAJ == DigiCert == (Bug #1389172 already created by Jeremy - for the first 3 items
Re: Bugzilla Bugs re CA issuance of non-compliant certs
Feedback will be appreciated on the following draft for the Bugzilla Bugs that I will be filing for the problems listed below. Product: NSS Component: CA Certificate Mis-Issuance Whiteboard: [ca-compliance] Blocks: 1029147 Summary: : Non-BR-Compliant Certificate Issuance Description: The following problems have been found in certificates issued by your CA, and reported in the mozilla.dev.security.policy forum. Direct links to those discussions are provided for your convenience. To continue inclusion of your CA’s root certificates in Mozilla’s Root Store, you must respond in this bug to provide the following information: 1) Prompt confirmation that your CA has stopped issuing TLS/SSL certificates with the problems listed below. 2) Explanation about how and why the mistakes were made, and not caught and fixed earlier. 3) List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things. 4) Regular updates to confirm when those steps have been completed. Note Section 4.9.1.1 of the CA/Browser Forum’s Baseline Requirements, which states: “The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs: … 9. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement; 10. The CA determines that any of the information appearing in the Certificate is inaccurate or misleading; … 14. Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement; or 15. The technical content or format of the Certificate presents an unacceptable risk to Application Software Suppliers or Relying Parties (e.g. the CA/Browser Forum might determine that a deprecated cryptographic/signature algorithm or key size presents an unacceptable risk and that such Certificates should be revoked and replaced by CAs within a given period of time). However, it is not our intent to introduce additional problems by forcing the immediate revocation of certificates that are not BR compliant when they do not pose an urgent security concern. Therefore, we request that your CA perform careful analysis of the situation and if there is justification to not revoke the problematic certificates, then explain those reasons and provide a timeline for when the bulks of the certificates will expire or be revoked/replaced. We expect that your forthcoming audit statements will indicate the findings of these problems. If your CA will not be revoking the certificates within 24 hours in accordance with the BRs, then that will also need to be listed as a finding in your CA’s BR audit statement. We expect that your CA will work with your auditor (and supervisory body, as appropriate) and the Root Store(s) that your CA participates in to ensure your analysis of the risk and plan of remediation is acceptable. If your CA will not be revoking the problematic certificates as required by the BRs, then we recommend that you also contact the other root programs that your CA participates in to acknowledge this non-compliance and discuss what expectations their Root Programs have with respect to these certificates. The problems reported for your CA in the mozilla.dev.security.policy forum are as follows: ** Failure to respond within 24 hours after Problem Report submitted https://groups.google.com/d/msg/mozilla.dev.security.policy/PrsDfS8AMEk/w2AMK81jAQAJ ** ~~ END DRAFT ~~ Updated list: == Actalis == Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position) https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ == Camerfirma == Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position) https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ URI in dNSName SAN https://groups.google.com/d/msg/mozilla.dev.security.policy/etp2Yz2fmM4/ayBTsfJnBgAJ == Certinomis == Invalidly long serial numbers (Serial Number > 20 Octets) https://groups.google.com/d/msg/mozilla.dev.security.policy/b33_4CyJbWI/74sItqcvBgAJ Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position) https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ == certSIGN == Invalid common name and invalid SAN dnsName https://groups.google.com/d/msg/mozilla.dev.security.policy/ETG72kifv4k/2BD-CVDDAAAJ == Comodo == Certificates with metadata-only subject fields (at least one subject field that only contains ASCII punctuation
Re: Bugzilla Bugs re CA issuance of non-compliant certs
On Tuesday, August 15, 2017 at 12:46:36 PM UTC-7, Ryan Sleevi wrote: > > The requirement for revocation comes from the Baseline Requirements. > > Could you clarify your expectations regarding CAs' violation of the > Baseline Requirements with respect to these issues and Section 4.9.1.1. Are you specifically referring to item #9 of Section 4.9.1.1? Or other items in that list? For reference for everyone, here's what Section 4.9.1.1 currently says: ~~ The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs: 1. The Subscriber requests in writing that the CA revoke the Certificate; 2. The Subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization; 3. The CA obtains evidence that the Subscriber’s Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise or no longer complies with the requirements of Sections 6.1.5 and 6.1.6; 4. The CA obtains evidence that the Certificate was misused; 5. The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber Agreement or Terms of Use; 6. The CA is made aware of any circumstance indicating that use of a Fully-Qualified Domain Name or IP address in the Certificate is no longer legally permitted (e.g. a court or arbitrator has revoked a Domain Name Registrant’s right to use the Domain Name, a relevant licensing or services agreement between the Domain Name Registrant and the Applicant has terminated, or the Domain Name Registrant has failed to renew the Domain Name); 7. The CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully-Qualified Domain Name; 8. The CA is made aware of a material change in the information contained in the Certificate; 9. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement; 10. The CA determines that any of the information appearing in the Certificate is inaccurate or misleading; 11. The CA ceases operations for any reason and has not made arrangements for another CA to provide revocation support for the Certificate; 12. The CA’s right to issue Certificates under these Requirements expires or is revoked or terminated, unless the CA has made arrangements to continue maintaining the CRL/OCSP Repository; 13. The CA is made aware of a possible compromise of the Private Key of the Subordinate CA used for issuing the Certificate; 14. Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement; or 15. The technical content or format of the Certificate presents an unacceptable risk to Application Software Suppliers or Relying Parties (e.g. the CA/Browser Forum might determine that a deprecated cryptographic/signature algorithm or key size presents an unacceptable risk and that such Certificates should be revoked and replaced by CAs within a given period of time). ~~ 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
Forwarded Message Subject: Summary of August 2017 Audit Reminder Emails Date: Tue, 15 Aug 2017 19:00:07 + (GMT) Mozilla: Overdue Audit Statements Root Certificates: Autoridad de Certificacion Firmaprofesional CIF A62634068 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: BR and EV audits have happened, but there are action plans being presented to the auditors. Primary issues are use of UTF8 instead of PrintableString in jurisdictionOfIncorporation, and a recently repealed Spanish law that required privat Mozilla: Audit Reminder Root Certificates: Chambers of Commerce Root Chambers of Commerce Root - 2008 Global Chambersign Root Global Chambersign Root - 2008 Standard Audit: https://bug986854.bmoattachments.org/attachment.cgi?id=8775118 Audit Statement Date: 2016-06-17 BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8800807 BR Audit Statement Date: 2016-08-05 EV Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8800811 EV Audit Statement Date: 2016-08-05 CA Comments: null Mozilla: Audit Reminder Root Certificates: Certinomis - Root CA Certinomis - Autorité Racine Standard Audit: https://bug937589.bmoattachments.org/attachment.cgi?id=8784555 Audit Statement Date: 2016-08-23 BR Audit: https://bug937589.bmoattachments.org/attachment.cgi?id=8784555 BR Audit Statement Date: 2016-08-23 CA Comments: null Mozilla: Audit Reminder Root Certificates: AffirmTrust Commercial AffirmTrust Networking AffirmTrust Premium AffirmTrust Premium ECC Standard Audit: https://cert.webtrust.org/SealFile?seal=2115=pdf Audit Statement Date: 2016-06-30 BR Audit: https://cert.webtrust.org/SealFile?seal=2116=pdf BR Audit Statement Date: 2016-06-30 EV Audit: https://cert.webtrust.org/SealFile?seal=2093=pdf EV Audit Statement Date: 2016-06-30 CA Comments: null Mozilla: Audit Reminder Root Certificates: E-Tugra Certification Authority Standard Audit: https://bug877744.bmoattachments.org/attachment.cgi?id=8792625 Audit Statement Date: 2016-09-09 BR Audit: https://bug877744.bmoattachments.org/attachment.cgi?id=8792625 BR Audit Statement Date: 2016-09-09 EV Audit: https://bug877744.bmoattachments.org/attachment.cgi?id=8792625 EV Audit Statement Date: 2016-09-09 CA Comments: null Mozilla: Audit Reminder Root Certificates: GlobalSign ECC Root CA - R5** GlobalSign Root CA - R3** GlobalSign Root CA** GlobalSign Extended Validation CA - SHA256 - G2 - intermediate cert being treated as root during transition** ** Audit Case in the Common CA Database is under review for this root certificate. Standard Audit: https://cert.webtrust.org/SealFile?seal=2056=pdf Audit Statement Date: 2016-06-10 BR Audit: https://cert.webtrust.org/SealFile?seal=2054=pdf BR Audit Statement Date: 2016-06-10 EV Audit: https://cert.webtrust.org/SealFile?seal=2055=pdf EV Audit Statement Date: 2016-06-10 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://bugzilla.mozilla.org/attachment.cgi?id=8815072 Audit Statement Date: 2016-08-31 BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8815073 BR Audit Statement Date: 2016-08-31 EV Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8815074 EV Audit Statement Date: 2016-08-31 CA Comments: null Mozilla: Audit Reminder Root Certificates: ACCVRAIZ1 Standard Audit: https://cert.webtrust.org/SealFile?seal=2170=pdf Audit Statement Date: 2016-08-17 BR Audit: https://cert.webtrust.org/SealFile?seal=2171=pdf BR Audit Statement Date: 2016-08-17 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 ACES CA X6 DST Root CA X3 Standard Audit: https://cert.webtrust.org/SealFile?seal=2107=pdf Audit Statement Date: 2016-08-19 BR Audit: https://cert.webtrust.org/SealFile?seal=2106=pdf BR Audit Statement Date: 2016-08-19 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 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:
Re: Bugzilla Bugs re CA issuance of non-compliant certs
On Tuesday, August 15, 2017 at 1:00:04 PM UTC-7, Jonathan Rudenberg wrote: > It’s worth noting that with the exception of the metadata-only > subject fields issue, Alex and I have attempted to contact every > CA listed directly via their public certificate problem reporting channels. Good point, so in each Bugzilla Bug I should also add the item that their certificate problem reporting channel might be broken. > In addition to this, the Mozilla Root Store policy requires all CAs > to monitor this mailing list. Mozilla's Root Store policy says: "CAs MUST follow and be aware of discussions in the mozilla.dev.security.policy forum, where Mozilla's root program is coordinated." There is no indication about how frequently a representative of the CA must check the m.d.s.policy discussions. And what about when a CA's representative is on vacation? (e.g. the month of August for many CAs) Do we really expect them to monitor m.d.s.policy while on vacation? (I don't even monitor it myself while I'm on vacation.) Also, for many of the subjects for the posts in m.d.s.policy I could see that whomever is monitoring the discussion forum might assume certain posts do not apply to their CA. Cheers, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Bugzilla Bugs re CA issuance of non-compliant certs
On Tuesday, August 15, 2017 at 3:53:06 PM UTC-7, Jonathan Rudenberg wrote: > It would be useful to know when and through what channel the CA learned about > each of the problems listed. (problem report via email at date/time; > known/unresolved issue since date; mailing list post at date/time; when I saw > this bug; etc.) I agree that will be useful, but my goal with this is to educate the CA about what we expect going forward. I want to foster open communication with CAs, so I will ask for this information, but I will not use this information against the CA. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Bugzilla Bugs re CA issuance of non-compliant certs
Updated draft for the Bugzilla Bugs that I will be filing for the problems listed below. Product: NSS Component: CA Certificate Mis-Issuance Whiteboard: [ca-compliance] Blocks: 1029147 Summary: : Non-BR-Compliant Certificate Issuance Description: The following problems have been found in certificates issued by your CA, and reported in the mozilla.dev.security.policy forum. Direct links to those discussions are provided for your convenience. To continue inclusion of your CA’s root certificates in Mozilla’s Root Store, you must respond in this bug to provide the following information: 1) How your CA first became aware of the problems listed below (e.g. via a Problem Report, via the discussion in mozilla.dev.security.policy, or via this Bugzilla Bug), and the date. 2) Prompt confirmation that your CA has stopped issuing TLS/SSL certificates with the problems listed below. 3) Complete list of certificates that your CA finds with each of the listed issues during the remediation process. The recommended way to handle this is to ensure each certificate is logged to CT and then attach a CSV file/spreadsheet of the fingerprints or crt.sh IDs, with one list per distinct problem. 4) Summary of the problematic certificates. For each problem listed below: number of certs, date first and last certs with that problem were issued. 5) Explanation about how and why the mistakes were made, and not caught and fixed earlier. 6) List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things. 7) Regular updates to confirm when those steps have been completed. Note Section 4.9.1.1 of the CA/Browser Forum’s Baseline Requirements, which states: “The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs: … 9. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement; 10. The CA determines that any of the information appearing in the Certificate is inaccurate or misleading; … 14. Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement; or 15. The technical content or format of the Certificate presents an unacceptable risk to Application Software Suppliers or Relying Parties (e.g. the CA/Browser Forum might determine that a deprecated cryptographic/signature algorithm or key size presents an unacceptable risk and that such Certificates should be revoked and replaced by CAs within a given period of time). However, it is not our intent to introduce additional problems by forcing the immediate revocation of certificates that are not BR compliant when they do not pose an urgent security concern. Therefore, we request that your CA perform careful analysis of the situation. If there is justification to not revoke the problematic certificates, then explain those reasons and provide a timeline for when the bulks of the certificates will expire or be revoked/replaced. We expect that your forthcoming audit statements will indicate the findings of these problems. If your CA will not be revoking the certificates within 24 hours in accordance with the BRs, then that will also need to be listed as a finding in your CA’s BR audit statement. We expect that your CA will work with your auditor (and supervisory body, as appropriate) and the Root Store(s) that your CA participates in to ensure your analysis of the risk and plan of remediation is acceptable. If your CA will not be revoking the problematic certificates as required by the BRs, then we recommend that you also contact the other root programs that your CA participates in to acknowledge this non-compliance and discuss what expectations their Root Programs have with respect to these certificates. The problems reported for your CA in the mozilla.dev.security.policy forum are as follows: ** Failure to respond within 24 hours after Problem Report submitted https://groups.google.com/d/msg/mozilla.dev.security.policy/PrsDfS8AMEk/w2AMK81jAQAJ The problems were reported via your CA’s Problem Reporting Mechanism as listed here: https://ccadb-public.secure.force.com/mozilla/CAInformationReport Therefore, if this is the first time you have received notice of the problem(s) listed below, please review and fix your CA’s Problem Reporting Mechanism to ensure that it will work the next time someone reports a problem like this. ** ~~ END DRAFT ~~ Updated list: == Actalis == Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position) https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ == Camerfirma == Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong
Re: Bugzilla Bugs re CA issuance of non-compliant certs
Bugs filed... == Actalis == https://bugzilla.mozilla.org/show_bug.cgi?id=1390974 == Camerfirma == https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 == Certinomis == https://bugzilla.mozilla.org/show_bug.cgi?id=1390978 == certSIGN == https://bugzilla.mozilla.org/show_bug.cgi?id=1390979 == Comodo == https://bugzilla.mozilla.org/show_bug.cgi?id=1390981 == Consorci AOC == https://bugzilla.mozilla.org/show_bug.cgi?id=1390988 == D-TRUST == https://bugzilla.mozilla.org/show_bug.cgi?id=1390990 == DigiCert == https://bugzilla.mozilla.org/show_bug.cgi?id=1389172 == Disig == https://bugzilla.mozilla.org/show_bug.cgi?id=1390991 == DocuSign/Keynectis == https://bugzilla.mozilla.org/show_bug.cgi?id=1390994 == Entrust == https://bugzilla.mozilla.org/show_bug.cgi?id=1390996 == FNMT == https://bugzilla.mozilla.org/show_bug.cgi?id=1391095 (This bug is to add the AC FNMT Usuarios certificate to OneCRL) == GlobalSign == https://bugzilla.mozilla.org/show_bug.cgi?id=1390997 == Kamu SM == https://bugzilla.mozilla.org/show_bug.cgi?id=1390998 == IdenTrust == https://bugzilla.mozilla.org/show_bug.cgi?id=1391000 == Izenpe == https://bugzilla.mozilla.org/show_bug.cgi?id=1391054 == Let’s Encrypt == RESOLVED (no bug needed) == Microsec e-Szigno == https://bugzilla.mozilla.org/show_bug.cgi?id=1391055 == NetLock == https://bugzilla.mozilla.org/show_bug.cgi?id=1391056 == PROCERT == https://bugzilla.mozilla.org/show_bug.cgi?id=1391058 == QuoVadis == https://bugzilla.mozilla.org/show_bug.cgi?id=1391063 == SECOM == https://bugzilla.mozilla.org/show_bug.cgi?id=1391064 == StartCom == https://bugzilla.mozilla.org/show_bug.cgi?id=1386894 == Staat der Nederlandend / PKIoverheid == RESOLVED (no bug needed) == SwissSign == https://bugzilla.mozilla.org/show_bug.cgi?id=1391066 == Symantec == https://bugzilla.mozilla.org/show_bug.cgi?id=1391067 == Taiwan-CA == https://bugzilla.mozilla.org/show_bug.cgi?id=1391068 == T-Systems == https://bugzilla.mozilla.org/show_bug.cgi?id=1391074 == Visa == https://bugzilla.mozilla.org/show_bug.cgi?id=1391087 == WISeKey == https://bugzilla.mozilla.org/show_bug.cgi?id=1391089 == ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Remove old WoSign root certs from NSS
I also think we should remove the old WoSign root certs from NSS. Reference: https://wiki.mozilla.org/CA/Additional_Trust_Changes#WoSign ~~ Mozilla currently recommends not trusting any certificates issued by this CA after October 21st, 2016. That recommendation covers the following roots: CN=CA 沃通根证书, OU=null, O=WoSign CA Limited, C=CN CN=Certification Authority of WoSign, OU=null, O=WoSign CA Limited, C=CN CN=Certification Authority of WoSign G2, OU=null, O=WoSign CA Limited, C=CN CN=CA WoSign ECC Root, OU=null, O=WoSign CA Limited, C=CN This restriction has been implemented in both in the Mozilla platform security code (PSM), which is shared by the Mozilla applications (Firefox, Thunderbird, etc.), and in addition, in the NSS library code, which is used by applications that use the NSS certificate verification APIs. ~~ Please let me know if you foresee any problems with removing these root certs from NSS. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Remove old StartCom root certs from NSS
And I think we should remove the old StartCom root certs from NSS. Reference: https://wiki.mozilla.org/CA/Additional_Trust_Changes#StartCom ~~ Mozilla currently recommends not trusting any certificates issued by this CA after October 21st, 2016. That recommendation covers the following roots: CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL CN=StartCom Certification Authority G2, OU=null, O=StartCom Ltd., C=IL This restriction has been implemented in both in the Mozilla platform security code (PSM), which is shared by the Mozilla applications (Firefox, Thunderbird, etc.), and in addition, in the NSS library code, which is used by applications that use the NSS certificate verification APIs. ~~ Please let me know if you foresee any problems with removing these root certs from NSS. 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
Forwarded Message Subject: Summary of July 2017 Audit Reminder Emails Date: Tue, 18 Jul 2017 19:00:05 + (GMT) Mozilla: Audit Reminder Root Certificates: LuxTrust Global Root 2 Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8777887 Audit Statement Date: 2016-07-26 BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8777887 BR Audit Statement Date: 2016-07-26 EV Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8777887 EV Audit Statement Date: 2016-07-26 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-27B09FD368FD11E6BE26005056BA67F7-_v2%5BdownloadKey%5D=615a9f0920a27ede37762410735c2deadd67547d%5Baction%5D=downloadDocument=9653a97e7fec91c2194d Audit Statement Date: 2016-07-11 BR Audit: https://www.mydqs.com/kunden/kundendatenbank.html?aoemydqs%5BrequestId%5D=europev2-DQS-27B09FD368FD11E6BE26005056BA67F7-_v2%5BdownloadKey%5D=615a9f0920a27ede37762410735c2deadd67547d%5Baction%5D=downloadDocument=9653a97e7fec91c2194d BR Audit Statement Date: 2016-07-11 CA Comments: null Mozilla: Audit Reminder Root Certificates: Autoridad de Certificacion Firmaprofesional CIF A62634068 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: BR and EV audits have happened, but there are action plans being presented to the auditors. Primary issues are use of UTF8 instead of PrintableString in jurisdictionOfIncorporation, and a recently repealed Spanish law that required privat Mozilla: Audit Reminder Root Certificates: Chambers of Commerce Root Chambers of Commerce Root - 2008 Global Chambersign Root Global Chambersign Root - 2008 Standard Audit: https://bug986854.bmoattachments.org/attachment.cgi?id=8775118 Audit Statement Date: 2016-06-17 BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8800807 BR Audit Statement Date: 2016-08-05 EV Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8800811 EV Audit Statement Date: 2016-08-05 CA Comments: null Mozilla: Audit Reminder Root Certificates: COMODO RSA Certification Authority** USERTrust ECC Certification Authority** AAA Certificate Services** AddTrust External CA Root** COMODO Certification Authority** COMODO ECC Certification Authority** UTN-USERFirst-Client Authentication and Email** USERTrust RSA Certification Authority** ** Audit Case in the Common CA Database is under review for this root certificate. Standard Audit: https://cert.webtrust.org/SealFile?seal=2058=pdf Audit Statement Date: 2016-06-03 BR Audit: https://cert.webtrust.org/SealFile?seal=2060=pdf BR Audit Statement Date: 2016-06-03 BR Audit: BR Audit Statement Date: EV Audit: https://cert.webtrust.org/SealFile?seal=2059=pdf EV Audit Statement Date: 2016-06-03 CA Comments: null Mozilla: Audit Reminder Root Certificates: EC-ACC Standard Audit: https://cert.webtrust.org/SealFile?seal=2043=pdf Audit Statement Date: 2016-05-30 BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8815404 BR Audit Statement Date: 2016-05-30 CA Comments: Per CA: ETSI-EIDAS audits to be released by the 1st of June 2017. Mozilla: Audit Reminder Root Certificates: AffirmTrust Commercial AffirmTrust Networking AffirmTrust Premium AffirmTrust Premium ECC Standard Audit: https://cert.webtrust.org/SealFile?seal=2115=pdf Audit Statement Date: 2016-06-30 BR Audit: https://cert.webtrust.org/SealFile?seal=2116=pdf BR Audit Statement Date: 2016-06-30 EV Audit: https://cert.webtrust.org/SealFile?seal=2093=pdf EV Audit Statement Date: 2016-06-30 CA Comments: null Mozilla: Audit Reminder Root Certificates: GlobalSign ECC Root CA - R5 GlobalSign Root CA - R3 GlobalSign Root CA GlobalSign Extended Validation CA - SHA256 - G2 - intermediate cert being treated as root during transition Standard Audit: https://cert.webtrust.org/SealFile?seal=2056=pdf Audit Statement Date: 2016-06-10 BR Audit: https://cert.webtrust.org/SealFile?seal=2054=pdf BR Audit Statement Date: 2016-06-10 EV Audit: https://cert.webtrust.org/SealFile?seal=2055=pdf EV Audit Statement Date: 2016-06-10 CA Comments: null Mozilla: Audit Reminder Root Certificates: Government Root Certification Authority - Taiwan Standard Audit: https://cert.webtrust.org/SealFile?seal=2050=pdf Audit Statement Date: 2016-06-29 BR Audit: https://cert.webtrust.org/SealFile?seal=2051=pdf BR Audit Statement Date: 2016-06-29 CA Comments: null Mozilla: Audit Reminder Root Certificates: Hellenic Academic and Research Institutions ECC RootCA 2015 Hellenic Academic and Research Institutions RootCA 2015
Re: Guang Dong Certificate Authority (GDCA) root inclusion request
The updated documents are also posted on the CA's website: https://www.gdca.com.cn/customer_service/knowledge_universe/cp_cps/ Current audit statements are here: WebTrust CA: https://cert.webtrust.org/ViewSeal?id=2231 WebTrust BR: https://cert.webtrust.org/ViewSeal?id=2232 WebTrust EV SSL: https://cert.webtrust.org/ViewSeal?id=2233 Unless anyone raises further questions or concerns, I plan to close this discussion and recommend approval of this request to include "GDCA TrustAUTH R5 ROOT" certificate, turn on the Websites trust bit, and enabled EV treatment. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Guang Dong Certificate Authority (GDCA) root inclusion request
Thanks to all of you who reviewed and commented on this request from Guangdong Certificate Authority (GDCA) to include the GDCA TrustAUTH R5 ROOT certificate, turn on the Websites trust bit, and enabled EV treatment. I believe that all of the concerns that were raised in this discussion have been properly addressed, and I will state my intent to approve this request in the bug. https://bugzilla.mozilla.org/show_bug.cgi?id=1128392 I am now closing this discussion. Any further follow-up should be added directly to the bug. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Responses to April 2017 CA Communication
All, The responses to Mozilla's April 2017 CA Communication are being published here: https://wiki.mozilla.org/CA:Communications#April_2017_Responses Reminder: I have postponed the response deadline to May 5, and I made a note of that here: https://wiki.mozilla.org/CA:Communications#April_2017 Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Bugzilla Product/Component groups for CA Program Bugs
The Bugzilla Product/Components for CA Program bugs have been changed. All of the CA Program bugs are now in the NSS Product group in Bugzilla. The NSS Product group in Bugzilla now has the following Components: Build CA Certificate Mis-Issuance CA Certificate Root Program CA Certificates Code Documentation Libraries Test Tools I am working on updating the CA Program wiki pages to match this change. Cheers, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Expanding Aaron Wu's role in CA Program
All, As many of you know, Aaron Wu has been doing the Information Verification[1] for root inclusion/update requests, has helped me organize the CA Program Bugzilla Bugs[2], and continues to expand in his role in helping with Mozilla's CA Certificates Module[3]. I have asked Aaron to begin opening the public discussions[4] for root inclusion/update requests, and to help me keep those discussions moving forward, so we can work through our queue[5]. For further information, please see the entry I added for Aaron in the CA:Policy_Participants wiki page[6]. I will continue to be very involved in the CA Program, but as you may have noticed I became overloaded this year. Therefore, I am extremely grateful for all the work that Gerv and Aaron have picked up. I will greatly appreciate your understanding and support to help Aaron as he takes on more of this work. Thanks, Kathleen [1] https://wiki.mozilla.org/CA:How_to_apply#Information_Verification [2] https://wiki.mozilla.org/CA_Bug_Triage [3] https://wiki.mozilla.org/Modules/All#CA_Certificates [4] https://wiki.mozilla.org/CA:How_to_apply#Public_discussion [5] https://wiki.mozilla.org/CA/Dashboard#Ready_for_Public_Discussion [6] https://wiki.mozilla.org/CA:Policy_Participants ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Extend deadline for April 2017 CA Communication?
> might be able to capture freeform text (perhaps unattributed) as to why Sure, below is a summary in my own words of why CAs are asking for an extension. Note that the April 2017 survey has many more action items than previous CA Communications, so I think it is reasonable that CAs might need more time to prepare all the answers. - people out-of-office who are needed to respond to the survey (vacations, business, health) - in the middle of an audit, so the people who are needed to respond to the survey are extremely busy - in the middle of data center upgrade/move, so the people who are needed to respond to the survey are extremely busy Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Extend deadline for April 2017 CA Communication?
I added a note about the extension to May 5 to https://wiki.mozilla.org/CA:Communications#April_2017 Cheers, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Bugzilla Bugs re CA issuance of non-compliant certs
Filed bug for GoDaddy: https://bugzilla.mozilla.org/show_bug.cgi?id=1391429 Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TrustCor root inclusion request
Thank you to everyone who has reviewed and commented on this request from TrustCor to include the “TrustCor RootCert CA-1”, “TrustCor RootCert CA-2”, and “TrustCor ECA-1” root certificates and enable the Websites and Email trust bits. I believe that all of the questions and concerns have been addressed and resolved. Therefore, if no further concerns are raised, I intend to close this discussion and recommend approval in the bug. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Bugzilla Bugs re CA issuance of non-compliant certs
I will proceed with filing these bugs now. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Bugzilla Bugs re CA issuance of non-compliant certs
On Friday, August 18, 2017 at 6:35:23 AM UTC-7, Gervase Markham wrote: > On 17/08/17 00:18, Kathleen Wilson wrote: > > == Let’s Encrypt == > > RESOLVED (no bug needed) > > > == Staat der Nederlandend / PKIoverheid == > > RESOLVED (no bug needed) > > While the timely responses and performance of these CAs is commendable, > it may be worth opening a bug and recording the events and the outcome, > so that our bug database remains the canonical source of information > regarding misissuances that Mozilla knows about. > > Kathleen: If your bug-filing fingers are not yet entirely worn out, > could they stretch to two more? :-) Let's Encrypt https://bugzilla.mozilla.org/show_bug.cgi?id=1391867 Staat der Nederlandend https://bugzilla.mozilla.org/show_bug.cgi?id=1391864 Cheers, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Remove old StartCom root certs from NSS
I have filed Bug #1392849 to remove the old StartCom root certificates. This will likely happen in the October batch of root changes. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Changing CCADB domains
All, I think it is time for us to change the domains that we are using for the CCADB as follows. Change the links for... 1) CAs to login to the CCADB from https://mozillacacommunity.force.com/ to https://ccadb.force.com/ 2) all published reports from https://mozillacaprogram.secure.force.com/ to https://ccadb.secure.force.com/ We asked Salesforce for a temporary redirect from the old to the new URLs, but that was declined because we're not paying for premium support for the CCADB. (Other than this change, I do not currently see the need for us to pay for premium support.) So, when we make this change, it will be a breaking change for everyone using the current links. To make this change happen, we will file a Salesforce bug and request that the change happen on a certain date, within a certain 24 hour window. So, we're planning to request that this change happen on a Friday. I would send an email via the CCADB to all included CAs before and after the change. I would also need to update all of Mozilla's wiki pages that have these links. i.e. all the wiki pages with instructions about CA login, public-facing reports, and the CA Communication responses. I suspect this change will also impact crt.sh. Is there anything that I have missed in regards to what will be impacted when we make this change? Does anyone have concerns or feedback on this? Cheers, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Update
On Tuesday, May 9, 2017 at 10:03:53 AM UTC-7, Kurt Roeckx wrote: > > Do we somewhere have the official templates being used to send > reminders of the audit requirements? Unofficial templates: https://wiki.mozilla.org/CA:Email_templates The official templates are in Salesforce, but currently match the wiki page. > Kathleen posts a summary of > the email that got send, but I'm not sure if they contain more > text or if the text changes as the period gets longer. For directly included certs, the email changes as the period gets longer. So far we only have one email template for intermediate certs: https://wiki.mozilla.org/CA:Email_templates#Disclosure_Incomplete_Email_Template I have not yet created automation around notifying CAs of overdue audit statements for intermediate certs. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Changing CCADB domains
Here are the changes we are requesting to be made on Friday, May 19, at 1pm PDT. 1) https://mozillacacommunity.force.com/ will be changed to https://ccadb.force.com/ (This is the CA login page, and the domain CAs see when they are logged into the CCADB) 2) https://mozillacaprogram.secure.force.com/ will be changed to https://mozilla-ccadb.secure.force.com/ (This is the domain for the Mozilla reports that are published directly from the CCADB) 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
Forwarded Message Subject: Summary of June 2017 Audit Reminder Emails Date: Tue, 20 Jun 2017 19:00:06 + (GMT) Mozilla: Audit Reminder Root Certificates: Atos TrustedRoot 2011 Standard Audit: https://www.mydqs.com/kunden/kundendatenbank.html?aoemydqs%5BrequestId%5D=europev2-DQS-27B09FD368FD11E6BE26005056BA67F7-_v2%5BdownloadKey%5D=615a9f0920a27ede37762410735c2deadd67547d%5Baction%5D=downloadDocument=9653a97e7fec91c2194d Audit Statement Date: 2016-07-11 BR Audit: https://www.mydqs.com/kunden/kundendatenbank.html?aoemydqs%5BrequestId%5D=europev2-DQS-27B09FD368FD11E6BE26005056BA67F7-_v2%5BdownloadKey%5D=615a9f0920a27ede37762410735c2deadd67547d%5Baction%5D=downloadDocument=9653a97e7fec91c2194d BR Audit Statement Date: 2016-07-11 CA Comments: null Mozilla: Audit Reminder Root Certificates: Autoridad de Certificacion Firmaprofesional CIF A62634068 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: BR and EV audits have happened, but there are action plans being presented to the auditors. Primary issues are use of UTF8 instead of PrintableString in jurisdictionOfIncorporation, and a recently repealed Spanish law that required privat Mozilla: Audit Reminder Root Certificates: Chambers of Commerce Root Chambers of Commerce Root - 2008 Global Chambersign Root Global Chambersign Root - 2008 Standard Audit: https://bug986854.bmoattachments.org/attachment.cgi?id=8775118 Audit Statement Date: 2016-06-17 BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8800807 BR Audit Statement Date: 2016-08-05 EV Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8800811 EV Audit Statement Date: 2016-08-05 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 AddTrust Public CA Root AddTrust Qualified CA Root COMODO Certification Authority COMODO ECC Certification Authority Secure Certificate Services Trusted Certificate Services UTN-USERFirst-Client Authentication and Email UTN-USERFirst-Hardware UTN-USERFirst-Object USERTrust RSA Certification Authority Standard Audit: https://cert.webtrust.org/SealFile?seal=2058=pdf Audit Statement Date: 2016-06-03 BR Audit: https://cert.webtrust.org/SealFile?seal=2060=pdf BR Audit Statement Date: 2016-06-03 BR Audit: BR Audit Statement Date: EV Audit: https://cert.webtrust.org/SealFile?seal=2059=pdf EV Audit Statement Date: 2016-06-03 CA Comments: null Mozilla: Audit Reminder Root Certificates: EC-ACC Standard Audit: https://cert.webtrust.org/SealFile?seal=2043=pdf Audit Statement Date: 2016-05-30 BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8815404 BR Audit Statement Date: 2016-05-30 CA Comments: Per CA: ETSI-EIDAS audits to be released by the 1st of June 2017. Mozilla: Audit Reminder Root Certificates: AffirmTrust Commercial AffirmTrust Networking AffirmTrust Premium AffirmTrust Premium ECC Standard Audit: https://cert.webtrust.org/SealFile?seal=2115=pdf Audit Statement Date: 2016-06-30 BR Audit: https://cert.webtrust.org/SealFile?seal=2116=pdf BR Audit Statement Date: 2016-06-30 EV Audit: https://cert.webtrust.org/SealFile?seal=2093=pdf EV Audit Statement Date: 2016-06-30 CA Comments: null Mozilla: Audit Reminder Root Certificates: GlobalSign ECC Root CA - R5 GlobalSign Root CA - R3 GlobalSign Root CA GlobalSign Extended Validation CA - SHA256 - G2 - intermediate cert being treated as root during transition Standard Audit: https://cert.webtrust.org/SealFile?seal=2056=pdf Audit Statement Date: 2016-06-10 BR Audit: https://cert.webtrust.org/SealFile?seal=2054=pdf BR Audit Statement Date: 2016-06-10 EV Audit: https://cert.webtrust.org/SealFile?seal=2055=pdf EV Audit Statement Date: 2016-06-10 CA Comments: null Mozilla: Audit Reminder Root Certificates: Government Root Certification Authority - Taiwan Standard Audit: https://cert.webtrust.org/SealFile?seal=2050=pdf Audit Statement Date: 2016-06-29 BR Audit: https://cert.webtrust.org/SealFile?seal=2051=pdf BR Audit Statement Date: 2016-06-29 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: http://www.harica.gr/documents/HARICA-ETSI_CERTIFICATE_AUTH_W_ANNEX_REV1.pdf Audit Statement Date: 2016-07-08 BR Audit: http://www.harica.gr/documents/HARICA-ETSI_CERTIFICATE_AUTH_W_ANNEX_REV1.pdf BR Audit Statement Date: 2016-07-08 CA
Auditor Qualifications
All, We've added new Auditor objects to the Common CA Database. Previously auditor information was just in text fields, and the same auditor could be represented different ways. Now we will have a master list of auditors that CAs can select from when entering their Audit Cases to provide their annual updates. The root store operator members of the CCADB will update this data as we encounter audit statements from new auditor/locations that we are able to verify. I have started the master list based on auditors encountered in the CCADB for root certificates. https://ccadb-public.secure.force.com/mozilla/AuditorQualificationsReport I will greatly appreciate it if you will review the list and let me know if I've made any mistakes in the data. Also, I will greatly appreciate good links to the qualifications to the ETSI auditors (I'm not sure if the links/qualifications I've used are the best). Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
ETSI auditors still not performing full annual audits?
I just filed https://bugzilla.mozilla.org/show_bug.cgi?id=1374381 about an audit statement that I received for SwissSign. I have copied the bug description below, because I am concerned that there still may be ETSI auditors (and CAs?) who do not understand the audit requirements, see below. ~~~ SwissSign provided their annual audit statement: https://bug1142323.bmoattachments.org/attachment.cgi?id=8853299 Problems noted in it: -- "Agreed-upon procedures engagement" - special words for audits - does not necessarily encompass the full scope -- "surveillance certification audits" - does not necessarily mean a full audit (which the BRs require annually) -- "point in time audit" -- this means that the auditor's evaluation only covered that point in time (note a period in time) -- "only intended for the client" -- Doesn't meet Mozilla's requirement for public-facing audit statement. -- "We were not engaged to and did not conduct an examination, the objective of which would be the expression of an opinion on the Application for Extended Validation (EV) Certificate. Accordingly, we do not express such an opinion. Had we performed additional procedures, other matters might have come to our attention that would have been reported to you." -- some of the included root certs are enabled for EV treatment, so need an EV audit as well. According to section 8.1 of the CA/Browser Forum's Baseline Requirements: "Certificates that are capable of being used to issue new certificates MUST ... be ... fully audited in line with all remaining requirements from this section. ... 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." So, a full period-in-time audit is required every year. After I voiced concern (https://bugzilla.mozilla.org/show_bug.cgi?id=1142323#c27) the CA provided an updated audit statement to address the concerns I had raised in the bug: https://bugzilla.mozilla.org/attachment.cgi?id=8867948 I do not understand how the audit statement can magically change from point-in-time to a period-in-time. ~~~ I will greatly appreciate thoughtful and constructive input into this discussion about what to do about this SwissSign audit situation, and if this is an indicator that ETSI auditors are still not performing full annual audits that satisfy the CA/Browser Forum's Baseline Requirements. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ETSI auditors still not performing full annual audits?
On Monday, June 19, 2017 at 12:21:46 PM UTC-7, Peter Bowen wrote: > It seems there is some confusion. The document presented would appear > to be a Verified Accountant Letter (as defined in the EV Guidelines) > and can used as part of the process to validate a request for an EV > certificate. It is not an audit report and is not something normally > submitted to browsers. Yet, it is the document that was provided to root store operators as the annual audit statement. And there has been plenty of time in Bug #1142323 for that to have been rectified. As reference, here is the audit statement that was provided in 2016: https://bug343756.bmoattachments.org/attachment.cgi?id=8781268 It says: "KPMG has executed a main certification audit in year 2013, and surveillance certification audits in 2014 and 2015..." "We were engaged to conduct the annual examinations, with the objective of which would be the expression of an opinion on the application for Extended Validation (EV) Certificates. Accordingly we do express our positive opinion and provide you confirmation that the requirements were fulfilled during the annual certification audits... " In the audit statement in question (https://bug1142323.bmoattachments.org/attachment.cgi?id=8853299) it says: "KPMG has executed a main certification audit in year 2017..." So I took that to mean that this was intended to be their annual audit statement, and the format is very similar to the audit statement from the previous year. But as I read through it I noticed phrases like "point in time audit". And then it said: "We were not engaged to and did not conduct an examination, the objective of which would be the expression of an opinion on the Application for Extended Validation (EV) Certificate. Accordingly, we do not express such an opinion. Had we performed additional procedures, other matters might have come to our attention that would have been reported to you." This is very different from the statement the previous year. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
DRAFT: Notice to CAs about CCADB changes May 19-21
All, Below is the draft email that I plan to send later today, after we have final confirmation from Salesforce regarding these proposed changes. I will appreciate your feedback on this. Thanks, Kathleen Subject: Common CA Database (CCADB) changes May 19-21, 2017 Dear Certification Authority, The Common CA Database (CCADB) will undergo the following changes this weekend, May 19 to May 21. During this time, the old URLs listed below will stop working, and there will be some time when the CCADB is in read-only mode. On May 19 the following three breaking changes are planned, meaning that the old URLs will no longer work. Any links or bookmarks to these URLs will need to be updated. After these changes are made, I will also update Mozilla's wiki pages to point to the new URLs. 1) The CA login page and the domain CAs see when they are logged into the CCADB will change. https://mozillacacommunity.force.com/ will be changed to https://ccadb.force.com/ 2) The links to reports that are published directly from the CCADB will change. https://mozillacaprogram.secure.force.com/CA/ will be changed to https://ccadb-public.secure.force.com/mozilla/ 3) The links to CA communication responses that are published directly from the CCADB will change. https://mozillacaprogram.secure.force.com/Communications will be changed to https://ccadb-public.secure.force.com/mozillacommunications Then on May 21 between 12am and 4am PDT, the CCADB will be in read-only mode while Salesforce performs an instance refresh to upgrade the infrastructure supporting the CCADB instance in their data centers. Regards, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Sandbox: Mozilla: Audit Reminder
CAs, I was testing some changes in my CCADB Sandbox, and accidentally sent out audit reminder email from it. So, if you get an email with the subject "Sandbox: Mozilla: Audit Reminder" you can ignore it. It's likely a duplicate of the email you received last Tuesday. I apologize for the spam. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT: Notice to CAs about CCADB changes May 19-21
I've been receiving questions about this update, so hopefully the following will clarify... CAs now login to the CCADB at this URL: https://ccadb.force.com There is no login required to view the public-facing reports and the responses to the CA Communications. The links to those have been updated in the following wiki pages: https://wiki.mozilla.org/CA/Included_Certificates https://wiki.mozilla.org/CA/Intermediate_Certificates https://wiki.mozilla.org/CA/Removed_Certificates https://wiki.mozilla.org/CA/Communications Cheers, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Taiwan GRCA Root Renewal Request
On Wednesday, March 15, 2017 at 5:01:13 PM UTC-7, Kathleen Wilson wrote: > > So, if there are no further questions or comments about this CA's request, > then I will close this discussion and recommend approval in the bug. > All, I requested that this CA perform a BR Self Assessment, and they have attached their completed BR Self Assessment to the bug here: https://bugzilla.mozilla.org/show_bug.cgi?id=1065896#c30 Aaron has reviewed and verified the BR Self Assessment. Therefore, I plan to approve this request from the Government of Taiwan (GRCA) to include their "Government Root Certification Authority" root certificate, and turn on the Websites and Email trust bits, and constrain this root to *.tw. If there are no further concerns, then I will close this discussion and recommend approval in the bug. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CA report with CAA and Problem Reporting info
On Friday, May 26, 2017 at 2:50:16 AM UTC-7, Gervase Markham wrote: > On 26/05/17 01:01, Kathleen Wilson wrote: > > Known problems: - Some CAs did not provide their CAA (Certification > > Authority Authorization) information correctly, so that column is > > empty for them. Note that some CAs do not have the Websites trust bit > > set for any of their root certs, so that column may remain empty for > > them. > > That makes me think: could we detect that situation and put a marker in > the report to say "N/A", or would that be difficult? > I put "N/A" directly into the field for those CAs who do not have roots included with the Websites trust bit set. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
CA report with CAA and Problem Reporting info
All, We have added the following two reports to https://wiki.mozilla.org/CA/Included_Certificates 1) CAs with Included Certificates https://ccadb-public.secure.force.com/mozilla/CAInformationReport 2) CAs with Included Certificates (CSV) https://ccadb-public.secure.force.com/mozilla/CAInformationReportCSVFormat The columns in these reports are: CA Owner Name Organizational Type Geographic Focus Primary Market/Customer Base Company Website Recognized CAA Domains Problem Reporting Mechanism Known problems: - Some CAs did not provide their CAA (Certification Authority Authorization) information correctly, so that column is empty for them. Note that some CAs do not have the Websites trust bit set for any of their root certs, so that column may remain empty for them. - Problem Reporting Mechanism data needs to be cleaned up to be made consistent. If you would like me to update any of the information in this report for your CA, please send me email, and I will update it in the CCADB for you. CAs are not able to directly modify the CA Owner data in the CCADB. Cheers, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT: Notice to CAs about CCADB changes May 19-21
On Thursday, May 18, 2017 at 10:08:32 AM UTC-7, Kathleen Wilson wrote: > All, > > Below is the draft email that I plan to send later today, after we have final > confirmation from Salesforce regarding these proposed changes. > We received confirmation from Salesforce that these changes to the URLs will happen at about 1:00pm PDT on May 19. I have sent email to the CA Contacts who have active CCADB CA Community Licenses. I also added this email to https://wiki.mozilla.org/CA/Communications Cheers, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DRAFT: Notice to CAs about CCADB changes May 19-21
On Thursday, May 18, 2017 at 10:08:32 AM UTC-7, Kathleen Wilson wrote: > > On May 19 the following three breaking changes are planned, meaning that the > old URLs will no longer work. Any links or bookmarks to these URLs will need > to be updated. ... > > 1) The CA login page and the domain CAs see when they are logged into the > CCADB will change. > https://mozillacacommunity.force.com/ > will be changed to > https://ccadb.force.com/ > > 2) The links to reports that are published directly from the CCADB will > change. > https://mozillacaprogram.secure.force.com/CA/ > will be changed to > https://ccadb-public.secure.force.com/mozilla/ > > 3) The links to CA communication responses that are published directly from > the CCADB will change. > https://mozillacaprogram.secure.force.com/Communications > will be changed to > https://ccadb-public.secure.force.com/mozillacommunications > These changes have happened, and I have updated the wiki pages with the correct links: https://wiki.mozilla.org/CA:CommonCADatabase https://wiki.mozilla.org/CA/Intermediate_Certificates https://wiki.mozilla.org/CA/Communications Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Plan for Symantec posted
On Friday, May 19, 2017 at 8:42:40 AM UTC-7, Gervase Markham wrote: > > I have passed that document to Kathleen, and I hope she will be > endorsing this general direction soon, at which point it will no longer > be a draft. > > Assuming she does, this will effectively turn into a 3-way conversation > between Symantec, Google and Mozilla, to iron out the details of what's > required, with the Google proposal as a base. (Which I'm fine with as a > starting point.) > > Comments are therefore invited on what modifications to the plan or > additional requirements Mozilla might want to suggest/impose, and > (importantly) why those suggestions/impositions are necessary and > proportionate. > Gerv, thank you for all the effort you have been putting into this investigation into Symantec's mis-issuances, and in identifying the best way to move forward with the primary goal being to help keep end-users safe. I fully support requiring Symantec to set up a new PKI on new infrastructure, and to transition to it in phases, in order to minimize the impact and reduce the risk for end-users. I think the general direction is correct, but I think there are a few details to be ironed out, such as: - What validity periods should be allowed for SSL certs being issued in the old PKI (until the new PKI is ready)? I prefer that this be on the order of 13 months, and not on the order of 3 years, so that we can hope to distrust the old PKI as soon as possible. I prefer to not have to wait 3 years to stop trusting the old PKI for SSL, because a bunch of 3-year SSL certs get issued this year. - Perhaps the new PKI should only be cross-signed by a particular intermediate cert of a particular root cert, so that we can begin to distrust the rest of the old PKI as soon as possible. - I'm not sold on the idea of requiring Symantec to use third-party CAs to perform validation/issuance on Symantec's behalf. The most serious concerns that I have with Symantec's old PKI is with their third-party subCAs and third-party RAs. I don't have particular concern about Symantec doing the validation/issuance in-house. So, I think it would be better/safer for Symantec to staff up to do the validation/re-validation in-house rather than using third parties. If the concern is about regaining trust, then add auditing to this. 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
Forwarded Message Subject: Summary of May 2017 Audit Reminder Emails Date: Tue, 16 May 2017 19:00:29 + (GMT) Mozilla: Audit Reminder Root Certificates: Autoridad de Certificacion Firmaprofesional CIF A62634068 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: 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 AddTrust Public CA Root AddTrust Qualified CA Root COMODO Certification Authority COMODO ECC Certification Authority Secure Certificate Services Trusted Certificate Services UTN-USERFirst-Client Authentication and Email UTN-USERFirst-Hardware UTN-USERFirst-Object USERTrust RSA Certification Authority Standard Audit: https://cert.webtrust.org/SealFile?seal=2058=pdf Audit Statement Date: 2016-06-03 BR Audit: https://cert.webtrust.org/SealFile?seal=2060=pdf BR Audit Statement Date: 2016-06-03 BR Audit: BR Audit Statement Date: EV Audit: https://cert.webtrust.org/SealFile?seal=2059=pdf EV Audit Statement Date: 2016-06-03 CA Comments: null Mozilla: Audit Reminder Root Certificates: ComSign CA ComSign Secured CA Standard Audit: https://bug1269275.bmoattachments.org/attachment.cgi?id=8778667 Audit Statement Date: 2016-04-26 CA Comments: null Mozilla: Audit Reminder Root Certificates: EC-ACC Standard Audit: https://cert.webtrust.org/SealFile?seal=2043=pdf Audit Statement Date: 2016-05-30 BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8815404 BR Audit Statement Date: 2016-05-30 CA Comments: Per CA: ETSI-EIDAS audits to be released by the 1st of June 2017. Mozilla: Audit Reminder Root Certificates: S-TRUST Universal Root CA TC TrustCenter Class 3 CA II Standard Audit: https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/6778UE_s.pdf Audit Statement Date: 2016-05-31 CA Comments: null Mozilla: Audit Reminder Root Certificates: Entrust Root Certification Authority - EC1 Entrust Root Certification Authority - G2 Entrust Root Certification Authority Entrust.net Certification Authority (2048) Standard Audit: https://cert.webtrust.org/SealFile?seal=328=pdf Audit Statement Date: 2016-05-18 BR Audit: https://www.entrust.com/wp-content/uploads/2016/06/2104-01-WebTrust-for-CA-SSL-Baseline-with-Network-Security-Report-002.pdf BR Audit Statement Date: 2016-05-18 EV Audit: https://cert.webtrust.org/SealFile?seal=328=pdf EV Audit Statement Date: 2016-05-18 CA Comments: null Mozilla: Audit Reminder Root Certificates: GlobalSign ECC Root CA - R5 GlobalSign Root CA - R3 GlobalSign Root CA GlobalSign Extended Validation CA - SHA256 - G2 - intermediate cert being treated as root during transition Standard Audit: https://cert.webtrust.org/SealFile?seal=2056=pdf Audit Statement Date: 2016-06-10 BR Audit: https://cert.webtrust.org/SealFile?seal=2054=pdf BR Audit Statement Date: 2016-06-10 EV Audit: https://cert.webtrust.org/SealFile?seal=2055=pdf EV Audit Statement Date: 2016-06-10 CA Comments: null Mozilla: Audit Reminder Root Certificates: GeoTrust Global CA 2 Standard Audit: https://www.symantec.com/content/en/us/about/media/repository/3_symantec_geotrust_wtca_6-15-2016.pdf Audit Statement Date: 2016-05-13 BR Audit: https://www.symantec.com/content/en/us/about/media/repository/6_symantec_geotrust_wtbr_6-15-2016.pdf BR Audit Statement Date: 2016-05-13 CA Comments: null Mozilla: Audit Reminder Root Certificates: Trustis Limited - Trustis FPS Root CA Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8745582 Audit Statement Date: 2016-02-03 BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8745582 BR Audit Statement Date: 2016-02-03 CA Comments: 2017 audit submitted via CCADB Audit Case is under review Mozilla: Audit Reminder Root Certificates: Certum Trusted Network CA 2 Certum CA Certum Trusted Network CA Standard Audit: https://cert.webtrust.org/SealFile?seal=2064=pdf Audit Statement Date: 2016-06-10 BR Audit: https://cert.webtrust.org/SealFile?seal=2066=pdf BR Audit Statement Date: 2016-06-10 EV Audit: https://cert.webtrust.org/SealFile?seal=2065=pdf EV Audit Statement Date: 2016-06-10 CA Comments: null Mozilla: Audit Reminder Root Certificates: FNMT-RCM - SHA256 Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8766584 Audit Statement Date: 2016-05-18 BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8766583 BR Audit Statement Date: 2016-05-18 CA Comments: null Mozilla: Audit Reminder Root Certificates: GlobalSign ECC Root CA - R4 GlobalSign
Re: Taiwan GRCA Root Renewal Request
On Friday, May 26, 2017 at 9:32:57 AM UTC-7, Kathleen Wilson wrote: > On Wednesday, March 15, 2017 at 5:01:13 PM UTC-7, Kathleen Wilson wrote: > All, > > I requested that this CA perform a BR Self Assessment, and they have attached > their completed BR Self Assessment to the bug here: > https://bugzilla.mozilla.org/show_bug.cgi?id=1065896#c30 > > Aaron has reviewed and verified the BR Self Assessment. > > Therefore, I plan to approve this request from the Government of Taiwan > (GRCA) to include their "Government Root Certification Authority" root > certificate, and turn on the Websites and Email trust bits, and constrain > this root to *.tw. > > If there are no further concerns, then I will close this discussion and > recommend approval in the bug. > After further consideration, I have decided to wait for the CA to provide their updated CP/CPS that will address all of the shortcomings that they noted in their BR Self Assessment that they plan to fix in the next version of their CP/CPS. So, this discussion will be on hold again until I have received and reviewed their updated CP/CPS documents. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Updating Root Program wiki pages
All, Gerv is leading the effort to clean up Mozilla's Root Store related wiki pages. The contents of https://wiki.mozilla.org/CA:Overview have been moved to https://wiki.mozilla.org/CA and cleaned up. The previous contents of https://wiki.mozilla.org/CA have been moved to https://wiki.mozilla.org/CA/Application_Process Please let me know if information that you need disappears, and you are not able to find it by starting with https://wiki.mozilla.org/CA Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Changing CCADB domains
On Wednesday, May 3, 2017 at 1:21:29 PM UTC-7, Nick Lamb wrote: > If you believe there are, or are likely to be, CAs trying to fill out the > survey a bit late, it may make sense to wait for that before triggering this > change, so as to avoid the (it seems almost inevitable) response that they > tried to do the survey but they were using the old link and it didn't work... Good point. We will ask Salesforce to make this change on May 19. 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
Forwarded Message Subject: Summary of September 2017 Audit Reminder Emails Date: Tue, 19 Sep 2017 19:00:08 + (GMT) Mozilla: Overdue Audit Statements Root Certificates: Autoridad de Certificacion Firmaprofesional CIF A62634068 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: BR and EV audits have happened, but there are action plans being presented to the auditors. Primary issues are use of UTF8 instead of PrintableString in jurisdictionOfIncorporation, and a recently repealed Spanish law that required privat Mozilla: Audit Reminder Root Certificates: Chambers of Commerce Root Chambers of Commerce Root - 2008 Global Chambersign Root Global Chambersign Root - 2008 Standard Audit: https://bug986854.bmoattachments.org/attachment.cgi?id=8775118 Audit Statement Date: 2016-06-17 BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8800807 BR Audit Statement Date: 2016-08-05 EV Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8800811 EV Audit Statement Date: 2016-08-05 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: 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=8784555 Audit Statement Date: 2016-08-23 BR Audit: https://bug937589.bmoattachments.org/attachment.cgi?id=8784555 BR Audit Statement Date: 2016-08-23 CA Comments: null Mozilla: Audit Reminder Root Certificates: E-Tugra Certification Authority Standard Audit: https://bug877744.bmoattachments.org/attachment.cgi?id=8792625 Audit Statement Date: 2016-09-09 BR Audit: https://bug877744.bmoattachments.org/attachment.cgi?id=8792625 BR Audit Statement Date: 2016-09-09 EV Audit: https://bug877744.bmoattachments.org/attachment.cgi?id=8792625 EV Audit Statement Date: 2016-09-09 CA Comments: null Mozilla: Audit Reminder Root Certificates: GlobalSign ECC Root CA - R5 Standard Audit: https://cert.webtrust.org/SealFile?seal=2287=pdf Audit Statement Date: 2017-07-26 BR Audit: https://bug1388488.bmoattachments.org/attachment.cgi?id=8895040 BR Audit Statement Date: 2017-07-26 EV Audit: https://cert.webtrust.org/SealFile?seal=2055=pdf EV Audit Statement Date: 2016-06-10 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: https://bugzilla.mozilla.org/attachment.cgi?id=8815072 Audit Statement Date: 2016-08-31 BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8815073 BR Audit Statement Date: 2016-08-31 EV Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8815074 EV Audit Statement Date: 2016-08-31 CA Comments: null Mozilla: Audit Reminder Root Certificates: IdenTrust Commercial Root CA 1 IdenTrust Public Sector Root CA 1 DST ACES CA X6 DST Root CA X3 Standard Audit: https://cert.webtrust.org/SealFile?seal=2107=pdf Audit Statement Date: 2016-08-19 BR Audit: https://cert.webtrust.org/SealFile?seal=2106=pdf BR Audit Statement Date: 2016-08-19 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 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: null Mozilla: Audit Reminder Root Certificates: PSCProcert Standard Audit: https://bug593805.bmoattachments.org/attachment.cgi?id=8795484 Audit Statement Date: 2016-08-02 BR Audit: https://bug593805.bmoattachments.org/attachment.cgi?id=8795484 BR Audit Statement Date: 2016-08-02 CA Comments: null Mozilla: Audit Reminder Root Certificates: Security Communication EV RootCA1 SECOM Trust.net - Security Communication RootCA1 Security Communication RootCA2 Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8805235 Audit Statement Date: 2016-08-22 BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8805235 BR Audit Statement Date: 2016-08-22 EV Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8805235
Re: Audit Reminder Email Summary
On Wednesday, September 20, 2017 at 6:34:04 AM UTC-7, Kurt Roeckx wrote: > On 2017-09-20 01:09, Kathleen Wilson wrote: > > Forwarded Message > > Subject: Summary of September 2017 Audit Reminder Emails > > Date: Tue, 19 Sep 2017 19:00:08 + (GMT) > > > > Mozilla: Overdue Audit Statements > > Root Certificates: > > Autoridad de Certificacion Firmaprofesional CIF A62634068 > > 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: BR and EV audits have happened, but there are action plans > > being presented to the auditors. Primary issues are use of UTF8 instead of > > PrintableString in jurisdictionOfIncorporation, and a recently repealed > > Spanish law that required privat > > Does that mean the standard audit did not happen? The currently linked > one covered the period 2015-03-10 to 2016-03-09. The next period of 1 > year is now over for more than 6 months. > > If the audits happened, why don't we have the audit statement yet? > I'll contact the CA, and ask them to respond. I noticed that for the audit reminders the program was sending to the email alias only, so I've asked my Salesforce consultant to make sure the Primary POC(s) are always in the 'To' list for the emails. However, it is the CA's responsibility to provide their updated audit statements, so not receiving the audit reminder email does not excuse them. > > Mozilla: Audit Reminder > > Root Certificates: > > Chambers of Commerce Root > > Chambers of Commerce Root - 2008 > > Global Chambersign Root > > Global Chambersign Root - 2008 > > Standard Audit: > > https://bug986854.bmoattachments.org/attachment.cgi?id=8775118 > > Audit Statement Date: 2016-06-17 > > BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8800807 > > BR Audit Statement Date: 2016-08-05 > > EV Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8800811 > > EV Audit Statement Date: 2016-08-05 > > CA Comments: null > > The standard audit was for the period of 2015-04-14 to 2016-04-13, and > so are also late with their audit. I'll contact the CA... > > > Mozilla: Audit Reminder > > Root Certificates: > > GlobalSign ECC Root CA - R5 > > Standard Audit: https://cert.webtrust.org/SealFile?seal=2287=pdf > > Audit Statement Date: 2017-07-26 > > BR Audit: https://bug1388488.bmoattachments.org/attachment.cgi?id=8895040 > > BR Audit Statement Date: 2017-07-26 > > EV Audit: https://cert.webtrust.org/SealFile?seal=2055=pdf > > EV Audit Statement Date: 2016-06-10 > > CA Comments: null > > The EV period was from 2015-04-01 to 2013-03-31. The others are new, > maybe forgot to update something? Bug in CCADB. I am waiting for my Salesforce consultant to confirm that she has replicated the bug in Sandbox, and then I will fix the data in Production. > > > Mozilla: Audit Reminder > > Root Certificates: > > Certum Trusted Network CA 2** > > Certum Trusted Network CA** > > > > ** Audit Case in the Common CA Database is under review for this root > > certificate. > > > > Standard Audit: https://cert.webtrust.org/SealFile?seal=2064=pdf > > Audit Statement Date: 2016-06-10 > > BR Audit: https://cert.webtrust.org/SealFile?seal=2066=pdf > > BR Audit Statement Date: 2016-06-10 > > EV Audit: https://cert.webtrust.org/SealFile?seal=2065=pdf > > EV Audit Statement Date: 2016-06-10 > > CA Comments: null > As noted by the '**' we have received the updated audit statements, and are working with the CA on their Audit Case. Since the Audit Case is a new process, there is a learning curve for most CAs. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SSL.com root inclusion request
Thank you to those of you who reviewed and commented on this request from SSL.com to include the “SSL.com Root Certification Authority RSA”, “SSL.com Root Certification Authority ECC”, “SSL.com EV Root Certification Authority RSA R2”, and “SSL.com EV Root Certification Authority ECC” root certificates, turn on the Email and Websites trust bits for the two non-EV roots, turn on the Websites trust bit for the two EV roots, and enable EV treatment for the two EV roots. I believe that all of the questions and concerns that were raised in this discussion have been properly addressed. As a result of this discussion, there are a couple of minor changes that the CA plans to make in their CP/CPS, but those are not show-stoppers. Therefore, I am closing this discussion and I will state my intent to approve this request in the bug. https://bugzilla.mozilla.org/show_bug.cgi?id=1277336 Any further follow-up should be added directly to the bug. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Violations of Baseline Requirements 4.9.10
I'm going to file the Bugzilla Bugs for each of these CAs, as follows. == Bug Summary: : Non-BR-Compliant OCSP Responders Bug Description: Problems have been found with OCSP responders for this CA, and reported in the mozilla.dev.security.policy forum here: https://groups.google.com/d/msg/mozilla.dev.security.policy/o1MX07iWDco/RuM1NK_0AQAJ As per section 4.9.10 of the BRs, OCSP responders MUST NOT respond with a “good” status for unissued certificates. The effective date for this requirement was 2013-08-01. Please provide an incident report in this bug, as described here: https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report == > I have updated the list again to note the additional responders fixed (in > this update: CA Disig, PKIoverheid, Izenpe). To make this email slightly > less enormous I've also started removing everything but the CA's name when > I have confirmed that all the reported responders are now properly > responding to my queries. Should I still file a bug for those, so that the incident report is recorded in Bugzilla? Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certigna Root Renewal Request
> This request from the Dhimyotis/Certigna is to include the > SHA-256 ‘Certigna Root CA’ certificate and turn on the > Websites and Email trust bits. This root certificate will > eventually replace the SHA-1 ‘Certigna’ root certificate > that was included via Bugzilla #393166. > ... > The request is documented in the following bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=1265683 This CA has provided an updated BR Self Assessment: https://bugzilla.mozilla.org/show_bug.cgi?id=1265683#c25 I will greatly appreciate constructive feedback on this CA's root renewal request. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Violations of Baseline Requirements 4.9.10
Bugs filed… > > AS Sertifitseerimiskeskuse (SK) > Bug #1398233 > > Autoridad de Certificacion Firmaprofesional > Bug #1398240 > > CA Disig a.s. (Fixed as of 2017-08-31) > Bug #1398242 > > certSIGN (partially resolved) > Bug #1398243 > > Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert) > Bug #1398246 > > DigiCert: > Bug #1398269 > > DocuSign (OpenTrust/Keynectis) > Bug #1398247 > > Government of The Netherlands, PKIoverheid (Logius) (Fixed as of 2017-08-31) > Bug #1398251 > > IdenTrust (fixed as of 2017-08-31) > Bug #1398255 > > Izenpe S.A. (fixed as of 2017-09-05) > Bug #1398258 > > PROCERT > Existing Bug: 1391058 > > SECOM Trust Systems Co. Ltd. > Bug #1398259 > > Visa > Bug #1398261 ~ Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Remove old WoSign root certs from NSS
Posted: https://blog.mozilla.org/security/2017/08/30/removing-disabled-wosign-startcom-certificates-firefox-58/ I will look into getting this translated and published in China. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Draft Security Blog about v2.5 of Root Store Policy
On Thursday, September 7, 2017 at 1:23:17 AM UTC-7, Buschart, Rufus wrote: > I have a question regarding the meaning of: > > > * The latest versions of the WebTrust and ETSI audit criteria are now > > required, and auditors are required to be appropriately qualified. I will delete that sentence in the blog post, because I don't think it's really necessary. > > Will you still accept ETSI TS 102 042 audits or does it mean, you will only > accept ETSI EN 319 411-1 audits? Both are acceptable according to BRG 8.4. mozilla.org/listinfo/dev-security-policy ETSI TS 102 042 audits are still allowed as per https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#audit-criteria Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Draft Security Blog about v2.5 of Root Store Policy
All, Here is a draft of a security blog about version 2.5 of Mozilla's Root Store Policy. I will greatly appreciate constructive feedback about it. Thanks, Kathleen == Mozilla Releases Version 2.5 of Root Store Policy == Recently, Mozilla released version 2.5 of our Root Store Policy, which continues our efforts to improve standards and reinforce public trust in the security of the Web. We are grateful to all those in the security and Certificate Authority (CA) communities who contributed constructively to the discussions surrounding the new provisions. The changes of greatest note in version 2.5 of our Root Store Policy are as follows: * CAs are required to follow industry best practice for securing their networks, for example by conforming to the CA/Browser Forum’s Network Security Guidelines or a successor document. * CAs are required to use only those methods of domain ownership validation which are specifically documented in the CA/Browser Forum’s Baseline Requirements 1.4.1. * Additional requirements were added for intermediate certificates that are used to sign certificates for S/MIME. In particular, such intermediate certificates must be name constrained in order to be considered technically-constrained and exempt from being audited and disclosed on the Common CA Database. * Clarified that point-in-time audit statements do not replace the required period-of-time assessments. Mozilla continues to require full-surveillance period-of-time audits that must be conducted annually, and successive audit periods must be contiguous. * Clarified the information that must be provided in each audit statement, including the distinguished name and SHA-256 fingerprint for each root and intermediate certificate in scope of the audit. * CAs are required to follow and be aware of discussions in the mozilla.dev.security.policy forum, where Mozilla's root program is coordinated, although they are not required to participate. * The latest versions of the WebTrust and ETSI audit criteria are now required, and auditors are required to be appropriately qualified. * CAs are required at all times to operate in accordance with the applicable Certificate Policy (CP) and Certificate Practice Statement (CPS) documents, which must be reviewed and updated at least once every year. * Our policy on root certificates being transferred from one organization or location to another has been updated and included in the main policy. Trust is not transferable; Mozilla will not automatically trust the purchaser of a root certificate to the level it trusted the previous owner. The differences between versions 2.5 and 2.4.1 may be viewed on Github. (Version 2.4.1 contained exactly the same normative requirements as version 2.4 but was completely reorganized.) As always, we re-iterate that participation in Mozilla’s CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Mozilla Security Team == ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: PROCERT issues
In past incidents, we have provided a list of action items that the CA must complete before they can be re-included in Mozilla's root store. What action items do you all think PROCERT should complete before they can be re-included in Mozilla's root store? What do you think should happen if PROCERT completes those action items before their PSCProcert root is actually removed? Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: PROCERT issues
On Friday, September 29, 2017 at 2:52:49 PM UTC-7, Eric Mill wrote: > That dynamic is natural, but accepting that this dynamic exists is > different than giving into it in some absolute way. When offering second > chances, requiring that the person/org fulfill certain conditions that > speak directly to their ability to have learned and adapted from the thing > they failed at the first time is an approach that accepts this dynamic, > without shutting the door on people or organizations that have grown as a > result of the experience. > > I think it would arguably lead to worse behavior, and less disclosure of > incidents and mistakes, if Mozilla adopted a posture where second chances > are rarely given. Not saying that's what's being said here, but I think > it's worth emphasizing that the first principle here should be to optimize > for incentivizing the behavior you want out of the CA community that > protects users and increases information sharing. > > -- Eric I agree with Eric on this. The last sentence in our CA Communications and Mozilla Security Blog Posts regarding our CA Program is frequently: "... we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve." Below are my personal feelings... In the case of WoSign and StartCom, I felt such a level of deception that it will be extremely difficult for either CA to ever gain my trust again. Rightly or wrongly so, I have not recognized that level of deception from other CAs in Mozilla's program. The deception happened before Inigo went to StartCom, and I appreciate all of Inigo's efforts, but due to the position he is now in, he will have to do an outstanding job, be test-driven, and demonstrate a truly clean CA hierarchy in order to regain my trust in StartCom. Unfortunately, I just don't feel that I've seen that so far. In regards to PROCERT, I do not believe that they have intentionally deceived me, but that their representatives responded to previous CA Communications and the Bugzilla Bug without getting their technical people involved. That is very bad! and I am very disappointed! But perhaps there are actions that they can take to demonstrate their commitment to not repeating those mistakes, to putting code into place to prevent non-BR-compliant cert issuance, and to show that they do have the level of technical knowledge in their organization that is needed to operate a good CA. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TrustCor root inclusion request
Thanks again to everyone reviewed and commented on this request from TrustCor. I am now closing this discussion, and will recommend approval in the bug to include the “TrustCor RootCert CA-1”, “TrustCor RootCert CA-2”, and “TrustCor ECA-1” root certificates and enable the Websites and Email trust bits. https://bugzilla.mozilla.org/show_bug.cgi?id=1231853 Any further follow-up on this request should be added directly to the bug. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Remove old WoSign root certs from NSS
On Friday, August 4, 2017 at 12:01:15 AM UTC-7, Percy wrote: > I suggest that Mozilla can post an announcement now about the complete > removal of WoSign/StartCom to alert website developers. I suspect that a > moderate amount of Chinese websites are still using WoSign certs chained to > the old roots. Google posted about this complete removal here > https://security.googleblog.com/2017/07/final-removal-of-trust-in-wosign-and.html > > > And since WoSign has the most presence in China, I suggest Mozilla can > instruct Mozilla China to post such announcement in Chinese as well. Here's a DRAFT for such an announcement, that I could post to Mozilla's Security Blog [1]. ~~ DRAFT ~~ Title: Removing Disabled WoSign and StartCom Certificates from Firefox 58 In October 2016, Mozilla announced[2] that, as of Firefox 51, we would stop validating new certificates chaining to the below list of root certificates owned by the companies WoSign and StartCom. The announcement also indicated our intent to eventually completely remove these root certificates from Mozilla’s Root Store[3], so that we would no longer validate certificates issued even before that date by those roots. That time has now arrived. We plan to release the relevant changes[4] to Network Security Services (NSS)[5] in November, and then the changes will be picked up in Firefox 58[6], due for release in January 2018. Sites using certificates chaining up to any of the following root certificates need to migrate to another root certificate. This announcement applies to the root certificates with the following names: CN=CA 沃通根证书, OU=null, O=WoSign CA Limited, C=CN CN=Certification Authority of WoSign, OU=null, O=WoSign CA Limited, C=CN CN=Certification Authority of WoSign G2, OU=null, O=WoSign CA Limited, C=CN CN=CA WoSign ECC Root, OU=null, O=WoSign CA Limited, C=CN CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL CN=StartCom Certification Authority G2, OU=null, O=StartCom Ltd., C=IL Mozilla Security Team ~~ As always, I will appreciate your constructive feedback. Thanks, Kathleen [1] https://blog.mozilla.org/security/ [2] https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates/ [3] https://wiki.mozilla.org/CA [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1387260 https://bugzilla.mozilla.org/show_bug.cgi?id=1392849 [5] https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS [6] https://wiki.mozilla.org/RapidRelease/Calendar ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: PROCERT issues
Bug Filed regarding PROCERT Action Items: https://bugzilla.mozilla.org/show_bug.cgi?id=1405862 Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Doppelganger/tripleganger intermediate certificates
Bugs filed, or already existed… To the CAs who have already responded here in this discussion, please also copy-paste your incident report into the bug. > > > > Issuer: https://crt.sh/?caid=140 > >Issuer O: AC Camerfirma SA CIF A82743287 > > Issuer CN: Chambers of Commerce Root > > Subject CN: (id=1252) AC CAMERFIRMA AAPP > > (id=12625404) AC Camerfirma Express Corporate Server > >Serial #: 0d > > Certs: https://crt.sh/?id=1252 > > https://crt.sh/?id=12625404 > >Revoked?: No > > > > I see these Camerfirma doppelgangers in the CCADB. https://bugzilla.mozilla.org/show_bug.cgi?id=1405815 > > > > > Issuer: https://crt.sh/?caid=935 > >Issuer O: Actalis S.p.A./03358520967 > > Issuer CN: Actalis Authentication Root CA > > Subject CN: UniCredit Subordinate External > >Serial #: 3e:5d:be:44:e7:51:5a:5a > > Certs: https://crt.sh/?id=47081615 > > https://crt.sh/?id=147626411 > >Revoked?: No > > > I am not finding these Actalis certs in the CCADB. Will include that in the > Actalis bug as well. > > By the way, I do not see them listed here: > https://crt.sh/mozilla-disclosures#undisclosed > https://bugzilla.mozilla.org/show_bug.cgi?id=1405817 > > > > > > Issuer: https://crt.sh/?caid=941 > >Issuer O: Atos > > Issuer CN: Atos TrustedRoot 2011 > > Subject CN: Atos TrustedRoot Client-CA 2011 > >Serial #: 5b:6a:8e:8d:5a:86:71:8f > > Certs: https://crt.sh/?id=12725513 > > https://crt.sh/?id=12725727 > > https://crt.sh/?id=12728899 > >Revoked?: No > > Subject CN: Atos TrustedRoot CodeSigning-CA 2011 > >Serial #: 33:45:52:39:ec:16:dd:62 > > Certs: https://crt.sh/?id=18068233 > > https://crt.sh/?id=49643406 > >Revoked?: Yes > > Subject CN: Atos TrustedRoot Server-CA 2011 > >Serial #: 6b:5d:91:bc:13:61:ce:75 > > Certs: https://crt.sh/?id=705899 > > https://crt.sh/?id=18068212 > >Revoked?: Yes > > > I see these Atos doppelgangers in the CCADB. > > https://bugzilla.mozilla.org/show_bug.cgi?id=1329223 > > > > > > Issuer: https://crt.sh/?caid=138 > >Issuer O: SwissSign AG > > Issuer CN: SwissSign Gold CA - G2 > > Subject CN: AffirmTrust Networking > >Serial #: 84:3c:74:b1:aa:34:86:b1:c4:c7:a0:df:55:b5:e9 > > Certs: https://crt.sh/?id=3386 > > https://crt.sh/?id=1991456 > >Revoked?: No > > Subject CN: Trend Micro Gold CA > >Serial #: 49:e1:33:6e:94:e5:b6:a5:2d:a9:6e:d4:8a:e2:76 > > Certs: https://crt.sh/?id=12629343 > > https://crt.sh/?id=198226194 > >Revoked?: Yes > > I see these SwissSign doppelgangers in the CCADB. > https://bugzilla.mozilla.org/show_bug.cgi?id=1404403 > > > > > > Issuer: https://crt.sh/?caid=656 > >Issuer O: Trustwave Holdings, Inc. > > Issuer CN: Trustwave Organization Issuing CA, Level 2 > > Subject CN: Trustwave Enterprise CA > >Serial #: 6b:49:d2:04 > > Certs: https://crt.sh/?id=12624965 > > https://crt.sh/?id=12629351 > >Revoked?: Issuer cert revoked (https://crt.sh/?id=95565) > > > > Issuer: https://crt.sh/?caid=12391 > >Issuer O: Trustwave Holdings, Inc. > > Issuer CN: Trustwave Enterprise CA > > Subject CN: Trustwave Enterprise VPN CA > >Serial #: 41:90:ae:5d > > Certs: https://crt.sh/?id=12625419 > > https://crt.sh/?id=12629788 > >Revoked?: Issuer's issuer cert revoked (https://crt.sh/?id=95565) > > > I see the revoked issuer is in CCADB. The other certs are not, but that's OK > since the revoked issuer is in OneCRL. > https://bugzilla.mozilla.org/show_bug.cgi?id=1405826 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
A lot of the delay this time is in regards to our new Audit Case process. We'll work to get this cleared up this month. Forwarded Message Subject: Summary of October 2017 Audit Reminder Emails Date: Tue, 17 Oct 2017 19:00:06 + (GMT) Mozilla: Overdue Audit Statements Root Certificates: Autoridad de Certificacion Firmaprofesional CIF A62634068 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: BR and EV audits have happened, but there are action plans being presented to the auditors. Primary issues are use of UTF8 instead of PrintableString in jurisdictionOfIncorporation, and a recently repealed Spanish law that required privat 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: Overdue Audit Statements Root Certificates: Chambers of Commerce Root** Chambers of Commerce Root - 2008** Global Chambersign Root** Global Chambersign Root - 2008** ** Audit Case in the Common CA Database is under review for this root certificate. Standard Audit: https://bug986854.bmoattachments.org/attachment.cgi?id=8775118 Audit Statement Date: 2016-06-17 BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8800807 BR Audit Statement Date: 2016-08-05 EV Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8800811 EV Audit Statement Date: 2016-08-05 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: Chunghwa Telecom Co., Ltd. - ePKI Root Certification Authority** ** Audit Case in the Common CA Database is under review for this root certificate. Standard Audit: https://cert.webtrust.org/SealFile?seal=2277=pdf Audit Statement Date: 2016-11-04 BR Audit: https://cert.webtrust.org/SealFile?seal=2278=pdf BR Audit Statement Date: 2016-11-04 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: https://bugzilla.mozilla.org/attachment.cgi?id=8815072 Audit Statement Date: 2016-08-31 BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8815073 BR Audit Statement Date: 2016-08-31 EV Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8815074 EV Audit Statement Date: 2016-08-31 CA Comments: null Mozilla: Audit Reminder Root Certificates: IdenTrust Commercial Root CA 1** IdenTrust Public Sector Root CA 1** DST ACES CA X6** 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=2107=pdf Audit Statement Date: 2016-08-19 BR Audit: https://cert.webtrust.org/SealFile?seal=2106=pdf BR Audit Statement Date: 2016-08-19 CA Comments: null Mozilla: Audit Reminder Root Certificates: NetLock Arany (Class Gold) F?tanúsítvány 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: Security Communication EV RootCA1 Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8805235 Audit Statement Date: 2016-08-22 BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8805235 BR Audit Statement Date: 2016-08-22 EV Audit:
Re: Audit Reminder Email Summary
On Tuesday, October 17, 2017 at 2:44:11 PM UTC-7, Kathleen Wilson wrote: > A lot of the delay this time is in regards to our new > Audit Case process. > We'll work to get this cleared up this month. To those of you CAs who have correctly followed the instructions for providing your annual updates -- THANK YOU!!! Many of you have done this successfully without any problems. To the rest of the CAs, Please help us out here, by reading and following the instructions. http://ccadb.org/cas/updates "The process for submitting an annual update is as follows: 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." We've had CAs file multiple Audit Cases for the same audit statements, with different information. Please don't do that. You only need to file one Audit Case for each set of audit statements. If you are unsure, please just create one Audit Case and then send email to me and Aaron so we can help you out. Some CAs do not create the corresponding Root Cases to indicate which root certs were in scope of the audits and to provide the 3 test websites that are required by the BRs. Many of the CAs unfortunately have not tested their 3 test websites to ensure that the TLS certs chain up to those root certs and have the correct results. All of this is described in http://ccadb.org/cas/updates We continue to work to improve the interface to make it more obvious what you need to do. But in the meantime please carefully read and follow the instructions. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
CCADB Report: AllCertificateRecordsCSVFormat
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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Warning about posting via Google Groups
On Monday, November 20, 2017 at 7:51:59 AM UTC-8, Gervase Markham wrote: > Dear m.d.s.p., > > We appear to again have a problem with messages posted via the Google > Groups web UI making it to all subscribers on the list: > https://bugzilla.mozilla.org/show_bug.cgi?id=1412993 > > Until that problem is resolved, if you wish to post to the list, please > subscribe to the mailing list version or use the newsgroup gateway: > https://www.mozilla.org/about/forums/#dev-security-policy > > The Google Groups UI can still be used for referencing messages, and for > reading the list. > > Gerv If any of you have recently posted to mozilla.dev.security.policy, and your message has not shown up in Google Groups, please forward your message to me with full headers. The folks trying to debug this problem need the full email header for a failed message that is less than 8 days old. (all of the ones that I had previously provided are older than 8 days) Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
