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

Wed Apr 3 17:13:38 UTC 2024

Hi,

I like the spirit of the linters but as said in some of the emails it´s not that easy for some members (even drafting a ballot nowadays 😊) and it´s not required at all (can´t be added in a ballot something that is not a requirement). 

So, although there´s been many bugzillas indicating the lack of a specific linter update, that´s an issue in the configuration of the CA systems, that is a specific task of any CA and can´t blame on the linters. Rely on linters could be an option, an alternative, but if that´s a requirement you can create more problems. For example, you mention that Rob and Matthew are the maintainers of one linter, if there´s a problem with that linter, then someone may/will have the excuse to blame these 2 persons for not updating/changing/modifying whatever requirements and that´s the reason for their fault,etc., and IMHO that wouldn´t be fair, considering what the linters are and how they are maintained, which is in a voluntary basis.

I think that linters are good tools to help but not de-facto ones and, in any case, it has to be clear that the latest and only responsible for any mis-issuance is the CA itself.

Regards

De: Servercert-wg <servercert-wg-bounces at cabforum.org> En nombre de Aaron Gable via Servercert-wg
Enviado el: martes, 2 de abril de 2024 20:45
Para: Ryan Dickson <ryandickson at google.com>
CC: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Asunto: Re: [Servercert-wg] Fixing lag between requirements changes and linter updates

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

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 <mailto: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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcertlint%2Fcertlint&data=05%7C02%7Cinigo.barreira%40sectigo.com%7Cfd917408367f452440fc08dc5344fc79%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638476802971171709%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=3Ini2ROBfJNv4BCEB7feBqGUXQbx0GrYy0UEElw4fd8%3D&reserved=0>  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 <mailto: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  <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcabforum.org%2Fworking-groups%2Fserver%2Fcharter%2F&data=05%7C02%7Cinigo.barreira%40sectigo.com%7Cfd917408367f452440fc08dc5344fc79%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638476802971196081%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Scv%2F3ia6UlrnxAub%2Bqe8SPOOcbop8oltitPRAUwyTEY%3D&reserved=0> 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/20240403/d024025b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6630 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240403/d024025b/attachment-0001.p7s>