feat: add secp256r1 to the ECDSA curves in the interface spec

[MRmarioruci]

New variant secp256r1 of ecdsa_curve, selecting threshold ECDSA on the NIST P-256 curve in ecdsa_public_key and sign_with_ecdsa. P-256 is the curve the web platform standardised on: WebAuthn, TLS, VAPID web push (ES256) and OAuth DPoP. A canister cannot produce any of those signatures today, so each one needs a key held off-chain.

Changes

Key derivation for the new curve is the same generalization of BIP32 instantiated over P-256, which is SLIP-10. signing/key_derivation.rs:210 dispatches Ed25519 => eddsa_ckd, _ => bip32_ckdpub, so K256 and P256 run the same code, and bip32_ckdpub documents itself as following SLIP-0010 with BIP32 identical for K256. The derivation paragraph is split into one bullet per curve, matching how schnorr_public_key already presents its two algorithms. Signatures are encoded as for secp256k1, because EccCurveType::scalar_bytes is 32 on both curves, so r and s are 32 bytes each. The ecdsa_curve argument of ic0.cost_sign_with_ecdsa accepts 1, and the changelog bullet goes under the current 0.67.0 heading.

Two things deliberately left out. The u32 value 1 is normative, since it is the System API ABI, so it has to agree with dfinity/ic: please confirm it before this merges. And this describes the interface, not availability. Whether a given key_id exists depends on the implementation, so the pages that list the keys deployed on mainnet are unchanged, docs/references/management-canister.md included. Those should change when a key is generated.

Paired with dfinity/ic#11573, which adds the variant to the implementation.

Tests

didc check public/references/ic.did passes, and node scripts/validate.js passes on the three changed markdown files.

🤖 Generated with Claude Code

[github-actions]

🤖 Here's your preview: https://kwnd6-zaaaa-aaaam-ai7va-cai.icp0.io

[Copilot]

🟢 Approval recommended

No unresolved review comments were identified, and the interface and documentation changes are consistent.

Pull request overview

Adds secp256r1 support to the IC interface specification for threshold ECDSA.

Changes:

• Adds the P-256 Candid curve variant.
• Documents SLIP-10 derivation and 64-byte signatures.
• Maps System API curve value 1 to P-256 and updates the changelog.

File summaries

File	Description
public/references/ic.did	Adds the secp256r1 variant.
docs/references/ic-interface-spec/management-canister.md	Documents P-256 derivation and signatures.
docs/references/ic-interface-spec/changelog.md	Records the interface addition.
docs/references/ic-interface-spec/canister-interface.md	Documents the numeric curve mapping.

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 0
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[marc0olo]

Review: secp256r1 in the ECDSA curves

Must fix

• Hold until feat(crypto): add secp256r1 variant to EcdsaCurve ic#11573 merges: the spec leads, but publishing it before the protocol accepts the variant would describe a curve the network rejects. Nothing to change for it, just the merge timing.
• The u32 value is decided here: the body asks for 1 to be confirmed against dfinity/ic, and feat(crypto): add secp256r1 variant to EcdsaCurve ic#11573 points back here. This repo is the source of truth, so the value is normative once published. Drop the caveat and flip the cross-reference in feat(crypto): add secp256r1 variant to EcdsaCurve ic#11573.
• The changelog bullet is in the wrong section: main now has ### 0.68.0 (2026-09-14), and a test merge drops the bullet at the end of ### 0.67.0 (2026-08-31), with no conflict to flag it. Give it a new ### 0.69.0 {$0_69_0} at the top. The sections run on biweekly Mondays, so date it at the first one after feat(crypto): add secp256r1 variant to EcdsaCurve ic#11573 merges.
• docs/references/management-canister.md: the availability pages are rightly untouched, but three lines there state the interface, not availability. Line 356 currently supports secp256k1 now covers both curves. Line 361 needs the P-256 / SLIP-10 sentence. Line 373 64 bytes for secp256k1 applies to both.

Suggestions

• The secp256r1 bullet omits the non-conforming path case: the secp256k1 bullet says such a path still returns a key, just not BIP32-compatible. Worth stating for SLIP-10 too.
• Bullet placement: move the curve bullets below the return value paragraph, as in schnorr_public_key.