Re: Policy 2.7 Proposal: Clarify Section 5.1 ECDSA Curve-Hash Requirements
Ryan Sleevi wrote: > > >> 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)? > Exactly. That way, it is clear that the given encodings are not imposing a new requirement, and it would be clear which standard is being used to determine to correct encoding. I realize that determining the encoding from each of these cited specs would require understanding more specifications, including in particular how ASN.1 DER requires DEFAULT values to be encoded. I would advise against calling out all of these details individually less people get confused by inevitable omissions. Cheers, Brian -- https://briansmith.org/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7 Proposal: Clarify Section 5.1 ECDSA Curve-Hash Requirements
> 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 wrote: > > > On Tue, May 21, 2019 at 3:32 PM Daniel McCarney > 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
RE: Policy 2.7 Proposal: Clarify Section 5.1 ECDSA Curve-Hash Requirements
GlobalSign has revoked the respective certificates and is investigating root cause. Thanks. > -Original Message- > From: dev-security-policy On > Behalf Of Ryan Sleevi via dev-security-policy > Sent: dinsdag 21 mei 2019 6:06 > To: Brian Smith > Cc: Ryan Sleevi ; mozilla-dev-security-policy security-pol...@lists.mozilla.org>; Wayne Thayer > 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 wrote: > > > On Fri, Apr 26, 2019 at 11:39 AM Wayne Thayer wrote: > > > >> On Wed, Apr 24, 2019 at 10:02 AM Ryan Sleevi 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
