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. > 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. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
