Webauthn: Crypto algorithm agility: e.g., Specify the set of hash algorithms UAs can select between.

[jyasskin]

Simply requiring a "recognized algorithm name" isn't enough because arbitrary other specifications can define an algorithm, while relying parties need to know which hash algorithms they need to be able to use to verify signatures.

@equalsJeffH suggested limiting to {SHA-256, SHA-384, SHA-512} in https://github.com/w3c/webauthn/pull/347#discussion_r103040671. There's been mention of SM3 in the spec, but it's not currently defined in WebCrypto. It could be defined somewhere appropriate and re-added to the set of allowed algorithms in this spec later, if folks want to do so.

[vijaybh]

I don't think this is relevant to CTAP. For CTAP, the hash value is just an opaque bunch of bits. The hash algorithm is only relevant to the application running on the RP side.

[selfissued]

In general, this goes to the question of how RPs discover the supported functionality of the client, for functionality that can be added to. If we decide that a fixed list is fine for now, then I agree with Jeff's list.

We should decide this for the Implementer's Draft, since it affects interop.

[samuelweiler]

In general, it's useful to have a story re: algorithm agility, and that goes far beyond "just parameterize them". That story needs to include specific instructions for what to do when a new, previously unknown algorithm appears and when no known algorithms appear. Ideally, it would address downgrade attacks.

RFC7696 (Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms) is relevant, though it's really not a great reference. I'll see if I can find something better.

[jyasskin]

The algorithm agility story should probably be bigger than just the hash function. I've seen advice that we should strive to handle agility by upgrading to a whole new suite of cryptographic primitives, rather than making the parties negotiate each algorithm. Maybe the PublicKeyCredentialType enumeration is the right place to declare which versions an RP supports, and then each version will specify a single cryptographic algorithm for the authenticator to use in each place?

[equalsJeffH]

see also #296

[equalsJeffH]

see also #296 -- tho @rlin1 asserts this issue is actually different and I agree.

[nadalin]

@selfissued need to state which algs are acceptable for the UA to use eg when hashing the clientData.

[rlin1]

WebCrypto already defines a list of "popular" algorithms that we could reference.
See https://www.w3.org/TR/WebCryptoAPI/#algorithm-recommendations-implementers

[selfissued]

@jyasskin it looks to me like this issue is probably obsolete now. Since it was written, we've redone the description of the use of cryptographic algorithms and identifiers - referencing and using registered algorithms in the IANA COSE Algorithms registry at https://www.iana.org/assignments/cose/cose.xhtml#algorithms. If you agree, can you please close this? If you don't can you add a comment proposing a specific requested change so the issue becomes actionable? Thanks.

[jyasskin]

https://w3c.github.io/webauthn/#dom-collectedclientdata-hashalgorithm still refers to a "recognized algorithm name" as this issue says. Also, the COSE algorithms don't include hash algorithms.

I'd suggest "The hashAlgorithm member is one of "SHA-256", "SHA-384", or "SHA-512", interpreted as a recognized algorithm name."

[equalsJeffH]

@jyasskin wrote in https://github.com/w3c/webauthn/issues/362#issuecomment-302914784:

The algorithm agility story should probably be bigger than just the hash function. I've seen advice that we should strive to handle agility by upgrading to a whole new suite of cryptographic primitives, rather than making the parties negotiate each algorithm. Maybe the PublicKeyCredentialType enumeration is the right place to declare which versions an RP supports, and then each version will specify a single cryptographic algorithm for the authenticator to use in each place?

sounds like a worthwhile approach to consider.

[equalsJeffH]

on 6-Dec-2017 webauthn call: fix hash alg at "SHA-256", worry about SHA2 being broken anon, strip out "recognized algorithm name" phrase. tacitly rely on PublicKeyCredentialType enumeration in the future as necessary to signal use of another crypto suite.