<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 1/6/2024 12:20 π.μ., Aaron Gable
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAEmnEregarMe4DYGaF7HmMoGNP9AuWP4NNEF4PckEdp5D6tfHw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">On Wed, May 29, 2024 at 10:57 PM Dimitris
Zacharopoulos (HARICA) via Servercert-wg <<a
href="mailto:servercert-wg@cabforum.org"
moz-do-not-send="true" class="moz-txt-link-freetext">servercert-wg@cabforum.org</a>>
wrote:<br>
</div>
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>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.<br>
<ul>
<li>"The CA SHOULD perform Linting on the corpus of its
non-expired, non-revoked Subscriber Certificates
whenever it updates the Linting software".<br>
</li>
</ul>
What do people think about these proposals?<br>
</div>
</blockquote>
<div><br>
</div>
<div>Just chiming in to say that I don't love this proposal,
for a few reasons.</div>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:CAEmnEregarMe4DYGaF7HmMoGNP9AuWP4NNEF4PckEdp5D6tfHw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>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 <i>four years</i>.
I'm sure there are speedups to be had, but they'd have to be
several orders of magnitude to make that feasible.</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:CAEmnEregarMe4DYGaF7HmMoGNP9AuWP4NNEF4PckEdp5D6tfHw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>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.</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
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?<br>
<br>
<br>
Dimitris.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CAEmnEregarMe4DYGaF7HmMoGNP9AuWP4NNEF4PckEdp5D6tfHw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>Thanks,</div>
<div>Aaron</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>