Skip to main content

CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) Registrations for Web Authentication (WebAuthn) Algorithms
draft-ietf-cose-webauthn-algorithms-08

Yes

Murray Kucherawy

No Objection

Erik Kline
Warren Kumari
Éric Vyncke
(Alvaro Retana)
(Barry Leiba)
(Deborah Brungard)
(Magnus Westerlund)
(Robert Wilton)

Note: This ballot was opened for revision 07 and is now closed.

Murray Kucherawy
Yes
Erik Kline
No Objection
Roman Danyliw
No Objection
Comment (2020-06-09 for -07) Sent
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.
Warren Kumari
No Objection
Éric Vyncke
No Objection
Alvaro Retana Former IESG member
No Objection
No Objection (for -07) Not sent

                            
Barry Leiba Former IESG member
No Objection
No Objection (for -07) Not sent

                            
Benjamin Kaduk Former IESG member
(was Discuss) No Objection
No Objection (2020-06-12) Sent
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.
Deborah Brungard Former IESG member
No Objection
No Objection (for -07) Not sent

                            
Magnus Westerlund Former IESG member
No Objection
No Objection (for -07) Not sent

                            
Robert Wilton Former IESG member
No Objection
No Objection (for -07) Not sent