Open panva opened 2 weeks ago
Yeah, if this spec (or the SHA3 part of it) were to be merged into Web Crypto, it would essentially have that effect - unless we add some text to the contrary, but I don't see why it shouldn't be allowed.
The only caveat is, we might have to come up with & register some JWK alg
s for those new combinations - but the same is true for some of the other new algorithms in this spec, see https://twiss.github.io/webcrypto-modern-algos/#jwk-mapping. Or we could just leave alg
empty in those cases, as we do for ECDSA..?
Yeah it would need registrations probably through its own JOSE IETF WG specs, otherwise export without alg
.
There are a number of algorithms in the IANA registry that point to Web Crypto as the reference, so I suppose we could do the same here. But yeah, perhaps having an IETF spec might be better.
Yeah I know, but those are either straight forward or (in most cases) prohibited. In case of e.g. RSA-PSS the required saltLength is not part of that registration, it's part of its definition. I really depends, not to mention that it's too early think about :D
edit:
The size of the salt value is the same size as the hash function output.
So that would be straight forward as well.
Is it intended that the SHA3 algorithms from this proposal interact with other algorithms from https://w3c.github.io/webcrypto/ whenever a
hash
algorithm member (HashAlgorithmIdentifier
) is used? e.g. RSA-PSS with SHA3-256 hash, where hash is on the key's algorithm, or ECDSA where hash is on the operation's algorithm, or HMAC similarly to ECDSA on the operation's algorithm, same for HKDF.Asking for a friend.