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