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.

>> 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.  And by 
all means run multiple checkers that purport to check the same 
things.

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.


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

Reply via email to