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

[Corey Bonnell]

*	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.

 

In addition to these points, maintaining accuracy of the evolution of requirements changes incurs a rather significant increase in software complexity. None of the linter projects suffer from an excess of engineering resources, so I think that the limited available resources should first be spent on ensuring that linters are up to date with the current requirements and adding new features. Maintaining fidelity with historical versions of the requirements is a “nice-to-have” but not needed, in my opinion. For this reason, support for (in)effective dates of requirements was not introduced to pkilint until support for SC-72 was added.

 

*	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.

 

The vast majority of that 300ms is spent spinning up the linter process, so there are major performance gains to be had by running the linter as a server where the startup cost is incurred only once and not for every certificate. This approach is taken by KeyFactor’s “Lint Eastwood” project, Sectigo’s pkimetal, and the pkilint REST API. Nonetheless, I agree that recommending re-linting the corpus of all valid certificates on every linter release is potentially resource intensive and may not yield any useful results due to the reasons outlined above about maintaining historical fidelity of requirements changes.

 

Thanks,

Corey

 

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Aaron Gable via Servercert-wg
Sent: Friday, May 31, 2024 5:20 PM
To: Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] Ballot SC-75 - Pre-sign linting

 

On Wed, May 29, 2024 at 10:57 PM Dimitris Zacharopoulos (HARICA) via Servercert-wg <servercert-wg at cabforum.org <mailto: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.

 

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.

 

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.

 

Thanks,

Aaron

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240601/9f745811/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5231 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240601/9f745811/attachment-0001.p7s>