Ballot for draft-ietf-cose-webauthn-algorithms
Yes
No Objection
Note: This ballot was opened for revision 07 and is now closed.
Thanks for the updates in -07 in response to LC feedback on secp256k1 and ES256K being registered as “Recommend: No”. Two additional items in that vein: ** Table 2. ES256K should read Recommended = NO (i.e., not recommended) consistent with the registration guidance in Section 4.1 and Section 4.2. ** Section 5.4. The basis of the “not recommended” is explained in Section 5.2 and 5.3. Can that be done here too.
Thank you for addressing my review comments. I would prefer to go even further on the "more strongly reiterate the cross-algorithm risk" front, perhaps OLD: Care should be taken that a secp256k1 key is not mistaken for a P-256 [RFC7518] key, given that their representations are the same except for the "crv" value. As described in Section 8.1.1 of [RFC8152], we currently do not have any way to deal with this attack except to restrict the set of curves that can be used. NEW: Care should be taken that a secp256k1 key is not misinterpreted as a P-256 [RFC7518] key, given that their representations are the same except for the "crv" value. As described in Section 8.1.1 of [RFC8152], we currently do not have any way to deal with this attack except to restrict the set of curves that can be used. In general, any system that is willing to accept both "crv" values "secp256k1" and "P256" is vulnerable to this substitution attack, absent some external mechanism for integrity protecting the "crv" value used to interpret the key.