Dear Ryan,
Here is an initial, interim response to your email as it relates to certificates issued by the TI Trust Technologies Global CA. (Jeremy Rowley or I will be sending you a separate email shortly that reports on this issue with regard to Cybertrust Japan.) I will supplement this response as more information becomes available. Explanation to the community about how/why this happened: Apparently Telecom Italia Trust Technologies does not have adequate Baseline-Requirements filters in place to catch these. How many certificates it affected: Only the 5 listed at <https://misissued.com/batch/7/> https://misissued.com/batch/7/, as far as we know. What steps DigiCert is taking to prevent these issues in the future?: As a result of this and other recent issues, DigiCert is bringing certificate issuance for TI Trust Technologies in-house. We will be revoking CA certificate serial no. 07279ca7 issued to TI Trust Technologies Global CA. The key ceremony to create a new in-house CA is scheduled for Wednesday, 23 August, 2017. Do you have details about why DigiCert failed to detect these, and what steps DigiCert has in place to ensure compliance from its subordinate CAs? DigiCert uses some of the same tools used by others to monitor and detect mis-issuance by external, cross-certified CAs. These include crt.sh, cablint, and Censys.IO. As illustrated in this case, external CAs may be revoked if they do not comply. Whenever DigiCert is made aware of the non-compliance of an external CA, it contacts the operator of that CA and requests that non-compliant certificates be revoked, that the CA scan its records for other certificates with the same infirmity, and that it patch its systems so that the issue does not recur. On a proactive basis, DigiCert regularly advises external CAs of new requirements in the Baseline Requirements or browser root programs and asks these external CAs to ensure their ongoing compliance. Contracts with such entities also require compliance with the requirements. Sincerely yours, Ben Ben Wilson, JD, CISA, CISSP VP Compliance +1 801 701 9678 From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Saturday, August 12, 2017 8:56 PM To: Ben Wilson <ben.wil...@digicert.com> Cc: Jonathan Rudenberg <jonat...@titanous.com>; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Certificates with reserved IP addresses Do you have an estimate on when you can provide an explanation to the community about how/why this happened, how many certificates it affected, and what steps DigiCert is taking to prevent these issues in the future? Do you have details about why DigiCert failed to detect these, and what steps DigiCert has in place to ensure compliance from its subordinate CAs? On Sat, Aug 12, 2017 at 10:19 PM, Ben Wilson via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > wrote: Thanks. We've sent an email to the operators of the first two CAs (TI Trust Technologies and Cybertrust Japan) that they need to revoke those certificates. Thanks again, Ben -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+ben <mailto:dev-security-policy-bounces%2Bben> =digicert....@lists.mozilla.org <mailto:digicert....@lists.mozilla.org> ] On Behalf Of Jonathan Rudenberg via dev-security-policy Sent: Saturday, August 12, 2017 7:53 PM To: mozilla-dev-security-pol...@lists.mozilla.org <mailto:mozilla-dev-security-pol...@lists.mozilla.org> Subject: Certificates with reserved IP addresses Baseline Requirements section 7.1.4.2.1 prohibits ipAddress SANs from containing IANA reserved IP addresses and any certificates containing them should have been revoked by 2016-10-01. There are seven unexpired unrevoked certificates that are known to CT and trusted by NSS containing reserved IP addresses. The full list can be found at: https://misissued.com/batch/7/ DigiCert TI Trust Technologies Global CA (5) Cybertrust Japan Public CA G2 (1) PROCERT PSCProcert (1) It’s also worth noting that three of the "TI Trust Technologies” certificates contain dnsNames with internal names, which are prohibited under the same BR section. Jonathan _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> https://lists.mozilla.org/listinfo/dev-security-policy
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
