Yes the part that threw me off was the jump from the intermediary signing key to the signature of an end-user certificate. I didn't expect a leap to that extent without requirements on RSA/ECDSA public keys given where the chain of trust breaks.
On Thursday, May 30, 2024 at 5:55:30 PM UTC+1 Aaron Gable wrote: > 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/e6fb1f49-9da7-4923-aa50-eff4bb960a5cn%40mozilla.org.
