On 23/11/2018 16:24, Enrico Entschew wrote: > This post links to https://bugzilla.mozilla.org/show_bug.cgi?id=1509512 > > syntax error in one tls certificate > > 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 became aware of the issue via https://crt.sh/ on 2018-11-12, 09:01 UTC. > > 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. > > Timeline: > 2018-11-12, 09:01 UTC CA became aware via https://crt.sh/ of a syntax error > in one tls certificate issued on 2018-06-02. The PrintableString of OBJECT > IDENTIFIER serialNumber (2 5 4 5) contains an invalid character. For more > details see https://crt.sh/?id=514472818 > 2018-11-12, 09:30 UTC CA Security Issues task force analyzed the error and > recommended further procedure. > 2018-11-12, 10:30 UTC Customer was contacted the first time. Customer runs an > international critical trade platform for emissions. Immediate revocation of > the certificate would cause irreparable harm to the public. > 2018-11-12, 13:00 UTC We performed a dedicated additionally coaching on > this specific syntax topic within the validation team to avoid this kind of > error in the future. > 2018-11-16, 08:40 UTC Customer responded first time and asked for more time > to evaluate the certificate replacement process. > 2018-11-19, 12:30 UTC CA informed the auditor TÜV-IT about the issue. > 2018-11-20, 15:19 UTC Customer declared to replace the certificate on > 2018-11-22 latest. > 2018-11-22, 15:52 UTC New certificate has been applied for and has been > issued. > 2018-11-22, 16:08 UTC The certificate with the serial number 3c 7c fb bf ea > 35 a8 96 c6 79 c6 5c 82 ec 40 13 was revoked by customer. > > 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. > > The CA has not stopped issuing EV-certificates. We applied dedicated coaching > on this specific syntax topic within the validation team to avoid this kind > of error until software adjustments to both effected systems have been > completed. > > 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. > > 1 Certificate > SHA-256 41F3AD0CBDA392F078D776FD1CDC0E35F7AF61030C56C7B26B95936F41A83B32 > Issued on 2018-06-01 > > 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. > > For more details see https://crt.sh/?id=514472818 > > 6. Explanation about how and why the mistakes were made or bugs introduced, > and how they avoided detection until now. > > This problem was caused within the frontend system to the customer and the > lint system. Both systems did not check the entry in the field of > serialNumber (2 5 4 5) correctly. It was possible to enter characters other > than defined in PrintableString definition. > > 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. > > The CA Security Issues task force together with the software development > analyzed the error. We applied dedicated coaching on this specific syntax > topic within the validation team to avoid this kind of error until software > adjustments to both effected systems have been completed. The changes in the > systems are expected to go live in early January 2019. >
In addition to this, would you add the following: - Daily checks of crt.sh (or some other existing tool) if additional such certificates are erroneously issued before the automated countermeasures are in place? - Procedurally (and eventually technically) restrict the serial number element to actual validated identification numbers from a fixed set of databases for each jurisdiction. For example for a Bundesamt, this should be a special prefix followed by some kind of official identifying number of entities within the Bundesvervaltung. Similar of cause for Landesamts, companies etc. Also, it is unclear why a Bundesamt belongs to an identification jurisdiction lower than the entire BDR. For comparison, Danish Company entities are fully identified by the numeric part of their VAT number (or a number from the same national database if it has no VAT registration), and this is what CAs put in the serialNumber distinguished name element. Danish government entities also have unique numbers from a different database, but I haven't found a government certificate the serialNumber element. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
