[framework] Remove support for secp192[k|r]1 curves #242

valeriosetti · 2025-11-28T10:01:47Z

Description

This is a prerequisite for Mbed-TLS/TF-PSA-Crypto#570

PR checklist

TF-PSA-Crypto PR provided Remove support for secp192[k|r]1 curves TF-PSA-Crypto#570
development PR provided [mbedtls] Remove support for secp192[k|r]1 curves (part 2) mbedtls#10522
3.6 PR not required because: no backport

davidhorstmann-arm

Just one question re server11.key, but mostly looks good otherwise.

Thanks for doing this the 'right' way as it will really help us out in the future!

data_files/server11.key

gilles-peskine-arm · 2025-11-28T15:11:30Z

I recently made an incompatible change in TF-PSA-Crypto (moving crypto_adjust_config_synonyms) that requires a framework change. Sorry. You'll need to rebase your framework branch.

This is basically identical to "server3.crt", i.e. it contains an EC public key and it's signed by a RSA one. The difference is that in this case we're using a secp256r1 EC key, instead of the secp192r1 that was used in "server3.crt". Signed-off-by: Valerio Setti <[email protected]>

davidhorstmann-arm

I'm very sorry to ask, but would you mind updating the middle commit message? It says that the new key is secp192k1 rather than secp256k1, which is incorrect (and one of the things we're trying to remove so fairly confusing).

I'm happy with it otherwise and the rebase should not change any content so should be quick to re-review.

This is a secp256k1 EC key. The goal is to use it in tests where a key that does not belong to the "suite-b" list is required. For example it can be used as counterpart of "server5.key" since this one is secp256r1 and this curve type belong to "suite-b". Signed-off-by: Valerio Setti <[email protected]>

This is almost identical to "server5-rsa-signed.crt" in the sense that it includes an EC public key and it's signed with an RSA one. The main difference compared to "server5-rsa-signed.crt" is that in this case we're using a secp256k1 key, instead the companion one uses a secp256r1. The important thing here is that the "k1" type does not belong to "suite-b", while "r1" does. Signed-off-by: Valerio Setti <[email protected]>

valeriosetti · 2025-11-28T16:45:53Z

I'm very sorry to ask, but would you mind updating the middle commit message?

No problem at all, that sentence was totally misleading indeed. It's fixed now :)

davidhorstmann-arm

LGTM, thanks!

mpg

Got a few questions.

I haven't check the files yet, I'll keep that for the next round (in case some of them get re-generated in the meantime).

data_files/Makefile

mpg · 2025-12-02T08:50:24Z

data_files/Makefile

+	$(MBEDTLS_CERT_WRITE) subject_key=$< subject_name="C=NL,O=PolarSSL,CN=localhost" serial=13 \
+		issuer_crt=$(test_ca_crt) issuer_key=$(test_ca_key_file_rsa) issuer_pwd=$(test_ca_pwd_rsa) \
+		not_before=20190210144406 not_after=20290210144406 \
+		md=SHA1 version=3 output_file=$@


Unsure: on one hand, I understand the desire to generate certificates that are as close as possible to the originals, on the other hand, it hurts a bit to still generate new certs using SHA1 in 2025 (that is, 8 years after shattered) - even for testing (unless of course testing SHA1 is the goal, which I don't think it is here?).

(Similarly conflicted thoughts about the date range: 20290201 is a bit more that 3 years from now.)

Right, also in this case I tried to keep as close as possible to what was there before, but I don't see any problem in changing the SHA algorithm or dates

Ok. That means the test using server11.crt will probably need updating expected flags to remove BAD_MD then. Actually, if the sole purpose of server11.crt is to be rejected by each test that's using it, then it would make sense to keep it using SHA1. You probably have a better view than me of whether that's the case. Wdyt?

(And sorry for making opposite suggestions just 1h apart.)

For dates, I'd generally encourage to either use the same scripts/configs we already have (which should give 10 years), or increase the lifetime if you can be bothered. (Though arguably going past 1970 + 2^31 seconds in 2038 could cause problems on 32-bit systems — that's something we aren't testing thoroughly yet.) There's usually no reason to keep the dates of existing test data unless the test is specifically related to dates (e.g. testing an expired cert, or testing Y2K or Y2038).

For hashes I'd generally encourage to use SHA-256 for maximum configuration coverage. (Unless of course there's a reason to use a specific hash.) Changing the hash is usually not a problem except that you have to update dependencies accordingly, but it can be harder if what you're changing is itself signed and there are tests with restrictive policies. But I think we generally don't have policies in tests that forbid SHA-256 unless we're specifically testing hash policies.

That means the test using server11.crt will probably need updating expected flags to remove BAD_MD then. Actually, if the sole purpose of server11.crt is to be rejected by each test that's using it, then it would make sense to keep it using SHA1. You probably have a better view than me of whether that's the case. Wdyt?

Yes, this is correct. Indeed SHA-256 is allowed by suite-b, so BAD_MD is no more set as failure flag. I will go back to SHA-1 for this specific certificate (but I will keep SHA-256 for the other one).

davidhorstmann-arm

LGTM, thanks!

Whoops, jumped the gun - I'll wait for the update back to SHA-1

- use SHA-256 instead of SHA-1 for "server5-rsa-signed.crt". This change is not applied to "server11.crt" because the goal there is to have as many features as possible which are _not_ part of suite-b (and SHA-1 is not part of it). - move start/end dates forward so that certificates are valid for the next 10 years. Signed-off-by: Valerio Setti <[email protected]>

davidhorstmann-arm

LGTM, thanks!

mpg

Thanks for addressing my comments! I've also checked that the files match what's expected from the Makefile. LGTM!

valeriosetti added needs-review Every commit must be reviewed by at least two team members, needs-ci Needs to pass CI tests needs-reviewer This PR needs someone to pick it up for review size-s Estimated task size: small (~2d) priority-high High priority - will be reviewed soon labels Nov 28, 2025

valeriosetti added this to Roadmap pull requests (new board) Nov 28, 2025

github-project-automation bot moved this to In Development in Roadmap pull requests (new board) Nov 28, 2025

This was referenced Nov 28, 2025

Remove support for secp192[k|r]1 curves Mbed-TLS/TF-PSA-Crypto#570

Open

[mbedtls] Remove support for secp192[k|r]1 curves (part 2) Mbed-TLS/mbedtls#10522

Open

davidhorstmann-arm requested changes Nov 28, 2025

View reviewed changes

data_files/server11.key Show resolved Hide resolved

valeriosetti force-pushed the issue568-framework branch from 8338ee0 to ca68004 Compare November 28, 2025 15:29

valeriosetti requested a review from davidhorstmann-arm November 28, 2025 15:30

valeriosetti force-pushed the issue568-framework branch from ca68004 to f7d3257 Compare November 28, 2025 15:38

davidhorstmann-arm requested changes Nov 28, 2025

View reviewed changes

valeriosetti added 2 commits November 28, 2025 17:44

valeriosetti force-pushed the issue568-framework branch from f7d3257 to 85cbd7a Compare November 28, 2025 16:44

valeriosetti requested a review from davidhorstmann-arm November 28, 2025 16:46

davidhorstmann-arm previously approved these changes Nov 28, 2025

View reviewed changes

valeriosetti removed the needs-ci Needs to pass CI tests label Dec 1, 2025

mpg self-requested a review December 1, 2025 11:40

mpg removed the needs-reviewer This PR needs someone to pick it up for review label Dec 1, 2025

mpg reviewed Dec 2, 2025

View reviewed changes

valeriosetti dismissed davidhorstmann-arm’s stale review via 03ce50b December 2, 2025 09:39

valeriosetti requested a review from mpg December 2, 2025 09:40

davidhorstmann-arm previously approved these changes Dec 2, 2025

View reviewed changes

valeriosetti force-pushed the issue568-framework branch from 03ce50b to 3a682fe Compare December 2, 2025 11:45

davidhorstmann-arm approved these changes Dec 2, 2025

View reviewed changes

mpg approved these changes Dec 2, 2025

View reviewed changes

github-project-automation bot moved this from In Development to Has Approval in Roadmap pull requests (new board) Dec 2, 2025

mpg added approved Design and code approved - may be waiting for CI or backports and removed needs-review Every commit must be reviewed by at least two team members, labels Dec 2, 2025

davidhorstmann-arm added the needs-ci Needs to pass CI tests label Dec 2, 2025

valeriosetti merged commit f58263d into Mbed-TLS:main Dec 2, 2025
2 checks passed

github-project-automation bot moved this from Has Approval to Done in Roadmap pull requests (new board) Dec 2, 2025

valeriosetti removed the needs-ci Needs to pass CI tests label Dec 2, 2025

[framework] Remove support for secp192[k|r]1 curves #242

[framework] Remove support for secp192[k|r]1 curves #242

Conversation

valeriosetti commented Nov 28, 2025 • edited by mpg Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

PR checklist

Uh oh!

davidhorstmann-arm left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

gilles-peskine-arm commented Nov 28, 2025

Uh oh!

davidhorstmann-arm left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

valeriosetti commented Nov 28, 2025

Uh oh!

davidhorstmann-arm left a comment

Choose a reason for hiding this comment

Uh oh!

mpg left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

mpg Dec 2, 2025

Choose a reason for hiding this comment

Uh oh!

valeriosetti Dec 2, 2025

Choose a reason for hiding this comment

Uh oh!

mpg Dec 2, 2025

Choose a reason for hiding this comment

Uh oh!

gilles-peskine-arm Dec 2, 2025

Choose a reason for hiding this comment

Uh oh!

valeriosetti Dec 2, 2025

Choose a reason for hiding this comment

Uh oh!

davidhorstmann-arm left a comment

Choose a reason for hiding this comment

Uh oh!

davidhorstmann-arm left a comment

Choose a reason for hiding this comment

Uh oh!

mpg left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

valeriosetti commented Nov 28, 2025 •

edited by mpg

Loading

davidhorstmann-arm left a comment •

edited

Loading