Mozilla Root Policy: ECC Curves and Signature Length (Mass Certificate Problem Report)

[Wayne]

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 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.

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.

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?

[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

[Aaron Gable]

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

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
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.

[Wayne]

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.

[Aaron Gable]

On Thu, May 30, 2024 at 9:58 AM Wayne <rdau...@gmail.com> wrote:

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.

I'm not sure I follow; can you clarify what you mean by this?

There are two requirements here:

- An issuing keypair of a given type (e.g. "RSA 4096", or "ECDSA P-384") must always use a specific signing algorithm correlated with that key type (e.g. "RSASSA-PKCS1-v1_5 with SHA-256", or "ECDSA with SHA-384", respectively); and

- A specific signing algorithm (e.g. "RSASSA-PKCS1-v1_5 with SHA-256", or "ECDSA with SHA-384") must always have a particular DER encoding (e.g. "300d06092a864886f70d01010b0500", or "300a06082a8648ce3d040303", respectively) in the resulting certificate's signatureAlgorithm.AlgorithmIdentifier field and tbsCertficiate.signature field.

This chain of logic -- specific signing keys must use specific signing algorithms, and specific signing algorithms must be represented with specific encodings -- doesn't seem to have a "jump" to me, so I think I must be misunderstanding your statement?

Thanks,

Aaron

[Wayne]

For the issuing keypair I didn't expect that it must always use a specific signing algorithm in this regard. The leap that I mean is a requirement on signing based off of the algorithm of the keypair. I agree that is what the policy says.

That is also why the censys queries are crafted as you saw, I expected any algorithm choices to be more constrained, i.e. RSA intermediary must issue RSA certs, ECDSA intermediary must issue ECDSA certs. There there isn't a limitation that but an explicit choice in signing makes me wonder what the security guarantees were intended to be.

We currently have RSA-2048 intermediaries that are publishing P-384 certificates that are held to a lower standard than a P-256 intermediary doing the same. You can understand my surprise here I hope? I simply didn't expect the keypair and signing algorithm to apply to child certificates in this manner.

[Aaron Gable]

I think there's still some confusion here.

On Thu, May 30, 2024 at 10:23 AM Wayne <rdau...@gmail.com> wrote:

That is also why the censys queries are crafted as you saw, I expected any algorithm choices to be more constrained, i.e. RSA intermediary must issue RSA certs, ECDSA intermediary must issue ECDSA certs. There there isn't a limitation that but an explicit choice in signing makes me wonder what the security guarantees were intended to be.

There is no choice in signing[1]. The signing algorithm used by the CA is determined by that CA's keypair. What there is is a choice (made by the subscriber, not by the CA!) of what kind of public key to submit in the CSR.

Imagine a classic, very simple CA. They have one RSA 4096 root, and one RSA 2048 intermediate. Every signature they produce will be sha256WithRSAEncryption, and every certificate they issue will encode that signatureAlgorithm using OID 1.2.840.113549.1.1.11. What should they do when an applicant submits an ECDSA P-384 public key in a CSR? Should they be forbidden from issuing that certificate? What security benefit would there be to refusing such a request?

 

Footnote [1]: Yes, there is some choice in the signing algorithm for RSA issuers, but that choice is still limited and there is no choice for ECDSA issuers.

We currently have RSA-2048 intermediaries that are publishing P-384 certificates that are held to a lower standard than a P-256 intermediary doing the same. You can understand my surprise here I hope? I simply didn't expect the keypair and signing algorithm to apply to child certificates in this manner.

Allow me to expand this sentence a little bit: "We currently have RSA-2048 intermediates using the sha256WithRSAEncryption signature algorithm to sign certificates containing ECDSA P-384 public keys. These certificates have lower cryptographic security than if they were issued from an ECDSA P-384 intermediate using the ecdsa-with-SHA384 algorithm." Is that an accurate understanding of what you mean by "held to a lower standard"?

But then I could say something similar: "These certificates have lower cryptographic security than if they were issued from an RSA 4096 intermediate using the sha512WithRSAEncryption signature algorithm." There's nothing special about the switch from RSA to ECDSA in your example; there are always ways in which the security could be improved, but they all come with tradeoffs such as certificate size or validation time.

At the end of the day, the public key submitted by the applicant/subscriber in their CSR doesn't matter. Yes, CAs are required to do a number of checks on that key -- ensuring it isn't known to be compromised or easily factored, for example -- but there is no security benefit to correlating the subscriber's keypair type with the issuer's keypair type (and therefore the issuer's signing algorithm).

Aaron

[Yu Rollin]

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.