On Tue, Feb 19, 2019 at 11:05 PM Wayne Thayer <[email protected]> wrote:
> On Tue, Feb 19, 2019 at 10:51 AM Ryan Sleevi <[email protected]> wrote: > >> >> >> On Tue, Feb 19, 2019 at 9:56 PM Wayne Thayer <[email protected]> wrote: >> >>> Ryan, >>> >>> On Mon, Feb 18, 2019 at 4:58 PM Ryan Sleevi via dev-security-policy < >>> [email protected]> wrote: >>> >>>> On Mon, Feb 18, 2019 at 2:49 PM Jakob Bohm via dev-security-policy < >>>> [email protected]> wrote: >>>> >>>> > On 15/02/2019 19:33, Ryan Sleevi wrote: >>>> > > On Fri, Feb 15, 2019 at 12:01 PM Jakob Bohm via dev-security-policy >>>> < >>>> > > [email protected]> wrote: >>>> >>>> And by >>>> > all means run multiple checkers that purport to check the same >>>> > things. >>>> >>>> >>>> While I realize there is a tendency to speak in the abstract here, I >>>> think >>>> it’s both valuable and appropriate to highlight that there are no such >>>> linters in the market, just as there is no “linter market” or “linter >>>> vendors”. None of the open-source projects purport to cover the same >>>> set of >>>> checks - >>> >>> >>> certlint, x509lint, and zlint all detect the problem with the Izenpe >>> certificate [1]. While I realize that none of these linters perform the >>> exact same set of checks, there is significant overlap that is in no way >>> abstract. >>> >>> each represents a different and complementary effort to examine >>>> different elements of the issuance pipeline. >>>> >>>> If you are referring to certlint, x509lint, and zlint, can you explain >>> this statement? >>> >> >> Sure! certlint’s strength is that it checks ASN.1 by virtue of asn1c, and >> while it has a number of secondary checks for BR compliance, they’re not as >> aggressively present as with zlint. Zlint is extremely well documented in >> both its checks of 5280, but particularly excels in its BR compliance >> aspects - especially with compliance dates. >> >> Interesting. In my experience, both certlint and zlint do a good job of > detecting BR violations. > I should have been clearer - ZLint is more timely in its adoption of forward looking dates, and more comprehensive in how it evaluates historic certs (based on the notBefore), due to its origins in studying historic ecosystem misissuance. It also better documents the source of the compliance requirement or interpretation. That’s not to say certlint doesn’t catch those, but if you were a CA examining for, say, historic misissuance as a post-issuance lint, Zlint is far more robust. They each have strengths. > X509lint is the less mature of the three linters, but more broadly >> targeted 5280 compliance without necessarily emphasizing the BR aspect. >> >> Agree on the 5280 focus of x509lint. > > There is indeed overlap between the three, but particularly zlint and >> cablint excel in ways that the other does not. You absolutely would not >> want one pre and one post - you will miss things between them. >> >> I'm still not clear on the meaning of your statement "...examine > different elements of the issuance pipeline." It sounds like you're > recommending using multiple/all of these linters both pre- and > post-issuance, which makes sense and is what I understood Jakob to be > suggesting as well. > I don’t think Jakob’s original suggestion that elicited that reply - namely, that “it is prudent to use a different brand and implementation of the software that does post-issuance checking than the software doing pre-issuance checking” seems to be saying the same thing as what you or I are saying. It is not that you want a difference than pre- and post-, but you want to make sure you’re comprehensive. You can be comprehensive with a single linter (in the abstract), although none of the linters are at that point. It also conflates software controls on the disembodied fields - which are not to be confused with pre-issuance linting, but instead is about the CA’s implementation and design of controls themselves. Put differently, linting, whether pre-issuance (i.e. a tbsCertificate fully formed, as the majority of CAs have done) or post-issuance (with a signed certificate), is itself a check on the CAs controls and design, not a substitute or equivalent for. > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
