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@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
_______________________________________________
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg
