Mark, Thanks for providing a detailed report about this, including the steps being taken to prevent future events like this. Your proposed remediation plans sound like excellent steps to ensure future conformance, and demonstrate an understanding as to the root causes and how to prevent them in the future. More importantly, they demonstrate a level of attention that hopefully all CAs engaging in third-party cross-signing should aspire to - namely, the oversight and supervision of the scope of audits to ensure all necessary controls are in place, the integration of automated checks, and greater transparency.
On Fri, Aug 11, 2017 at 10:39 AM, Policy Authority PKIoverheid via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > Dear Mozilla Security Policy Community, > > My apologies for the delayed follow up response. > > As stated in my email from 07/25/2017, Digidentity (DDY), one of our > TSP’s, issued 777 certificates from September 30th 2016 which were not > compliant with BR ballot 164. > > DDY has fixed the problem with the serial generation and is in the process > of replacing all 777 non-compliant certificates. > > Below you will find the answers on the following questions: > 1. Why did Logius/Policy Authority PKIoverheid not detect, identify, > disclose, and resolve this matter prior to public notification? > 2. Why did DDY not implement the serial number entropy as required by the > Baseline Requirements? > 3. Was this detected by the auditor? If not, why not? > > ANSWER ON QUESTION 1: > Logius PKIoverheid was notified by Gervase Markham to draw the issue to > their attention. See the timeline for further details. > > Logius PKIoverheid relies on the audits performed by external auditors to > make sure that the Trusted Service Providers (TSPs) aka CAs within the > PKIoverheid/Staat der Nederlanden hierarchy fully comply with applicable > requirements (like the BR, ETSI and our own Program of Requirements). > > For further details about the PKIoverheid architecture aka hierarchy see > one of these bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=529874 or > https://bugzilla.mozilla.org/show_bug.cgi?id=1016568 > > Inform > • Our TSPs are responsible to follow relevant changes in the BR. Besides > that the Policy Authority (PA) PKIoverheid informs all PKIoverheid-TSPs > about (intended) relevant changes to the Baseline Requirements. > > Check > • We require a yearly full ETSI EN 319 411-1 audit. In the case of DDY the > most recent full audit is of November 2016. > • We require a ETSI accredited auditor. In the case of DDY the auditor is > BSI and in 2016 it was accredited by the RvA (In Dutch: Raad voor > Accreditatie), the Dutch accreditation body (for more information see: > https://www.rva.nl/en/our-organization/about-the-rva). > • We manually take samples of the issued certificates from our TSPs using > CT logs. Unfortunately DDY was not part of the latest samples (see new > measure 2). > > Approve > • The PA PKIoverheid reviews the audit rapports from the TSPs and if > necessary will take measures to make sure the TSP conforms to the > applicable audit requirements. > > > Timeline (all times are UTC): > > 19 July 2017 00:27: A posting on mozilla.dev.security.policy stating a > non-compliant certificate issued by DDY. > > https://groups.google.com/forum/#!topic/mozilla.dev. > security.policy/vl5eq0PoJxY > > 20 July 2017 16:45: Mozilla (Gerv) notifies the Policy Authority (PA) > PKIoverheid on non-compliant certificates from DDY > > 20 July 2017 16:45: START INCIDENT > > 20 July 2017 17:27: PA PKIoverheid starts investigating the issue and > almost immediately raises an internal incident. > > 21 July 2017 09:08: PA PKIoverheid issues DDY to postpone further issuing > of certificates and requests an action plan from DDY how they will resolve > the issue by revoking and reissuing all certificates involved. > > 21 July 2017 09:50: DDY confirms postponing the issuing of certificates. > > 21 July 2017 09:50: FURTHER CERTIFICATE ISSUING SUSPENDED > > 24 July 2017 08:53: DDY delivers action plan including two newly generated > and compliant test certificates as proof that they fixed the issue. > > 24 July 2017 16:25: Based on the provided certificates the PA PKIoverheid > requests DDY to start executing the action plan including the approval to > restart issuing certificates. > > 24 July 2017 16:25: ISSUING RESTARTED > > 25 July 2017 14:37: DDY installs first production certificate on website ( > https://www.digidentity.eu/nl/home/) > > 25 July 2017 14:37: DDY starts revoking and replacing certificates > > 25 July 2017 21:20: PA PKIoverheid post a message on > mozilla.dev.security.policy stating that DDY has proven to be able to > generate compliant certificates and is allowed to restart the issuing of > new (compliant) certificates. A link to the compliant new DDY certificates > is included in this post as evidence. > > 26 July 2017 17:40: PA PKIoverheid requests Mozilla to honor the request > to extend the > 24-hour revocation time. > > 27 July 2017 10:31: Mozilla grants the PA PKIoverheid the request to > extend the revocation time (that is, Mozilla will accept an audit qualified > by this event). > > 27 July 2017 13:21: PA PKIoverheid requests the other Application Software > Suppliers to agree with Mozilla. > > 28 July 2017 12:54: PA PKIoverheid informs DDY that it requests an audit > statement regarding the Ballot 164 incident. > > 28 July 2017 12:54: PA PKIoverheid starts monitoring the resolving > progress but keeps the incident open until all involved certificates are > revoked or replaced. > INCIDENT UNDER CONTROL > > > ANSWER ON QUESTION 2: > DDY concluded wrongly that ballot 164 was not applicable for them since > the use of sequential serial numbers is not a security risk when used in > conjunction with the SHA-256 with RSA encryption certificate signing scheme. > > > ANSWER ON QUESTION 3: > Non-compliance with this requirements wasn’t noticed by the auditor > because DDY didn’t include the specific requirement in their Statement of > Applicability (reason: see the answer on question 2). ETSI EN 319 403 > (which determines the requirements for conformity assessment bodies) is not > clear about who determines the scope of an audit. The auditor’s > interpretation was that the client (DDY) had to determine the scope of the > audit (based on their Statement of Applicability). This will be mitigated > for future audits with new measure 4. > > > NEW MEASURES: > The following measures are newly introduced to mitigate risks that have > been identified during the evaluation of this incident. > 1. The implementation of Certificate Transparancy (CT) will reduce the > detection-time of non-compliant certificates to hours instead of > days/weeks/months. Implementation date is set on October 1st. > 2. The PA PKIoverheid will increase the rate of random certificate checks > to weekly as long as CT has not been implemented. Effective immediately. > 3. After a ballot has been adopted by the CABForum the PA PKIoverheid will > require of it TSP’s to show proof of conformance to the ballot before the > effective date. If a TSP isn't able to show proof of conformance as of the > effective date, certificate issuance will be suspended until the TSP can > supply evidence to the contrary. Effective 09/01/2017. > 4. PA PKIoverheid will review and/or determine the scope for the TSP in > question before any type of audit. Without clearance/approval of the PA > PKIoverheid no audit or issuance of certificates will take place. Effective > 09/01/2017. > 5. Research into possible implementation of (automated) Certlint checks in > the issuance process. > > > Best Regards, > Mark Janssen > _______________________________________________ > dev-security-policy mailing list > 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 https://lists.mozilla.org/listinfo/dev-security-policy
