On Thu, 23 Aug 2018 05:50:05 -0700 (PDT) Andy Warner via dev-security-policy <[email protected]> wrote:
> May 21st 2018, a new tool for issuing certificates within Google was > made available to internal customers. Within hours we started to > receive reports that Chrome Canary (v67) with Certificate > Transparency checks enabled was showing warnings. A coding error led > to the new tool providing Signed Certificate Timestamps (SCTs) from 2 > Google CT logs instead of one Google and one non-Google log. Feel free to jump in anywhere I've made a mistake, this might totally invalidate some of my questions. Presumably, since you eventually "fixed" this by asking Subscribers to re-issue, the SCTs are baked into a signed certificate, rather than provided separately so that the Subscriber can use them with e.g. Stapling technologies ? Which means that this "new tool" also involved a Google controlled subCA signing these certificates with, as it turns out, the wrong SCTs in them. It's not clear to me if the tool and CA are operationally one and the same. Q1: Could a more significant "coding error" in this tool have resulted in certificates being mis-issued (for example with SANs that don't belong to Google, or lacking mandatory X.509 fields, or without being CT logged)? If not please explain why the tool couldn't cause this. Q2: If this error hadn't caused a negative end-user experience, what mechanisms if any do you believe would have brought it to your attention and how soon? e.g. does a team sample resulting certificates from this tool at some interval? If it samples pre-certificates that would not have detected this error, but is worth mentioning. Q3: Such mistakes are of course inevitable in software development. But they could also be introduced maliciously. Were you able to confidently identify which specific individual(s) made the relevant change? (I don't want names). Are you confident you'd be able to do this even if somehow the production tool turned out not to match your revision control systems? Thanks as always for satisfying my curiosity Nick. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
