Seconding Amir: your Censys query is looking for the wrong thing. It's specifying two primary criteria (using your P-384 query as an example): - parsed.subject_key_info.ecdsa.length=`384`, i.e. looking for certificates whose *public key* is an ECDSA P-384 key; and - not parsed.signature.signature_algorithm.oid="1.2.840.10045.4.3.3", i.e. looking for certificates whose *signature* was *not* produced by a P-384 key.
These two facets of a certificate -- the algorithm used by the issuer, and the subject's public key -- do not have any relationship to each other. They are *often* correlated (for example, Let's Encrypt defaults to using our ECDSA intermediates to issue certificates containing ECDSA public keys), but there is no requirement to that effect. To the contrary, it is perfectly acceptable -- and from the results, clearly common -- to use an RSA intermediate to sign certificates containing ECDSA public keys, and vice versa. Aaron On Thu, May 30, 2024 at 9:23 AM 'Amir Omidi (aaomidi)' via [email protected] <[email protected]> wrote: > What this policy means is that if the signer key is: > - P-256: Then the child certificate needs to use SHA-256. > - P-384: Then the child certificate needs to use SHA-384. > > It doesn't say anything about what the signature should be based on the > child certificate's key - only the signer's key. > > For what its worth there is a zlint lint that catches this problem: > https://github.com/zmap/zlint/blob/master/v3/lints/mozilla/lint_mp_ecdsa_signature_encoding_correct.go > > On Thursday, May 30, 2024 at 12:09:05 PM UTC-4 Wayne wrote: > >> This is unusual but given the scale of this issue and multiple CAs >> involved I am making it public. I really hope there is a simple mistake in >> my analysis here. >> >> I was initially looking at the Certificate Policy of one unnamed CA and >> noticed a mismatch in their allowed curves, signatures and what they >> issued. Given I thought it was a one-off and a self-imposed limitation I >> didn't look further at the time. >> >> However in reviewing this I noticed that the Mozilla Root Policy >> <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#5-certificates> >> states the following: >> --- >> 5.1.2 ECDSA >> ... >> When a root or intermediate certificate's ECDSA key is used to produce a >> signature, *only the following algorithms MAY be used*, and with the >> following encoding requirements: >> - If the signing key is P-256, the signature MUST use ECDSA with SHA-256. >> The encoded AlgorithmIdentifier MUST match the following hex-encoded bytes: >> 300a06082a8648ce3d040302. >> - If the signing key is P-384, the signature MUST use ECDSA with SHA-384. >> The encoded AlgorithmIdentifier MUST match the following hex-encoded bytes: >> 300a06082a8648ce3d040303. >> --- >> >> There's two conditions here: 'When a root or intermediate certificate's >> ECDSA key is used to produce a signature' - I presume this means only >> intermediaries that have ECDSA keys have the signature/hash algorithm >> limitation. Note that the below research does not consider this in >> establishing scale as there isn't a simple mechanism to check for an >> intermediary's choice in algorithm on censys. >> >> Curve length must match hash length. But there's also the specificity in >> the hex-encoded bytes that a specific AlgorithmIdentifier: >> 300A06082A8648CE3D040303 - ecdsaWithSHA384, OID '1.2.840.10045.4.3.3' see >> below >> 300A06082A8648CE3D040302 - ecdsaWithSHA256, OID '1.2.840.10045.4.3.2' see >> below >> >> *For P-384 certificates that do not have a ECDSA-SHA384 signature* there >> are at least 1.8 million certificates on censys >> <https://search.censys.io/search?resource=certificates&q=%28labels%3D%22trusted%22+and+labels%3D%22precert%22+and+validation.nss.has_trusted_path%3Dtrue+and+not+labels%3D%22revoked%22%29+and+parsed.subject_key_info.ecdsa.length%3D%60384%60+and+not+parsed.signature.signature_algorithm.oid%3D%221.2.840.10045.4.3.3%22> >> . >> >> raw query: (labels="trusted" and labels="precert" and >> validation.nss.has_trusted_path=true and not labels="revoked") and >> parsed.subject_key_info.ecdsa.length=`384` and not >> parsed.signature.signature_algorithm.oid="1.2.840.10045.4.3.3" >> >> Here is a breakdown on the parsed.issuer.organization: >> --- >> Cisco Systems, Inc. - 1,751,139 >> Google Trust Services LLC - 78,412 >> nazwa.pl sp. z o.o. - 2,963 >> DigiCert Inc - 2,123 >> Deutsche Telekom Security GmbH - 441 >> IdenTrust - 300 >> GlobalSign nv-sa - 243 >> Unizeto Technologies S.A. - 180 >> Telia Finland Oyj - 148 >> Let's Encrypt - 119 >> Google Trust Services - 38 >> Trust Provider B.V. - 23 >> netart.com sp. z o.o. - 20 >> Rede Nacional de Ensino e Pesquisa - RNP - 19 >> cyber_Folks S.A. - 17 >> TrustAsia Technologies, Inc. - 13 >> Certera - 1 >> DigiCert Ireland Limited - 1 >> DigiCert, Inc. - 1 >> Microsoft Corporation - 1 >> --- >> >> *For P-256 certificates that do not have a ECDSA-SHA256 signature* there >> are at least 229k certificates on censys. >> <https://search.censys.io/search?resource=certificates&q=%28labels%3D%22trusted%22+and+labels%3D%22precert%22+and+validation.nss.has_trusted_path%3Dtrue+and+not+labels%3D%22revoked%22%29+and+parsed.subject_key_info.ecdsa.length%3D%60256%60+and+not+parsed.signature.signature_algorithm.oid%3D%221.2.840.10045.4.3.2%22> >> >> raw query: (labels="trusted" and labels="precert" and >> validation.nss.has_trusted_path=true and not labels="revoked") and >> parsed.subject_key_info.ecdsa.length=`256` and not >> parsed.signature.signature_algorithm.oid="1.2.840.10045.4.3.2" >> >> Here is a breakdown on the parsed.issuer.organization: >> --- >> Google Trust Services LLC - 133,178 >> DigiCert Inc - 31,263 >> GlobalSign nv-sa - 27,437 >> Google Trust Services - 22,569 >> Microsoft Corporation - 6,811 >> TrustAsia Technologies, Inc. - 2,278 >> SSL Corp - 1,467 >> IdenTrust - 1,335 >> Entrust, Inc. - 818 >> Let's Encrypt - 652 >> Deutsche Telekom Security GmbH - 607 >> Telia Finland Oyj - 356 >> Actalis S.p.A. - 109 >> DigiCert, Inc. - 109 >> Apple Inc. - 74 >> D-Trust GmbH - 54 >> QuoVadis Limited - 43 >> Unizeto Technologies S.A. - 36 >> Trust Provider B.V. - 19 >> CrowdStrike, Inc. - 11 >> DigiCert Ireland Limited - 11 >> Hellenic Academic and Research Institutions CA - 10 >> Verokey - 6 >> Aetna Inc - 5 >> ZeroSSL - 4 >> Chunghwa Telecom Co., Ltd. - 3 >> Rede Nacional de Ensino e Pesquisa - RNP - 3 >> Wells Fargo & Company - 2 >> Beijing Xinchacha Credit Management Co., Ltd. - 1 >> Gandi - 1 >> Hao Quang Viet Software Company Limited - 1 >> SECOM Trust Systems CO.,LTD. - 1 >> eMudhra Technologies Limited - 1 >> --- >> >> Now censys doesn't have a full scope of every certificate and I suspect >> there are more CAs impacted than this list shows. While I can see there are >> RSA intermediaries involved, there are also ECC intermediaries of at least >> the following CAs impacted: >> DigiCert, GlobalSign, Microsoft, SSL.com, TrustAsia, and Certera. >> >> ...Thoughts? >> > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/4c008353-b88e-445d-b497-3e3353ae5e87n%40mozilla.org > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/4c008353-b88e-445d-b497-3e3353ae5e87n%40mozilla.org?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErfXZJxA1UiJRpHEPLCEOkBoBhS3uoV9JbNo4LcF_A1B0w%40mail.gmail.com.
