0084 XLS-84d: Support for ES256 on the P-256 curve in Passkey Signatures

[intelliot]

Title:       0084 XLS-84d: Support for ES256 on the P-256 curve in Passkey Signatures
Revision:    1 (2024-10-14)
Type:        draft
Authors:     Elliot Lee
             Javi Romero
Affiliation: Ripple

Abstract

This specification proposes adding support for the COSE algorithms -7 (ECDSA with SHA-256 over P-256) and -8 (EdDSA with Ed25519) in passkey signatures on the XRP Ledger. Building upon the foundational passkey support introduced in the Passkey Signature Support Specification, this document details the inclusion of these specific algorithms, ensuring compatibility with widely used and secure cryptographic methods. Possible COSE algorithm values include -7, -8, -35, and -36, but this specification clarifies that algorithms -35 (ECDSA with SHA-384) and -36 (ECDSA with SHA-512) are not supported by this spec. By supporting only -7 and -8, the protocol achieves security and interoperability with common passkey implementations.

1. Overview

We propose adding support for COSE cryptographic algorithms -7 and -8 for passkey signatures.

This feature will require an amendment, tentatively titled featurePasskeyAlgoSupport.

Dependency: This specification depends on the foundational passkey support introduced in the Passkey Signature Support Specification, which outlines the general framework for supporting passkey-generated signatures.

2. On-Ledger Object: PasskeyList

The PasskeyList ledger object is used to store and manage registered passkey credentials associated with an account.

2.1. Fields

Field Name	Required?	JSON Type	Internal Type	Description
LedgerEntryType	✔️	string	UInt16	The ledger object's type (PasskeyList).
Account	✔️	string	AccountID	The account owning this PasskeyList.
Credentials	✔️	array	Array	An array of registered passkey credentials.

2.1.1. Credentials Array Elements

Each element in the Credentials array represents a registered passkey credential:

Field Name	Required?	JSON Type	Internal Type	Description
CredentialID	✔️	string	Blob	The identifier of the credential used for signing, as provided by the authenticator.
PublicKey	✔️	string	Blob	The public key associated with the credential.
SignCount	✔️	number	UInt32	The signature counter value from AuthenticatorData, used to prevent replay attacks.
Algorithm	✔️	number	Int32	An integer indicating the cryptographic algorithm used by the credential, specified using COSE algorithm identifiers (-7 or -8 in this spec).

• Algorithm:

  • Possible Values:
    • -7: ECDSA with SHA-256 over the P-256 curve (secp256r1)
    • -8: EdDSA with Ed25519
    • Not Supported:
      • -35: ECDSA with SHA-384 over the P-384 curve
      • -36: ECDSA with SHA-512 over the P-521 curve
  • Description: Specifies the cryptographic algorithm used by the credential, ensuring the correct algorithm is applied during signature verification.

Signature Verification Process

The signature verification process for algorithms -7 and -8 MUST follow these steps:

1. Credential Lookup: Verify that the CredentialID corresponds to a registered credential in the account's PasskeyList.
2. Extract Algorithm: Retrieve the Algorithm associated with the CredentialID from the PasskeyList. Ensure it is -7 or -8. If it is -35 or -36, the transaction MUST fail with a temBAD_SIGNATURE error.
3. Compute Client Data Hash: Compute the SHA-256 hash of the ClientDataJSON.
4. Construct Signed Data: Concatenate AuthenticatorData and the ClientDataHash.
5. Verify Signature:
   • Use the appropriate cryptographic algorithm based on the Algorithm value:
     • -7: ECDSA with SHA-256 over the P-256 curve.
     • -8: EdDSA with Ed25519.
   • Verify the Signature over the concatenated signed data using the PublicKey.
6. Validate Challenge: Ensure the challenge in ClientDataJSON matches the transaction hash.
7. Prevent Replay Attacks: Verify that the SignCount from AuthenticatorData is greater than the stored SignCount and update it.

6. Security Considerations

• Algorithm Support: By supporting only algorithms -7 and -8, and explicitly not supporting -35 and -36, the XRP Ledger ensures the use of widely accepted and secure cryptographic methods while avoiding unnecessary complexity.
• Phishing Resistance: Passkey authentication reduces phishing risks by binding credentials to specific origins and using public-key cryptography.
• Private Key Security: Private keys remain securely stored within authenticators and are not exposed.
• Interoperability: Supporting algorithms -7 and -8 enables compatibility with most authenticators.

7. Compliance with WebAuthn Specification

• Algorithm Identifiers: Uses COSE algorithm identifiers as specified in the WebAuthn specification, and clarifies that only -7 and -8 are supported.
• Verification Process: Adheres to the steps outlined in the WebAuthn Level 2 specification for verifying authentication assertions.
• Data Structures: Includes necessary data structures (AuthenticatorData, ClientDataJSON, CredentialID) for proper verification.

[mvadari]

Will it be possible to use the P-256 curve with a seed, like you can with secp256k1 and ed25519?

[intelliot]

I could go either way on this, but I would lean toward "No" because Ed25519 would still be preferred for the seed use case.