[Servercert-wg] Ballot SC-75 - Pre-sign linting

[Dimitris Zacharopoulos (HARICA)]

On 1/6/2024 12:20 π.μ., Aaron Gable wrote:
> On Wed, May 29, 2024 at 10:57 PM Dimitris Zacharopoulos (HARICA) via 
> Servercert-wg <servercert-wg at cabforum.org> wrote:
>
>     While we're in this vein, it would also be useful to add a
>     recommendation for CAs to lint all non-expired, non-revoked
>     certificates whenever they install an update of their linting
>     software.
>
>       * "The CA SHOULD perform Linting on the corpus of its
>         non-expired, non-revoked Subscriber Certificates whenever it
>         updates the Linting software".
>
>     What do people think about these proposals?
>
>
> Just chiming in to say that I don't love this proposal, for a few reasons.
>
> 1. Linting software has not always had a great track record of 
> applying new lints (based on new requirements) only to certificates 
> issued after a certain date. Running a new linting tool over old 
> certificates frequently raises warnings or errors which were not 
> actually errors at the time of issuance. Zlint has support for this 
> behavior, but it is not used consistently across all lints in their 
> corpus. A quick glance at pkilint's source does not seem to show any 
> support for this behavior, but I easily could be wrong.

Linters can be expected to throw false positives and it's the CA's 
responsibility to interpret those results properly. Linting the 
non-expired, non-revoked certificates is usually a "one-off" task 
(linting software is usually not updated so frequently) and if the CA 
decides that a certain lint is a false positive, it could be excluded 
for that run. In most cases though, updated linters may catch past 
compliance matters and mis-issuances that are correctly detected and 
reported. It's always best to risk some false positives (which you can 
document and move on) than to risk missing real misissuances which will 
ultimately be revealed by third parties scanning the CT logs.

>
> 2. Some CAs have very large certificate corpuses, e.g. Let's Encrypt 
> has 400 million currently-valid certificates. Some linting tools are 
> very slow, e.g. pkilint's `lint_pkix_cert` takes 300ms per run. At 
> that rate, re-linting LE's whole corpus would take /four years/. I'm 
> sure there are speedups to be had, but they'd have to be several 
> orders of magnitude to make that feasible.

I believe this is a valid case for CAs that have large certificate 
volumes and linting every single currently-valid certificate is not a 
viable option, which is why this is a SHOULD requirement. Even so, based 
on audit methodologies, LE and other CAs with such large volumes could 
perform sampling and pick a smaller number of certificates for linting 
during the linter update.

>
> 3. Any large systems engineer knows that streaming processing and 
> batch processing infrastructure are very different, with wholly 
> different software and hardware setups to make each efficient. I think 
> it is much more important to incentivize stream-linting (i.e. as 
> issuance happens), and that it would be counterproductive to require 
> CAs to invest in both at the same time.

I'm probably thinking about this a bit differently because linting can 
be executed in multiple ways. It's the same software that can be 
executed in the issuance pipeline (pre-sign linting) and after the 
issuance pipeline (post-sign linting). In the latter case, it can be 
executed in batch mode that checks multiple certificates. The ballot 
certainly puts more weight on the stream-linting process but also 
recommends post-sign linting, at least when the linting software gets 
updated. I believe this is a good balance that puts all the expectations 
of using linting tools in the BRs.

Do people have strong feelings against RECOMMENDing linting of 
currently-valid certificates when linting software gets updated, with a 
threshold of 90 days after the update of the linting software?


Dimitris.


>
> Thanks,
> Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240603/bf5e6c7c/attachment.html>