GlobalSign has revoked the respective certificates and is investigating root cause. Thanks.
> -----Original Message----- > From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> On > Behalf Of Ryan Sleevi via dev-security-policy > Sent: dinsdag 21 mei 2019 6:06 > To: Brian Smith <br...@briansmith.org> > Cc: Ryan Sleevi <r...@sleevi.com>; mozilla-dev-security-policy <mozilla-dev- > security-pol...@lists.mozilla.org>; Wayne Thayer <wtha...@mozilla.com> > Subject: Re: Policy 2.7 Proposal: Clarify Section 5.1 ECDSA Curve-Hash > Requirements > > 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=ad567be233e98ac621e8b760005f37f1d7e916d73c602391771ab5f2 > 3f7af38b > - > https://crt.sh/?c=b719593d1e625e45f42ab3d1537e0a9c7a33c0a87244e7000db6157 > 1bc0fd98b > - > https://crt.sh/?c=541e29ce0aee8244a43b31e031208e6808a7e412d6c9cda6cd032d5 > 28ea0c690 > - > https://crt.sh/?c=6101a94793441c3b85ac653703d62d5c65ca6457662b36ad7abd3ee > 43d5eec11 > - > https://crt.sh/?c=ca304b895d0d652da1c352dbda577f7c70c5f6741758e17a919a97d > 063ad56c7 > - > https://crt.sh/?c=91d876790b645196389d3c92a6b480969557192ecdd2bfeaaced6c0 > 7948d9d5c > - > https://crt.sh/?c=96185e2fadc17a5b896338a3fcce3647b3b2f9221c61c9624814c4d3 > 7b884dbb > - > https://crt.sh/?c=9a9ec285f834b421416e5e5ba45727deaf92adf37e76a82cdf6d45d0 > fba0728c > - (Revoked) > https://crt.sh/?c=5cf9ff16c5d1e128a2082df9d290d1571c1a8f2f782bc1cacd2b0437 > 094f0e13 > > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
