> > > 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. On Tue, May 21, 2019 at 6:06 AM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thu, May 9, 2019 at 4:48 PM Brian Smith <br...@briansmith.org> wrote: > > > On Fri, Apr 26, 2019 at 11:39 AM Wayne Thayer <wtha...@mozilla.com> > wrote: > > > >> On Wed, Apr 24, 2019 at 10:02 AM Ryan Sleevi <r...@sleevi.com> wrote: > >> > >>> Thank you David and Ryan! This appears to me to be a reasonable > >>> improvement to our policy. > >>> > >> > >> Brian: could I ask you to review the proposed change? > >> > >> > >>> This does not, however, address the last part of what Brian proposes - > >>> which is examining if, how many, and which CAs would fail to meet these > >>> encoding requirements today, either in their roots, subordinates, or > leaf > >>> certificates. > >>> > >>> > >> While I agree that this would be useful information, for the purpose of > >> moving ahead with this policy change would it instead be reasonable to > set > >> an effective date and require certificates issued (notBefore) after that > >> date to comply, putting the burden on CAs to verify their > implementations > >> rather than relying on someone else to do that work? > >> > > > > My understanding here is that the proposed text is not imposing a new > > requirement, but more explicitly stating a requirement that is already > > imposed by the BRs. AFAICT BRs require syntactically valid X.509 > > certificates, RFC 5280 defines what's syntactically valid, RFC 5280 > defers > > to other documents about what is allowed for each algorithm identifier, > and > > this is an attempt to collect all those requirements into one spot for > > convenience. > > > > I unintentionally let this drop off my radar. > > I did some light analysis, based on analyzing simply the bytes of the cert > (i.e. without structural parsing), simply looking at whether or not one of > the prescribed sequences appears, first for SPKIs, then for signatures. > > For SPKIs, I only found a total of 9 unexpired certs, so I've just > reproduced them here: > - > > https://crt.sh/?c=ad567be233e98ac621e8b760005f37f1d7e916d73c602391771ab5f23f7af38b > - > > https://crt.sh/?c=b719593d1e625e45f42ab3d1537e0a9c7a33c0a87244e7000db61571bc0fd98b > - > > https://crt.sh/?c=541e29ce0aee8244a43b31e031208e6808a7e412d6c9cda6cd032d528ea0c690 > - > > https://crt.sh/?c=6101a94793441c3b85ac653703d62d5c65ca6457662b36ad7abd3ee43d5eec11 > - > > https://crt.sh/?c=ca304b895d0d652da1c352dbda577f7c70c5f6741758e17a919a97d063ad56c7 > - > > https://crt.sh/?c=91d876790b645196389d3c92a6b480969557192ecdd2bfeaaced6c07948d9d5c > - > > https://crt.sh/?c=96185e2fadc17a5b896338a3fcce3647b3b2f9221c61c9624814c4d37b884dbb > - > > https://crt.sh/?c=9a9ec285f834b421416e5e5ba45727deaf92adf37e76a82cdf6d45d0fba0728c > - (Revoked) > > https://crt.sh/?c=5cf9ff16c5d1e128a2082df9d290d1571c1a8f2f782bc1cacd2b0437094f0e13 > > 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. > > I haven't (yet) gone through the Signature encodings, but that should > hopefully address the SPKI concerns. Of course, I may have botched things > rather significantly in my queries, but at least sharing my data provides a > way for people to prove that :) > > > > > > It would be easier to understand if this is true if the proposed text > > cited the RFCs, like RFC 4055, that actually impose the requirements that > > result in the given encodings. > > > > Could you clarify, do you just mean adding references to each of the > example encodings (such as the above example, for the SPKI encoding)? > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
