fix(keys): name the secp256r1 JWK curve P-256 - #234
erkancamli wants to merge 1 commit into
Conversation
JOSE registers the NIST P-256 curve as "P-256" (RFC 7518, Section 6.2.1.1); "secp256r1" is not a registered JWK curve name. publicKeyBytesToJwk emitted crv: "secp256r1", so a DID document built from a secp256r1 keypair (JWK is the default encoding) carried a key that did-jwt cannot match, and ES256 JWTs and credentials from that identity failed with "no matching public key found". The guards also rejected standard P-256 JWKs such as the one in RFC 7515, Appendix A.3. The JWK type, guards and conversions now use "P-256", and jwkToKeypair maps it back to the secp256r1 curve.
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (7)
Included review availability: This review used your included allowance. Your plan provides up to 2 included reviews per hour; 1 remain after this review. WalkthroughThe keys package now uses the JOSE curve name ChangesP-256 JWK conversion
Priority: ➖ Normal Estimated code review effort: 2 (Simple) | ~10 minutes Change: Bug fix Suggested reviewers: Merge Risk: ⚪ Minimal · up to The curve-name migration has no identified issue requiring a fix before merge. Stored JWKs using the old name still need the migration described in the changeset. Security Architecture ReviewSecurity architecture risk: 🟡 Moderate · up to The new P-256 representation fixes interoperability, but it is not compatible with keys saved under the old curve name. Deployments that retain those keys or roll back a package version may need a coordinated data change to keep signing available. No new signature-verification bypass was identified. Retained concerns
Security review detailsSecurity Blast Radius
Trust Boundaries and Controls
Resilience and Maintainability Implications
Hardening Proposals
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
What
publicKeyBytesToJwkwrites secp256r1 keys as{ kty: "EC", crv: "secp256r1" }. JOSE registers this curve as"P-256"(RFC 7518, Section 6.2.1.1, and the JWK Elliptic Curve registry in Section 7.6.2);"secp256r1"is not a registered JWK curve name.Why it matters
createDidDocumentFromKeypairpublishes keys as JWK by default, and did-jwt only matches an ECpublicKeyJwkwhosecrvis"secp256k1"or"P-256". So an ES256 JWT or credential signed by a secp256r1 identity built with ACK fails verification:In the other direction,
isJwkrejects standard P-256 JWKs such as the one in RFC 7515, Appendix A.3.1. The skyfire-kya demo already overridescrv: "P-256"by hand for this reason.Change
JwkSecp256r1.crvis"P-256"; the guards,publicKeyBytesToJwkandpublicKeyJwkToBytesuse it.jwkToKeypairmaps"P-256"back to thesecp256r1curve.@agentcommercekit/keysminor, since the JWK type changes and JWKs stored withcrv: "secp256r1"no longer pass the guards (the changeset says how to migrate them).Tests
crv: "secp256r1", and a secp256r1keypairToJwk/jwkToKeypairround trip.public-key.test.tsexpectation is updated toP-256for secp256r1.pnpm run buildandpnpm run checkpass locally (format, lint, all package tests).AI disclosure: I used Claude to help with analysis, code and tests, and reviewed all changes myself.
Summary by CodeRabbit
secp256r1as the curve name must be updated toP-256.