add signDigest and verifyDigest operations

[panva]

Refs: #431
Refs: WICG/webcrypto-secure-curves#5

This PR adds signDigest and verifyDigest methods to the SubtleCrypto interface and defines the corresponding operations for the following algorithms: RSASSA-PKCS1-v1_5, RSA-PSS, ECDSA , and Ed25519.

• RSASSA-PKCS1-v1_5: Sign Digest performs EMSA-PKCS1-v1_5 signature generation with the supplied digest. Verify Digest performs the corresponding verification.
• RSA-PSS: Sign Digest and Verify Digest accept existing RsaPssParams and operate on the supplied digest.
• ECDSA: Sign Digest and Verify Digest accept EcdsaParams and use the supplied digest directly instead of hashing the message.
• Ed25519: Sign Digest and Verify Digest use Ed25519ph (RFC 8032 Section 5.1) with ContextParams for optional context support. A note clarifies that pure Ed25519 (used by sign/verify) and Ed25519ph (used by signDigest/verifyDigest) produce cryptographically distinct signatures that are not cross-verifiable.

Digest length is validated based on the hash algorithm: for RSA algorithms it's determined from the key's hash attribute, for ECDSA from the EcdsaParams dictionary's hash member , and for Ed25519 it's fixed to 64 bytes (SHA-512). In signDigest this is a rejection, in verifyDigest this is an early return false.

Uses existing keys and usages.

---

Preview | Diff

[Frosne]

That's not specifically about the patch, it's more a small bit that annoys my reading:
in one sentence we have normalisedAlgorithm AND algorithm.

Maybe one day we should change it to
Let signature be the result of performing the signDigest operation specified by |normalisedAlgorithm| using |key| and with |data| as |digest|/|message| (I believe for the sign operation). Same is about verify/verifyDigest.

[Frosne]

Sorry, I read slower than you update the patch :)

[twiss]

Thanks for the PR!

• Ed25519: Sign Digest and Verify Digest use Ed25519ph (RFC 8032 Section 5.1) with ContextParams for optional context support. A note clarifies that pure Ed25519 (used by sign/verify) and Ed25519ph (used by signDigest/verifyDigest) produce cryptographically distinct signatures that are not cross-verifiable.

I think it would be clearer to define a new algorithm, "Ed25519ph", if we want to support this (and/or drop this for now and define it in a separate PR).

After all, as you say, all the other algorithms have the property that sign(algorithm, message) === signDigest(algorithm, hash(message)), and I think it would be nice to preserve that invariant.

Additionally, there is a third algorithm in RFC 8032, Ed25519ctx, and we might want to clearly define which one is used if we ever add support for it (in the non-digest sign/verify), in which case we should clearly identify Ed25519ph as well.

(All of that being said, I don't think Ed25519ph and Ed25519ctx are particularly widely used, so adding them seems less urgent to me than the other algorithms, although I'm not opposed to it if there's implementer interest.)

[panva]

I think it would be clearer to define a new algorithm, "Ed25519ph", if we want to support this (and/or drop this for now and define it in a separate PR).

For Ed25519ctx I'd 100% agree since adding ContextParams.context option to Ed25519 would not cause its use to throw in existing implementations.

But for Ed25519ph because there's not only domain separation, there's actual method separation so I didn't come to a conclusion that a separate webcrypto algorithm is needed.

After all, as you say, all the other algorithms have the property that sign(algorithm, message) === signDigest(algorithm, hash(message)), and I think it would be nice to preserve that invariant.

Not a goal as far as i'm concerned.

(All of that being said, I don't think Ed25519ph and Ed25519ctx are particularly widely used, so adding them seems less urgent to me than the other algorithms, although I'm not opposed to it if there's implementer interest.)

Agreed, I'll drop it. It was a fun exercise regardless.