Improve algorithm steps for Modern Algorithms' supports() method

[panva]

The Modern Algorithms specification defines SubtleCrypto.supports() by normalizing an algorithm and executing its operation steps until it encounters unavailable key or data, key generation, a return, or an exception.

This makes the ordering and explicitness of validation in the core Web Cryptography specification observable. Some core operations currently reach one of those stopping points before checking parameters that supports() does have. This can make supports() return true for an interaction that:

• cannot succeed with any key or input;
• is not defined for the selected algorithms;
• is not expected to be supported by underlying cryptographic libraries; or
• is already deliberately rejected by implementations.

This PR makes those outcomes observable before supports() reaches its stopping point.

Changes

• Move existing AES-GCM IV, additional-data, and tag-length validation ahead of plaintext or ciphertext access.
• Check HKDF's 255-block output limit before accessing key material.
• Reject an explicitly zero-length HMAC import before examining key data.
• Check necessary RSA modulus-length and public-exponent constraints before key generation.
• Validate supplied X25519 and ECDH public keys and maximum derivation lengths before accessing the unavailable private key.
• Derive the ECDH output limit from the curve's EC domain parameters, including curves defined by applicable specifications.
• Define NamedCurve as an enum so names not defined by the core or an applicable specification fail during normalization.
• Make the fixed-output-hash boundary explicit for RSA, ECDSA, HMAC, HKDF, and PBKDF2.

The XOF checks establish an intentionally unsupported boundary rather than claiming every such composition is cryptographically impossible/undefined. Selecting an output length for an XOF does not turn it into the fixed-output hash expected by these traditional algorithms. In particular, implementations already reject RSA and ECDSA combinations with XOF digests using NotSupportedError. This just sets it as baseline.

Successful operations are unchanged.

Examples

Each of the following now returns false.

AES-GCM parameters

SubtleCrypto.supports("encrypt", {
  name: "AES-GCM",
  iv: new Uint8Array(12),
  tagLength: 31,
})

A 31-bit AES-GCM tag is never valid, regardless of key or plaintext.

HKDF output length

SubtleCrypto.supports("deriveBits", {
  name: "HKDF",
  hash: "SHA-256",
  salt: new Uint8Array(),
  info: new Uint8Array(),
}, 65288)

With SHA-256 the maximum is 65280 bits, so 65288 bits can never be derived.

XOFs in traditional algorithms

SubtleCrypto.supports("generateKey", {
  name: "HMAC",
  hash: { name: "cSHAKE128", outputLength: 256 },
})

Modern Algorithms implementations deliberately exclude XOF digests from these traditional algorithms. Selecting an output length does not turn cSHAKE into a fixed-output hash.

Undefined named curves

SubtleCrypto.supports("importKey", {
  name: "ECDSA",
  namedCurve: "not-a-curve",
})

No import using an undefined curve could ever succeed.

Zero-length HMAC imports

SubtleCrypto.supports("importKey", {
  name: "HMAC",
  hash: "SHA-256",
  length: 0,
})

No HMAC key data can satisfy an explicitly requested length of zero.

RSA key generation parameters

SubtleCrypto.supports("generateKey", {
  name: "RSA-PSS",
  modulusLength: 2048,
  publicExponent: new Uint8Array([2]),
  hash: "SHA-256",
})

No RSA key can use an even public exponent.

X25519 derivation length

SubtleCrypto.supports("deriveBits", {
  name: "X25519",
  public: publicKey,
}, 257)

X25519 produces at most 256 bits, so 257 bits can never be derived. Refs: WICG/webcrypto-modern-algos#74

ECDH derivation length

SubtleCrypto.supports("deriveBits", {
  name: "ECDH",
  public: publicKey,
}, 257)

With a P-256 public key, the field element encodes to 256 bits. The output limit is derived from the public key’s EC domain parameters, so extended named curves are handled without enumeration. Refs: WICG/webcrypto-modern-algos#74

---

Preview | Diff

[panva]

@twiss to confirm then

• replace e5fff3a with a break out per Improve algorithm steps for Modern Algorithms' supports() method #558 (review)
• drop 7c363af entirely to be dealt with later possibly reflecting on what gets implemented in an even broader round

The rest is fine from your POV?

[twiss]

Yeah, I'll do one more pass afterwards but I think the rest looks good 👍 Thanks!

[panva]

@twiss done , i'll leave the one review thread unresolved until the PR for modern algorithms is there.

[twiss]

Thanks! Final nit below.