twiss
commented
2 months ago Hey :wave: I hadn't considered it, but I'm also not sure if it's useful for web apps to be able to enumerate the supported algorithms, unless they have a lot of flexibility wrt. which algorithm to use (which usually you wouldn't have if you're implementing a specific protocol or so).
Also, for operations other than digest, you usually need to provide additional parameters etc. to use them, so you wouldn't be able to use an algorithm that you don't already know about in that case.
(And if you do know about them, you can just do ['SHA-1', 'SHA-256', ..., 'SHA3-256', ...].filter(alg => crypto.subtle.supports('digest', alg) with the current proposal for supports().)
with a mention not to use SHA-1 only if absolutely needed
I'm also not super sure if it's useful to expose programmatically, since if a web app wants to switch from SHA-1 to SHA-2 or -3 they would usually have to do additionaly work beyond just switching the algorithm in Web Crypto (e.g. store the hash algorithm used, in order for it to be backwards compatible, and so on). And once they switched, I don't think it's a good idea to continue to use SHA-1 in (versions of) browsers that think it's fine, for example.
(Btw, there's also draft-irtf-cfrg-webcrypto-algorithms about which algorithms are OK to use and not, though it should probably be updated.)
Frosne
That's not an issue with the provided specification, just opening a discussion (you can close it (= the discussion :D) if you already considered what I am gonna propose and don't find it useful).
When you were talking about the checking support functionality, I was asking myself if it would make sense to support a functionality providing which functions are supported. For example, supports('sign') could return 'SHA-1', 'SHA-256, ...', 'SHA3-256,...' with a mention not to use SHA-1 only if absolutely needed.