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
