> Note that this is applicable for signatureAlgorithms as well (and the same > section of the RFC), and this is again something cablint picks up and zlint > misses. However, it seems CAs happened to already have revoked these > certificates - perhaps from internal linting efforts that looked at all > their certificates, or crt.sh, or some other bit. It's also not too > surprising, given that this is the logic that mozilla::pkix implements > directly in its implementation.
I'd love to see another CA with greater development resources volunteer the time to implement the signatureAlgorithms coverage for zlint. I suspect there are a number of CAs using zlint that aren't represented in the repository contributor graph. So I'm fairly confident that the increased expression in policy does not > harm things, makes it easier to implement safe linters. Not to pick on > Daniel, but it looks like the PR made for zlint missed some edge corner > cases - perfectly understandable, in context, but exactly why/where the > direct comparison makes it easier :) :-) I should have known better than to think anything related to ASN.1 could be a quick PR. I'll work on integrating your feedback. Thanks again for taking the time to review it. On Wed, May 22, 2019 at 12:25 AM Ryan Sleevi <r...@sleevi.com> wrote: > > > On Tue, May 21, 2019 at 3:32 PM Daniel McCarney <c...@letsencrypt.org> > wrote: > >> >>> Of the 8 unrevoked, they're all issued by a single CA - GlobalSign - and >>> are all RSA keys that lack the explicit NULL parameter, and thus violate >>> the requirements of https://tools.ietf.org/html/rfc3279#section-2.3.1 >> >> >>> These are flagged by cablint (but not zlint), so that is an opportunity >>> for >>> CAs to improve things - both in how they encode and how they lint. >> >> >> Ryan: Thanks for flagging this difference between cablint and zlint. >> >> Let's Encrypt uses zlint and so I took some time today to submit a PR to >> address this missing lint finding: https://github.com/zmap/zlint/pull/285 >> Extra >> eyes on that would be most welcome. >> > > Thanks. I left some comments, and also spent some time digging into the > signature algorithm encodings. > > Using an algorithm that undercounts (meaning if they got it right in the > SPKI, but botched it in the signature, or vice-versa, I'm not counting it), > I still only found 415 certificates. I sampled around 40 of these, and they > were all revoked, and all fell into the class of RSA omitting the NULL. > > Note that this is applicable for signatureAlgorithms as well (and the same > section of the RFC), and this is again something cablint picks up and zlint > misses. However, it seems CAs happened to already have revoked these > certificates - perhaps from internal linting efforts that looked at all > their certificates, or crt.sh, or some other bit. It's also not too > surprising, given that this is the logic that mozilla::pkix implements > directly in its implementation. > > So I'm fairly confident that the increased expression in policy does not > harm things, makes it easier to implement safe linters. Not to pick on > Daniel, but it looks like the PR made for zlint missed some edge corner > cases - perfectly understandable, in context, but exactly why/where the > direct comparison makes it easier :) > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
