Re: Audit Reminder Email Summary
Here's the summary of Mozilla's audit reminder emails that were sent today by the CCADB. Reminder: The date logic for sending these emails is documented in the following wiki page. https://wiki.mozilla.org/CA/Email_templates#Audit_Reminder_Email_Templates - Audit Reminder is sent when previous Audit Period End date is 1 year plus 31 days to 93 days old. - Overdue Notice is sent when previous Audit Period End date is 1 year plus 93 days to 150 days old. - Danger of being removed warning is sent when previous Audit Period End date is older than 1 year plus 150 days. Forwarded Message Subject: Summary of March 2019 Audit Reminder Emails Date: Tue, 19 Mar 2019 19:00:09 + (GMT) Mozilla: Audit Reminder CA Owner: Krajowa Izba Rozliczeniowa S.A. (KIR) Root Certificates: SZAFIR ROOT CA2 Standard Audit: http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221051 Standard Audit Period End Date: 2017-12-18 BR Audit: http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221052 BR Audit Period End Date: 2017-12-18 CA Comments: null Mozilla: Audit Reminder CA Owner: certSIGN Root Certificates: certSIGN ROOT CA Standard Audit: https://www.certsign.ro/certsign/files/certSIGN-Webtrust-CA-Report-2018.pdf Standard Audit Period End Date: 2018-02-08 BR Audit: https://www.certsign.ro/certsign/files/certSIGN-Webtrust-CA-SSL-Report-2018.pdf BR Audit Period End Date: 2018-02-08 CA Comments: null Mozilla: Audit Reminder CA Owner: QuoVadis Root Certificates: QuoVadis Root CA 1 G3 QuoVadis Root CA 2 QuoVadis Root CA 2 G3 QuoVadis Root CA 3 QuoVadis Root CA 3 G3 QuoVadis Root Certification Authority Standard Audit: http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221092 Standard Audit Period End Date: 2017-12-31 BR Audit: http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221093 BR Audit Period End Date: 2017-12-31 EV Audit: http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221094 EV Audit Period End Date: 2017-12-31 CA Comments: null Mozilla: Audit Reminder CA Owner: Government of Spain, Fábrica Nacional de Moneda y Timbre (FNMT) Root Certificates: FNMT-RCM - SHA256 Standard Audit: https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2018041201_Audit_Attestation_s.pdf Standard Audit Period End Date: 2018-01-12 BR Audit: https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2018041201_Audit_Attestation_s.pdf BR Audit Period End Date: 2018-01-12 CA Comments: null Mozilla: Audit Reminder CA Owner: Amazon Trust Services Root Certificates: Amazon Root CA 3 Amazon Root CA 2 Starfield Services Root Certificate Authority - G2 Amazon Root CA 1 Amazon Root CA 4 Standard Audit: http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221192 Standard Audit Period End Date: 2018-01-15 BR Audit: http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221193 BR Audit Period End Date: 2018-01-15 EV Audit: http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221194 EV Audit Period End Date: 2018-01-15 CA Comments: null ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Virginia Tech misissuance report for 63 bit serial numbers
Hi Wayne, Can you open a Mozilla ticket for one of our older customers, Virginia Tech (VT)? Thanks. === 1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date. We received the disclosure report [1]. Note that this is a technically constrained CA that stopped issuing certificates in April 2018. 2. A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done. 3/19/2019: GlobalSign researched VT issuance based on [1] and found that certificates issued prior to 1 August 2017 were impacted while certificates issued between 8/1/2017 and 4/26/2018 have sufficient serial number entropy. They are now obtaining certificates from other CAs so no further non-compliant certificates will be issued. 3. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation. This CA stopped issuing certificates on 4/26/2018, so the certificates in question were all issued prior to this date. 4. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued. Initial reporting indicates there are 447 certificates issued between 9/30/2016 and 8/1/2017 5. The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem. We are in the process of collecting the list of impacted certificates from VT. 6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. We will collect the information on how the mistake was made from VT in the coming days. 7. 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. This CA is no longer issuing certificates and it will be revoked as soon as all issued certificates have expired or have been replaced. References: [1] https://docs.google.com/spreadsheets/d/1K96XkOFYaCIYOdUKokwTZfPWALWmDed7znjC Fn6lKoc/edit#gid=1093195185 smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Pre-Incident Report - WISeKey Serial Number Entropy
In light of the recent discussion related to serial number Entropy, at WISeKey we could verify that we were also affected by this issue. We are still doing the final investigation, but I'd like to open this thread to initiate the disclosure. I'll do the same opening a bug. As a preliminary note I'd like to express that the issue has only happened in CA not in production and not issuing certificates for end customers. The only affected certificates are a low number of test certificates issued to our own domains. #1. How your CA first became aware of the problem. 6/March/2019, reviewing a discussion in the mozilla group #2. A timeline of the actions your CA took in response. 7/March/2019, identified a potential issue due to misinterpretation of the EJBCA settings. 9/March/2019, confirmed the problem and started the full investigation. #3. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. This CA was already disabled for issuance of new certificates since time ago. Actually, WISeKey is not yet actively issuing SSL certificates, as part of the implications of the QuoVadis acquisition, as the active SSL issuance was transferred to the QV platform. This is changing, as explained in #7. #4. A summary of the problematic certificates. We identified about 30 potentially problematic entries in the CT logs, most of them issued in late 2016. All the occurrences are tests certificates. No customer has been affected, no production website is using these potentially problematic certificates. #5. The complete certificate data for the problematic certificates. We will provide a full list in the next days as follow-up of our investigation. #6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. Misinterpretations of BR stating 64bit integer. We didn't detected the issue with the linting tools. #7. 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. WISeKey is already in a project to rebuild part of our PKI as a consequence of the carve-out of the QuoVadis business and the need to get back full capabilities to issue SSL with a more modern infrastructure. This plan already included the deprecation of a number of CAs that didn't get into production, and this includes the affected by this issue. We have already contemplated in the plan the assurance that the new EJBCA systems will not reproduce this issue. Therefore, any affected CA will be revoked in the next weeks (current plan is to put in production the new CAs during the second half of April). None of the affected CAs are production CAs used for customer, so there's no impact by this revocation. All the affected certificates will be revoked, either individually, either globally when revoking the issuing CA. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DarkMatter Concerns
G’day Folks, It was a pleasure meeting many of the Mozilla community face to face at the CAB Forum meeting at Apple HQ last week. There are many others of you however, whose interface to the community is right here on this list, and so I wanted to share my perspective and feedback here on the recent dialogue so that the openness and transparency of the community is preserved. Over the past few weeks, there’s been much debate and shared points of view around DarkMatter’s multi-year process to have our CA Roots included in Mozilla’s Root Store. Who could have predicted that along the way, the community would have such wide-spread impact from the serialNumber entropy issue? I do think the BRs are a little ambiguously worded in this regards, and this is what certainly tripped us up, but upon learning what was intended by the standard, DarkMatter has completed its revocation of every still valid affected TLS certificate (~175), and we actioned that immediately, completing the process over about 72 hrs (timing over the week-end in the UAE was not optimal for us otherwise we could have completed it sooner). We still need to re-issue the Issuing CAs and submitted Roots – these are dependent on the availability of our WebTrust Auditors, but we expect this to be finalized in the next week or so. Many others in the community are also evaluating replacement of affected certificates e.g. see [1] [2] [3], etc. But the volumes these organizations are dealing with will make it difficult to meet BR revocation timelines, which is why I think Mozilla’s recent acknowledgement of this challenge with a proposal for an updated best practice for revocation is the right discussion to have. I think this is where the community is at its best: working together to identify and manage issues, learning from each other in how best to take action and resolving it as quickly as possible while maintaining the security and integrity of services for end users. After all, we ultimately share the same goal: transparent community-based processes that promote participation, accountability and trust [4]. Resolving this issue together is a good example of this principle in action. As I reflect on the many discussions in this community, and also with the 40-odd companies at last week’s CA/B Forum, it is clear that there is quite an interest in the DarkMatter story. Unfortunately, the one that has often been promoted as evidence in this community – is one that is not based on truth, and one that has consistently been refuted by DarkMatter. I would like to set the record straight once and for all, and share with all of you why DarkMatter’s story is not what some have claimed, but is, I believe, actually completely aligned with Mozilla’s own manifesto. DarkMatter Group was founded by Faisal Al Bannai, one of the most accomplished business leaders in the Middle East [5], as a commercial business entity that specializes in Cyber Security services, and solutions. Al Bannai served as CEO and founder until recently (2018), when he handed over the leadership role of the company to Karim Sabbagh, formerly the CEO of the world leading satellite fleet operator SES [6]. Al Bannai is the sole beneficial shareholder of the DarkMatter Group. The CA business that I head within the DarkMatter Group, and which I will provide further details below, is a completely independent business unit housed in a legally separate subsidiary company. The general business of the DarkMatter Group is all centered around cybersecurity. DarkMatter is very active in our local constituency [7], [8], [9], we have even developed and launched our own mobile phone [10]. The Cybersecurity divisions of DarkMatter are fully engaged in and participate in identifying and disclosing malicious applications that attack the security and privacy of individuals everywhere. Some recent examples of this are where DarkMatter researchers identified and informed Google of a malicious application available on the Google play store [11], and DarkMatter researchers also made a responsible disclosure to Apple of a significant attack that “bypasses all native macOS security measures”, (which findings were also presented at Hack-In-the-Box conference in Singapore [12]. This just highlights a couple. For those who have questioned who is really in the driving seat of the DarkMatter CAs, I want to assure you that DarkMatter’s PKI business has always been operated independently. We are a legally separate entity – housed under a subsidiary of the DarkMatter Group. Only myself and my handpicked team ever have hands on key material, and no single individual can effect an issuance without the validation of a counterpart and always under multiparty and multifactor authentication. We have stringent controls around who is eligible to hold a trusted role, and they must continue to meet operational KPIs, training and risk evaluation metrics to
