Agreed with Amir, if the public key of the issuer certificate is ECDSA P-384, then the signed certificate 's signing algorithm must be ECDSA with SHA-384. However, the public key of the signed certificate can be P-256, P-384, or even RSA.
在2024年5月31日星期五 UTC+8 00:23:43<Amir Omidi (aaomidi)> 写道： > 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/9b263bcf-38f5-49bf-8677-907af73c624cn%40mozilla.org.
