tECDSA secp256r1 key_1 reshared to uzr34 in proposal 144488

On October 19, 2026, NNS proposals 144463, 144488 and 144489 halted subnet uzr34, reshared the new tECDSA secp256r1 (NIST P-256) master key key_1 from the fiduciary subnet pzp6e to it, and restarted it. If your canister needs P-256 signatures, build against test_key_1 now and switch to key_1 after the follow-up proposal that enables signing on pzp6e executes.

This follows our earlier report on the P-256 test key. The production key now exists on two subnets. One step remains: enabling it for signing.

What changed: three proposals on October 19

The production key was created when proposal 144331 executed. That proposal "generated a new tECDSA Secp256r1 (NIST P-256) master key on the fiduciary signing subnet pzp6e". Before a key can be enabled for signing, a backup subnet must also hold it. For ICP's production keys, the backup subnet is uzr34, which also hosts the Internet Identity (II) canister. DFINITY announced the process on October 16 and voted to adopt the first proposal on "Monday, Oct 19th 2026, 13:00 UTC".

On October 19, DFINITY engineer eichhorl wrote that the resharing from pzp6e to uzr34 "was successful". For the new key, DFINITY proposed "the same parameters for the new key as currently used for the existing ECDSA key". All other parameters stayed the same. The fourth proposal enables signing on pzp6e, which already signs for the existing master keys. The forum thread does not give its number.

The API work came earlier. As noted in the thread, the secp256r1 variant was added to the public API in Registry proposal 144199, in a commit that also changed the management canister. PocketIC also supports secp256r1 threshold ECDSA keys (dfinity/ic PR #11741). For local tests, a cdk-rs pull request (#716) adds the curve to the Rust management canister bindings and prepares ic-cdk-management-canister v0.3.0.

Who is affected and why it matters

Internet Identity users. While uzr34 was paused, the II canister was planned to be unresponsive for "approximately 5–10 minutes". During that window, new II sessions could not start. Existing sessions kept working, and dapps kept working for users who were already logged in. The same halt-and-recover process was used before for the vetKeys production key and, more recently, to back up the P-256 test key to subnet fuqsr.

Canister developers. DFINITY says secp256r1 is used for web push notifications (VAPID) and X.509 certificates. With native support, canisters can sign for these schemes themselves instead of relying on a centralized third party. The interface spec change (developer-docs PR #394) also lists WebAuthn, TLS and OAuth DPoP as P-256 use cases. If you run an off-canister signer today only because ICP had no P-256 key, you can now plan to move that signing into a canister.

Governance voters and node providers. Proposal 144488 rewrote a subnet's recovery CUP. The published CUP lets anyone check that uzr34 was halted at a known state and restarted with that same state.

What to do now

The interface spec gives ecdsa_curve a new secp256r1 variant. You select it in the same key_id record that ecdsa_public_key and sign_with_ecdsa already use:

type ecdsa_curve = variant { secp256k1; secp256r1 };

ecdsa_public_key : (record {
  canister_id : opt canister_id;
  derivation_path : vec blob;
  key_id : record { curve : ecdsa_curve; name : text };
}) -> (record { public_key : blob; chain_code : blob });

sign_with_ecdsa : (record {
  message_hash : blob;
  derivation_path : vec blob;
  key_id : record { curve : ecdsa_curve; name : text };
}) -> (record { signature : blob });

// production key, once signing is enabled on pzp6e:
// key_id = record { curve = variant { secp256r1 }; name = "key_1" }

Steps for a P-256 integration:

1. Update your management canister bindings to a version that includes the secp256r1 variant. Older bindings cannot encode it.
2. Write and run local tests with PocketIC, which now holds secp256r1 keys.
3. On mainnet, use test_key_1 until production signing is enabled. A draft docs PR (developer-docs #420) lists test_key_1 on fuqsr and key_1 on pzp6e as the end state.
4. Watch the NNS proposal that enables ecdsa:secp256r1:key_1 on pzp6e. Change the key name to key_1 only after that proposal has executed.
5. Keep the curve and key name in configuration so that moving from the test key to the production key needs no code change.
6. Do not reuse secp256k1 public keys or addresses. Each curve has its own master key, so you must fetch the P-256 public key separately.

To check the halted uzr34 CUP yourself, follow the steps DFINITY posted for replica version 4a0dbb9251df6da0b65ab7a4d35e9a9871f58510:

git clone https://github.com/dfinity/ic.git
cd ic
git checkout 4a0dbb9251df6da0b65ab7a4d35e9a9871f58510

curl -fL -o /tmp/uzr34_cup_2026-10-19.pb https://oscnz-6iaaa-aaaas-qg6aa-cai.icp.net/uzr34_cup_2026-10-19.pb

bazel run --config=local //rs/cup_explorer:cup_explorer_bin -- verify-cup-of-halted-subnet --cup-path /tmp/uzr34_cup_2026-10-19.pb

The output should include "Confirmed that subnet uzr34 was halted on this CUP." Then compare the state hash it prints with the one in recovery proposal 144488. The earlier forum post "Verifying Key Resharing Proposals" explains that the tool confirms two things: the subnet was halted on purpose at a given CUP, and it restarted without changes to its state.

Caveats

Signing with key_1 is not available until the enable proposal on pzp6e executes. Check its status on the NNS dashboard before you deploy production code. Signature fees for the new key will follow its signing parameters, which DFINITY proposed to match the existing ECDSA key. Check the official cycle cost page rather than assuming a price.