On Mon, Feb 18, 2019 at 2:49 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> On 15/02/2019 19:33, Ryan Sleevi wrote: > > On Fri, Feb 15, 2019 at 12:01 PM Jakob Bohm via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > >> Indeed, the report states that the bug was in the pre-issuance checking > >> software. > >> > > > > I believe you may have misread the report. I do not have the same > > impression - what is stated is a failure of the control, not the linting. > > > > > > The report refers to the pre-checking code in question as the "filter". > > As the certificate hasn't been signed yet, pre-checking code needs to > either generate a dummy certificate (signed with a dummy untrusted key) > as input to a general cert-linter, or check the elements of the intended > certificate in a disembodied form. Indeed it does. It’s common form to check in a disembodied form as fields are input, typically from an RA endpoint. In fact, this is how every COTS CA product works. This emphasizes why it’s important to not speculate, and in particular, why it’s important and valuable to allow CAs to respond to the questions themselves in a timely fashion. This allows for a more meaningful understanding. > > >> One good community lesson from this is that it is prudent to use a > >> different brand and implementation of the software that does post- > >> issuance checking than the software doing pre-issuance checking, as a > >> bug in the latter can be quickly detected by the former due to not > >> having the same set of bugs. > > > > > > While I can understand the position here - and robustness is always good > - > > I do not believe this is wise or prudent advice, especially from this > > incident. While it is true that post-issuance may catch things > pre-issuance > > misses, the value in post-issuance is both as a means of ensuring that > > internal records are consistent (i.e. that the set of pre-issuance > > certificates match what was issued - ensuring no rogue or unauthorized > > certificates) as well as detecting if preissuance was not run. > > > > There's significant more risk for writing a second implementation "just > > because" - and far greater value in ensuring robustness. Certainly, > > post-issuance is far less important than pre-issuance. > > > > Of cause. I was not suggesting that approach (although it can be a > high reliability technique). I was merely suggesting to obtain a > cert linter from a different vendor than the main CA suite. There’s no reason to believe this is an appropriate suggestion for this incident, and certainly, not a necessary one. Such advice can easily lead to confusion and problematic designs, which is why I feel it important to point this out. And by > all means run multiple checkers that purport to check the same > things. While I realize there is a tendency to speak in the abstract here, I think it’s both valuable and appropriate to highlight that there are no such linters in the market, just as there is no “linter market” or “linter vendors”. None of the open-source projects purport to cover the same set of checks - each represents a different and complementary effort to examine different elements of the issuance pipeline. Also note that pre-issuance checking is not the same as checking CT > pre-certs. Pre-issuance checks need to happen before signing the > pre-certs. I’m not sure if you were directly this reply at me or others. I don’t believe there was any element to the replies or discussion to date that would need this clarification, not have I seen any past or present incident report that seems to have conflated these. It does seem an otherwise unnecessary clarification, even if accurate. > > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
