Re: Audit Reminder Email Summary
Forwarded Message Subject: Summary of August 2019 Audit Reminder Emails Date: Tue, 20 Aug 2019 19:00:34 + (GMT) Mozilla: Overdue Audit Statements CA Owner: AC Camerfirma, S.A. Root Certificates: Chambers of Commerce Root - 2008** Global Chambersign Root - 2008** ** Audit Case in the Common CA Database is under review for this root certificate. Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8995928 Standard Audit Period End Date: 2018-04-13 BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8995930 BR Audit Period End Date: 2018-04-13 EV Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8995931 EV Audit Period End Date: 2018-04-13 CA Comments: CA is requesting audit statement updates from their auditors, who are not available until first week of September. Mozilla: Audit Reminder CA Owner: GoDaddy Root Certificates: Go Daddy Class 2 CA Go Daddy Root Certificate Authority - G2 Starfield Class 2 CA Starfield Root Certificate Authority - G2 Standard Audit: https://www.cpacanada.ca/generichandlers/aptifyattachmenthandler.ashx?attachmentid=222460 Standard Audit Period End Date: 2018-06-30 BR Audit: https://www.cpacanada.ca/generichandlers/aptifyattachmenthandler.ashx?attachmentid=222461 BR Audit Period End Date: 2018-06-30 EV Audit: https://www.cpacanada.ca/generichandlers/aptifyattachmenthandler.ashx?attachmentid=222462 EV Audit Period End Date: 2018-06-30 CA Comments: null Mozilla: Audit Reminder CA Owner: IdenTrust Services, LLC Root Certificates: IdenTrust Commercial Root CA 1 IdenTrust Public Sector Root CA 1 DST Root CA X3 Standard Audit: https://bug1484318.bmoattachments.org/attachment.cgi?id=9006625 Standard Audit Period End Date: 2018-06-30 BR Audit: https://bug1484318.bmoattachments.org/attachment.cgi?id=9006626 BR Audit Period End Date: 2018-06-30 CA Comments: null Mozilla: Audit Reminder CA Owner: SECOM Trust Systems CO., LTD. Root Certificates: SECOM Trust.net - Security Communication RootCA1 Security Communication RootCA2 Standard Audit: https://www.cpacanada.ca/generichandlers/aptifyattachmenthandler.ashx?attachmentid=222449 Standard Audit Period End Date: 2018-06-08 BR Audit: https://www.cpacanada.ca/generichandlers/aptifyattachmenthandler.ashx?attachmentid=222450 BR Audit Period End Date: 2018-06-08 EV Audit: https://www.cpacanada.ca/generichandlers/aptifyattachmenthandler.ashx?attachmentid=222451 EV Audit Period End Date: 2018-06-08 CA Comments: null Mozilla: Overdue Audit Statements CA Owner: Asseco Data Systems S.A. (previously Unizeto Certum) Root Certificates: Certum Trusted Network CA 2 Certum CA Certum Trusted Network CA Standard Audit: https://bug1286477.bmoattachments.org/attachment.cgi?id=9001516 Standard Audit Period End Date: 2018-03-26 BR Audit: https://bug1286477.bmoattachments.org/attachment.cgi?id=9001514 BR Audit Period End Date: 2018-03-26 EV Audit: https://bug1286477.bmoattachments.org/attachment.cgi?id=9001515 EV Audit Period End Date: 2018-03-26 CA Comments: https://bugzilla.mozilla.org/show_bug.cgi?id=1566586 Update 8/16: "We are waiting for publication. We will update CCADB as soon as possible when we get information from EY Poland." Mozilla: Audit Reminder CA Owner: SSL.com Root Certificates: SSL.com EV Root Certification Authority ECC** SSL.com Root Certification Authority ECC** SSL.com Root Certification Authority RSA** SSL.com EV Root Certification Authority RSA R2** ** Audit Case in the Common CA Database is under review for this root certificate. Standard Audit: https://cdn.ssl.com/app/uploads/2018/09/SSL-COM-WTCA-Indp-Acct-Report-and-Mgmt-Assertion-June-2018.pdf Standard Audit Period End Date: 2018-06-30 BR Audit: https://cdn.ssl.com/app/uploads/2018/09/SSL-COM-WTBR-Indp-Acct-Report-and-Mgmt-Assertion-June-2018.pdf BR Audit Period End Date: 2018-06-30 EV Audit: https://cdn.ssl.com/app/uploads/2018/09/SSL-COM-WTEV-SSL-Indp-Acct-Report-and-Mgmt-Assertion-June-2018.pdf EV Audit Period End Date: 2018-06-30 CA Comments: null ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CA handling of contact information when reporting problems
On Mon, Aug 19, 2019 at 10:26 AM Mathew Hodson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > If these situations were common, it could create a chilling effect on > problem reporting that would hurt the WebPKI ecosystem. Are specific > procedures and handling of contact information in these situations > covered by the BRs or Mozilla policy? > No, there are not. This is not an uncommon practice within the broader realm of Security Incident Reporting / Disclosure, and has been the subject of much discussion and debate for 30+ years of computer security. You can find plenty of information about lawsuits intended to chill vulnerability disclosure. This is not a problem that can or will be solved within the BRs or Mozilla Policy. In general, anyone disclosing vulnerabilities should expect their information may be released. That's par for the course here. Different jurisdictions may have different protections, but reporters are encouraged to disclose directly with the CA. Root Store Operators may be willing to intermediate (e.g. disclosing to Mozilla's security reporting), but I'm also not aware of any strong guarantees Mozilla makes with respect to protecting the information of folks who report security issues, especially in the potential incident of (misguided, frivolous) lawsuits. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CA handling of contact information when reporting problems
Hello, I am a bit shocked about this case. The fact that this happened to someone would restrain myself from reporting key compromises. Even though it is the company's fault to protect their private key, their lawers still might sue the incident-reporter. A judge might not understand the PKI system and therefore might tend to decide in favor of the company, because the company can proove that they lost XXX dollars revenue because of the service outtage. I think big companies have a lot of expensive lawers who might win such a case against a private person who might not even have the money for a good lawer at all. In re privacy: Telling someone the name and/or email address of a person without their consent is a clear violation of the GDPR (European General Data Protection Regulation), in case European law applies. Publishing the name and/or email address online (e.g. in the incident template) is even worse. Take care, Daniel Am Montag, 19. August 2019 16:26:06 UTC+2 schrieb Mathew Hodson: > Tom Wassenberg on Twitter reported an experience he had with Sectigo > when reporting a compromised private key. > > https://twitter.com/tomwas54/status/1162114413148725248 > https://twitter.com/tomwas54/status/1162114465065840640 > https://twitter.com/tomwas54/status/1162114495017299976 > > "So a few weeks ago, I came across a private key used for a TLS > certificate, posted online. These should never be public (hence the > "private"), and every trusted CA is obliged to revoke any certificate > they issued when they become aware its private key is compromised. > > "So when I informed the issuing CA (@SectigoHQ) about this, they > promptly revoked the cert. Two weeks later however, I receive an angry > email from the company using the cert (cc'd to their lawyer), blaming > me for a disruption in the services they provide. > > "The company explicitly mentioned @SectigoHQ "was so kind" to give > them my contact info! It was a complete surprise for me that > @SectigoHQ would do this without my consent. Especially seeing how the > info was used to badger me." > > If these situations were common, it could create a chilling effect on > problem reporting that would hurt the WebPKI ecosystem. Are specific > procedures and handling of contact information in these situations > covered by the BRs or Mozilla policy? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
