As previously noted on this list, there are two Siemens CAs that have issued certificates with less than 64 bits of entropy. See https://misissued.com/batch/6/ The Siemens Issuing CA Internet 2013 is subordinate to a DigiCert-owned root, and the Siemens Issuing CA Internet 2016 is signed by Quo Vadis.
This email is meant to only address and respond as to certificates issued by the Siemens Issuing CA Internet 2013, which ceased issuing certificates in 2016, although it also contains information regarding the Siemens Issuing CA Internet 2016. We suspect that further response regarding the 2016 CA will be forthcoming from either QuoVadis or Siemens. Siemens reported the following to us earlier today: --------- We have discovered an implementation error in our in-house CA software which meant it was using 32bit serials, although they were non sequential. Siemens Issuing CA Internet 2013 was then already offline, because we started on 2nd November 2016 the issuing with the Siemens Issuing CA Internet 2016 which is cross-signed by QuoVadis. Furthermore, the Siemens Issuing CA Internet 2016 was taken offline immediately upon report to us and this was reported by Stephen Davidson from QuoVadis to the listserv on 7/20. The Issuing CA Internet 2016 remains offline and we issue now certificates from the external market. We also informed our external Auditor about that issue immediately. For the future, all problems are fixed. Originally it was planned to start on 4th of October 2017 with a new CA System (EJBCA) with full CT Logging. When we noticed the serial number issue, we doubled up our resources and moved the Go Live roughly one month earlier now to 8th of September 2017. In the past, we issued 137 certificates from the Siemens Issuing CA 2013 and the validity period of the certificates ends: 1 in September 2017 120 in October 2017 15 in November 2017 Except these, there are three certificates with a longer validity period: CN=circuit.siemens.com,L=Muenchen,SP=Bayern,C=DE,O=Siemens-Internet,OU=GS IT IN SPLM SDC US 2018-02-20 13:32:43.000 We are discussing with the customer to exchange the certificate, here some technical points must be clarified. The other two certificates are infrastructure certificates and cannot be replaced due the need of the function of the OCSP Responder and the CA Test site which is an ETSI Requirement CN=2013-internet-valid.catestsite.siemens.com,L=Muenchen,SP=Bayern,C=DE,O=Si emens-Internet,OU=GS IT HR 74,SN=ETSI0002 2018-02-20 14:01:05.000 CN=Siemens PKI OCSP Signer ZZZZZZY9,O=Siemens,C=DE 2018-04-10 10:24:31.000 The replacement is complicated as, although the PKI is centralized, the certificates are issued to Siemens group companies around the world. We´re working on a replacement plan to do this in a proper time. As the certificates are already reaching their end of life, for most of them the renewal process is already ongoing (60 days before expirations the certificate holders are informed to renew). -------- Obviously we will continue to evaluate DigiCert's response to this information from Siemens, but we figured that interim disclosure of this information to this list was important. Sincerely yours, Ben Wilson -----Original Message----- From: dev-security-policy [mailto:[email protected]] On Behalf Of Nick Lamb via dev-security-policy Sent: Sunday, August 13, 2017 2:07 AM To: [email protected] Subject: Re: Certificates with less than 64 bits of entropy On Sunday, 13 August 2017 04:04:45 UTC+1, Eric Mill wrote: > While not every issuing CA may take security seriously enough to > employ engineers on staff who can research, author and deploy a > production code fix in a 24 hour period, every issuing CA should be > able to muster the strength to keep the community informed of their > plans and progress in however long it takes to address the issue. In my opinion the correct incentive structure here is: We don't care whether you ever start issuing again but if you have a limited time to stop the problem, if you can't fix it quickly that will be by ceasing issuance. Switching off the issuance pipeline in a timely fashion when a problem is uncovered (so that things stop getting worse) needs to be something every CA can do. It should always be within the skill set of personnel available "on call" when things go wrong. But whether they have engineers able to actually fix a problem the same day, the next day or a month later is an operational detail for the CA leadership. For commercial CAs there is presumably some trade-off between the need to be seen as a reliable supplier for repeat subscribers and the cost of having on-call engineers. But it needn't concern m.d.s.policy where they think best to draw the line, so long as they prevent the problem recurring by switching off an affected issuance pipeline until it's fixed. I am minded to draw comparison to "emergency plumber" services. Despite it being an "emergency" the plumber will be no more quickly able to source parts from a discontinued product line, or plan and install complex new systems than a non-emergency plumber. Those things may still take weeks. But what they can always do immediately is switch off supply of water or gas so as to stop things getting worse. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
