[Servercert-wg] Fixing lag between requirements changes and linter updates

[Aaron Gable]

Thank you both for the thoughts and feedback! I agree that it shouldn't be
a requirement; I mostly included that option just to mark the extreme end
of the possibility space we're working in. Additional replies inline below:

On Tue, Apr 2, 2024 at 12:38 AM Martijn Katerbarg <
martijn.katerbarg at sectigo.com> wrote:

>
>    - We could likewise update the default ballot text template to
>    incorporate a line such as: “The following lints are being prepared to
>    accommodate these ballot requirements”, alternative “No lints are yet being
>    prepared for these changes. The author and endorsers are looking for
>    volunteers to help in this effort”.
>
>
I like the idea of this being included in the default ballot template. Easy
for an author to remove if they believe it is not relevant, and a simple
reminder for those ballots for which it would be appropriate.


>
>    - We have representatives for pkilint and certlint
>    <https://github.com/certlint/certlint> vailable at the forum, so it
>    should be easily do-able to make sure that if a lint is added, they could
>    also prepare a new release prior to the ballot’s effective date. I’m not
>    sure the same applies for zlint (correct me if I’ve missed a link though).
>    We should seek co-operation with the zlint maintainers to see if releases
>    can be prepared prior to any such effective date.
>
>
I believe that both Rob Stradling (Sectigo) and Matthew McPherrin (Let's
Encrypt) are maintainers of zlint.

On Tue, Apr 2, 2024 at 6:32 AM Ryan Dickson <ryandickson at google.com> wrote:

> That said, we also think it’s important to avoid creating external
> dependencies on third-party organizations, some of which are not directly
> involved in this specific Working Group or the broader Forum, when
> considering adding new requirements to the TLS BRs - or when those
> requirements become effective. This is especially true when considering
> requirements that have real-world security implications (e.g.,
> cryptographic deprecations). Ultimately, it is each CA’s responsibility to
> adhere to the BRs - and it is not the responsibility of the SCWG, as I
> interpret the charter
> <https://cabforum.org/working-groups/server/charter/> [4], to prevent
> compliance issues.
>

I agree that adding linting requirements to the BRs is a fraught and
complex idea (albeit a good and tempting one!), and I look forward to
discussion of SC-73. But I also think that requiring CAs to run linting
software is largely orthogonal to asking ballot authors (who may be CAs or
Certificate Consumers) to include linter changes alongside their ballots. I
think that encouraging authors to contribute linter changes has many
beneficial second-order effects:
- It helps people considering the ballot know if their interpretation of
the text matches the author's interpretation of their proposed text, and
vice versa;
- It can help uncover potential conflicts between different sections of the
requirements, by noting that a certificate which passes a new lint now
fails a pre-existing one;
- It can reduce load on the maintainers of those third-party linting tools,
who likely do want to stay up-to-date with BRs changes but may not have the
bandwidth to always do so;
- And of course, for those CAs which choose to perform linting using the
tools that authors contribute to, it can help them avoid potential
compliance incidents.


>
> Further, CAs aren’t required to adopt any or all of the open-source tools
> described in Samantha and Aaron’s message. If these tools are adopted,
> there’s nothing that ensures CAs rely on the latest versions of these tools
> - or use them “correctly.” The combination of these two points is that it
> seems unlikely this effort, if pursued, will completely eliminate incidents
> related to mis-issuance. However, better (i.e., reduced incidents) should
> still be considered a good thing because it represents an opportunity for
> investment of time and resources elsewhere in an effort to more
> meaningfully improve web security.
>

Agreed, and that's all I'm hoping for here: a low-cost lever to help nudge
the whole WebPKI in the direction of better automation and fewer incidents.

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