<div dir="ltr"><div dir="ltr"><div>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:</div></div><div><br></div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 2, 2024 at 12:38 AM Martijn Katerbarg <<a href="mailto:martijn.katerbarg@sectigo.com">martijn.katerbarg@sectigo.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg1414605967691436545"><div lang="en-SE" style="overflow-wrap: break-word;"><div class="m_1414605967691436545WordSection1"><ul type="disc" style="margin-top:0cm"><li class="m_1414605967691436545MsoListParagraph" style="margin-left:0cm"><span style="font-size:11pt">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”.</span></li></ul></div></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg1414605967691436545"><div lang="en-SE" style="overflow-wrap: break-word;"><div class="m_1414605967691436545WordSection1"><ul type="disc" style="margin-top:0cm"><li class="m_1414605967691436545MsoListParagraph" style="margin-left:0cm"><span style="font-size:11pt">We have representatives for pkilint and <a href="https://github.com/certlint/certlint" target="_blank">certlint</a> 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.</span></li></ul></div></div></div></blockquote><div><br></div><div>I believe that both Rob Stradling (Sectigo) and Matthew McPherrin (Let's Encrypt) are maintainers of zlint.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 2, 2024 at 6:32 AM Ryan Dickson <<a href="mailto:ryandickson@google.com">ryandickson@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span id="m_6655173131044780482gmail-docs-internal-guid-9901fdd8-7fff-e324-83ab-cdcfe641e138"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="background-color:transparent;font-family:Arial,sans-serif;color:rgb(0,0,0);font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">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 </span><a href="https://cabforum.org/working-groups/server/charter/" target="_blank" style="text-decoration-line:none"><span style="font-family:Arial,sans-serif;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;text-decoration-line:underline;vertical-align:baseline">charter</span></a><span style="background-color:transparent;font-family:Arial,sans-serif;color:rgb(0,0,0);font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"> [4], to prevent compliance issues.</span><br></p></span></div></blockquote><div><br></div><div>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:</div><div>- 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;</div><div>- 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;</div><div>- 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;</div><div>- 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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span id="m_6655173131044780482gmail-docs-internal-guid-9901fdd8-7fff-e324-83ab-cdcfe641e138"><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">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.</span></p></span></div></blockquote><div><br></div><div>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.</div><div><br></div><div>Thanks again,</div><div>Aaron</div></div></div>