chore: use rcgen and rustls-webpki k256-enabled forks from Zama org

[mkmks]

Description of changes

KMS nodes sign the CA certificates (that are used to issue ephemeral mTLS certificates) with their ECDSA+secp256k1 signing keys. rustls doesn't support the secp256k1 curve out of the box (although the underlying aws_lc_rs library does), and we had to fork the rcgen and rustls-webpki to enable it.

Initially, the forks were hosted under my (@mkmks) Github account because the whole idea was experimental and not certain to go to production. Now, that mTLS with core signing key-derived identities is in production, and fork upstreaming run into obstacles, a better practice would be to host the forks under the Zama Github organisation.

This PR does exactly that.

NB: The rustls-webpki version is stabilized at 0.103.7 in the fork because its 0.104 release has breaking architectural changes. These changes aren't final, so it wouldn't make a lot of sense to attempt to rebase our secp256k1-related changes on top of them.
NB2: The rcgen version is bumped to 0.14.7, and there were some API changes in the 0.14 branch (surprisingly) that required some minor changes on the KMS side.

Issue ticket number and link

Closes #240

PR Checklist

I attest that all checked items are satisfied. Any deviation is clearly justified above.

• Title follows conventional commits (e.g. chore: ...).
• Tests added for every new pub item and test coverage has not decreased.
• Public APIs and non-obvious logic documented; unfinished work marked as TODO(#issue).
• unwrap/expect/panic only in tests or for invariant bugs (documented if present).
• No dependency version changes OR (if changed) only minimal required fixes.
• No architectural protocol changes OR linked spec PR/issue provided.
• No breaking deployment config changes OR devops label + infra notified + infra-team reviewer assigned.
• No breaking gRPC / serialized data changes OR commit marked with ! and affected teams notified.
• No modifications to existing versionized structs OR backward compatibility tests updated.
• No critical business logic / crypto changes OR ≥2 reviewers assigned.
• No new sensitive data fields added OR Zeroize + ZeroizeOnDrop implemented.
• No new public storage data OR data is verifiable (signature / digest).
• No unsafe; if unavoidable: minimal, justified, documented, and test/fuzz covered.
• Strongly typed boundaries: typed inputs validated at the edge; no untyped values or errors cross modules.
• Self-review completed.

[github-actions]

Consolidated Tests Results 2026-03-19 - 16:53:32

Test Results

11 passed

Details

11 tests
not captured
junit-to-ctrf
build-and-test test-reporter #888
chore: use rcgen and rustls-webpki k256-enabled forks from Zama org #437

test-reporter: Run #888

Tests 📝	Passed ✅	Failed ❌	Skipped ⏭️	Pending ⏳	Other ❓	Flaky 🍂	Duration ⏱️
11	11	0	0	0	0	0	not captured

🎉 All tests passed!

Tests

View All Tests

Test Name	Status	Flaky	Duration
nightly_full_gen_tests_k8s_default_threshld_sequential_crs	✅		33.0s
test_k8s_threshld_insecure	✅		3m 15s
k8s_test_crs_uniqueness	✅		33.0s
k8s_test_insecure_keygen_encrypt_and_public_decrypt	✅		3m 18s
k8s_test_insecure_keygen_encrypt_multiple_types	✅		3m 38s
k8s_test_keygen_and_crs	✅		3m 15s
k8s_test_keygen_uniqueness	✅		8m 54s
nightly_full_gen_tests_k8s_default_centralzd_sequential_crs	✅		1.8s
test_k8s_centralzd_insecure	✅		2m 53s
k8s_test_centralized_insecure	✅		1m 1s
nightly_full_gen_tests_default_k8s_centralized_sequential_crs	✅		1.8s

_{🍂 No flaky tests in this run.}

Github Test Reporter by CTRF 💚

🔄 This comment has been updated

[dd23]

This looks good to me, but I guess for TLS-related code we should have a 2nd pair of eyes as well.

[Copilot]

Pull request overview

This PR successfully migrates TLS-related library forks from a personal GitHub account (mkmks) to the official Zama organization, addressing a critical security concern. The changes also reduce the number of forked dependencies by eliminating patches for rustls, rustls-pki-types, and tokio-rustls, which now use standard versions from crates.io. Additionally, rcgen is updated from 0.14.0 to 0.14.7, requiring API adaptations throughout the codebase.

Changes:

• Migrated rcgen and rustls-webpki forks from mkmks/github to zama-ai/github for better organizational ownership and security
• Removed unnecessary patches for rustls, rustls-pki-types, and tokio-rustls (now using standard crates.io versions)
• Updated rcgen from 0.14.0 to 0.14.7 and adapted code to use the new Issuer API pattern for certificate signing

Reviewed changes

Copilot reviewed 6 out of 7 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
Cargo.toml	Updated patch.crates-io section to point rcgen and rustls-webpki to Zama organization forks; removed rustls, rustls-pki-types, and tokio-rustls patches; bumped rcgen to 0.14.7 and rustls-webpki to 0.103.7
Cargo.lock	Reflects dependency updates with rustls 0.23.36 from crates.io instead of fork; rcgen 0.14.7 and rustls-webpki 0.103.7 from Zama forks; various transitive dependency updates
core/threshold/src/tls_certs.rs	Refactored certificate signing to use rcgen 0.14.7 Issuer API; updated create_ca_cert_from_signing_key signature to be generic over SigningKey trait; consolidated and simplified tests
core/service/src/util/key_setup/mod.rs	Adapted CA certificate generation to use new Issuer API; moved KeyPair creation before calling create_ca_cert_from_signing_key
core/service/src/cryptography/attestation/mod.rs	Updated TLS certificate signing to use Issuer::from_ca_cert_der instead of passing CertificateParams separately
core-client/Cargo.toml	Added k256, rcgen, and tokio-rustls dependencies needed for testing infrastructure
core-client/src/mpc_context.rs	Updated test context creation to use new rcgen Issuer API pattern

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jot2re]

I just assigned @dvdplm to have a look as well. I think it would be good he also gets a bit into the TLS code :)

[dvdplm]

Overall LGTM, left some minor comments and suggestions.

[dd23]

There is a security warning regarding aws-lc-sys that is patched in v0.38.0:
https://github.com/zama-ai/kms/security/dependabot/62

Can we update this dependency in this PR while we're at it?

[github-actions]

🚀 Preview deployment is deployed in "thresholdWithEnclave" mode

You can now port-forward the kms-core to run your tests locally against the preview deployment.

Connect to the Tailscale cluster zws-dev:

tailscale configure kubeconfig tailscale-operator-zws-dev.diplodocus-boa.ts.net

Port-forward the kms-core services to run your tests locally:

kubectl port-forward svc/kms-core-1-core-1 -n kms-ci-mkmks-437 50100:50100 & \
kubectl port-forward svc/kms-core-2-core-2 -n kms-ci-mkmks-437 50200:50100 & \
kubectl port-forward svc/kms-core-3-core-3 -n kms-ci-mkmks-437 50300:50100 & \
kubectl port-forward svc/kms-core-4-core-4 -n kms-ci-mkmks-437 50400:50100 &

Copy config.toml from core-client to ./core-client/config/client_local_kind_threshold.toml
⚠️ Make sure to not push this config.toml file to the repository!

kubectl cp kms-ci-mkmks-437/kms-core-client-0:/app/kms-core-client/config.toml ./core-client/config/client_local_kind_threshold.toml && \
    sed -i '' -E 's|address = "(http://)?kms-core-([0-9]+)-[^:]+:50100"|address = "http://localhost:50\200"|' ./core-client/config/client_local_kind_threshold.toml

🚀 And launch your tests:

cargo nextest run --test kubernetes_test_threshold --profile ci --no-fail-fast

You can connect to the core-client with:

kubectl exec kms-core-client-0 -n kms-ci-mkmks-437 -it -- /bin/bash

Close your port-forwarding with:

pgrep -f "kubectl port-forward" | xargs -n 1 kill

[github-actions]

🚀 Preview deployment is deployed in "thresholdWithEnclave" mode

You can now port-forward the kms-core to run your tests locally against the preview deployment.

Connect to the Tailscale cluster zws-dev:

tailscale configure kubeconfig tailscale-operator-zws-dev.diplodocus-boa.ts.net

Port-forward the kms-core services to run your tests locally:

kubectl port-forward svc/kms-core-1-core-1 -n kms-ci-mkmks-437 50100:50100 & \
kubectl port-forward svc/kms-core-2-core-2 -n kms-ci-mkmks-437 50200:50100 & \
kubectl port-forward svc/kms-core-3-core-3 -n kms-ci-mkmks-437 50300:50100 & \
kubectl port-forward svc/kms-core-4-core-4 -n kms-ci-mkmks-437 50400:50100 &

Copy config.toml from core-client to ./core-client/config/client_local_kind_threshold.toml
⚠️ Make sure to not push this config.toml file to the repository!

kubectl cp kms-ci-mkmks-437/kms-core-client-0:/app/kms-core-client/config.toml ./core-client/config/client_local_kind_threshold.toml && \
    sed -i '' -E 's|address = "(http://)?kms-core-([0-9]+)-[^:]+:50100"|address = "http://localhost:50\200"|' ./core-client/config/client_local_kind_threshold.toml

🚀 And launch your tests:

cargo nextest run --test kubernetes_test_threshold --profile ci --no-fail-fast

You can connect to the core-client with:

kubectl exec kms-core-client-0 -n kms-ci-mkmks-437 -it -- /bin/bash

Close your port-forwarding with:

pgrep -f "kubectl port-forward" | xargs -n 1 kill

[github-actions]

🚀 Preview deployment is deployed in "thresholdWithEnclave" mode

You can now port-forward the kms-core to run your tests locally against the preview deployment.

Connect to the Tailscale cluster zws-dev:

tailscale configure kubeconfig tailscale-operator-zws-dev.diplodocus-boa.ts.net

Port-forward the kms-core services to run your tests locally:

kubectl port-forward svc/kms-core-1-core-1 -n kms-ci-mkmks-437 50100:50100 & \
kubectl port-forward svc/kms-core-2-core-2 -n kms-ci-mkmks-437 50200:50100 & \
kubectl port-forward svc/kms-core-3-core-3 -n kms-ci-mkmks-437 50300:50100 & \
kubectl port-forward svc/kms-core-4-core-4 -n kms-ci-mkmks-437 50400:50100 &

Copy config.toml from core-client to ./core-client/config/client_local_kind_threshold.toml
⚠️ Make sure to not push this config.toml file to the repository!

kubectl cp kms-ci-mkmks-437/kms-core-client-0:/app/kms-core-client/config.toml ./core-client/config/client_local_kind_threshold.toml && \
    sed -i '' -E 's|address = "(http://)?kms-core-([0-9]+)-[^:]+:50100"|address = "http://localhost:50\200"|' ./core-client/config/client_local_kind_threshold.toml

🚀 And launch your tests:

cargo nextest run --test kubernetes_test_threshold --profile ci --no-fail-fast

You can connect to the core-client with:

kubectl exec kms-core-client-0 -n kms-ci-mkmks-437 -it -- /bin/bash

Close your port-forwarding with:

pgrep -f "kubectl port-forward" | xargs -n 1 kill

[github-actions]

🚀 Preview deployment is deployed in "thresholdWithEnclave" mode

You can now port-forward the kms-core to run your tests locally against the preview deployment.

Connect to the Tailscale cluster zws-dev:

tailscale configure kubeconfig tailscale-operator-zws-dev.diplodocus-boa.ts.net

Port-forward the kms-core services to run your tests locally:

kubectl port-forward svc/kms-core-1-core-1 -n kms-ci-mkmks-437 50100:50100 & \
kubectl port-forward svc/kms-core-2-core-2 -n kms-ci-mkmks-437 50200:50100 & \
kubectl port-forward svc/kms-core-3-core-3 -n kms-ci-mkmks-437 50300:50100 & \
kubectl port-forward svc/kms-core-4-core-4 -n kms-ci-mkmks-437 50400:50100 &

Copy config.toml from core-client to ./core-client/config/client_local_kind_threshold.toml
⚠️ Make sure to not push this config.toml file to the repository!

kubectl cp kms-ci-mkmks-437/kms-core-client-0:/app/kms-core-client/config.toml ./core-client/config/client_local_kind_threshold.toml && \
    sed -i '' -E 's|address = "(http://)?kms-core-([0-9]+)-[^:]+:50100"|address = "http://localhost:50\200"|' ./core-client/config/client_local_kind_threshold.toml

🚀 And launch your tests:

cargo nextest run --test kubernetes_test_threshold --profile ci --no-fail-fast

You can connect to the core-client with:

kubectl exec kms-core-client-0 -n kms-ci-mkmks-437 -it -- /bin/bash

Close your port-forwarding with:

pgrep -f "kubectl port-forward" | xargs -n 1 kill

[github-actions]

🚀 Preview deployment is deployed in "thresholdWithEnclave" mode

You can now port-forward the kms-core to run your tests locally against the preview deployment.

Connect to the Tailscale cluster zws-dev:

tailscale configure kubeconfig tailscale-operator-zws-dev.diplodocus-boa.ts.net

Port-forward the kms-core services to run your tests locally:

kubectl port-forward svc/kms-core-1-core-1 -n kms-ci-mkmks-437 50100:50100 & \
kubectl port-forward svc/kms-core-2-core-2 -n kms-ci-mkmks-437 50200:50100 & \
kubectl port-forward svc/kms-core-3-core-3 -n kms-ci-mkmks-437 50300:50100 & \
kubectl port-forward svc/kms-core-4-core-4 -n kms-ci-mkmks-437 50400:50100 &

Copy config.toml from core-client to ./core-client/config/client_local_kind_threshold.toml
⚠️ Make sure to not push this config.toml file to the repository!

kubectl cp kms-ci-mkmks-437/kms-core-client-0:/app/kms-core-client/config.toml ./core-client/config/client_local_kind_threshold.toml && \
    sed -i '' -E 's|address = "(http://)?kms-core-([0-9]+)-[^:]+:50100"|address = "http://localhost:50\200"|' ./core-client/config/client_local_kind_threshold.toml

🚀 And launch your tests:

cargo nextest run --test kubernetes_test_threshold --profile ci --no-fail-fast

You can connect to the core-client with:

kubectl exec kms-core-client-0 -n kms-ci-mkmks-437 -it -- /bin/bash

Close your port-forwarding with:

pgrep -f "kubectl port-forward" | xargs -n 1 kill