Re: [COSE] 🔔 WGLC of draft-ietf-cose-webauthn-algorithms

[Jim Schaad <[e-mail]>]

I start this review by copying forward all of my comments on draft-jones-cose-additional-algorithms-00

 

1.  I was surprised that there are two algorithms still in the WebAuthn document that are not included here.  Is that intentional and what is the plan forward for them? This one was addressed

 

2.  The title of the document is not descriptive in terms of a standalone sentence on what this document is doing.  It should be more specific on the algorithms.  The new title is fine except for the fact that WebAuthn is not expanded to anything.

 

3.  Abstract:  A list of the algorithms being processed in this document would be reasonable.  Based on the current text, the abstract would need to be re-written as soon as the algorithms are registered because they would then be registered and thus the specification is not necessary.  It would also be slightly odd in the event that the CTAP or WebAuthn protocols are updated to add new algorithms as they would not be in this document.  (See issue #1.)  No Change

 

4.  Section 1:  See abstract comment.  No change

 

5.  Section 2: The recommended column needs to be added to the table.  No change

 

6.  Section 2:  The discussion on what is and is not recommended and why belongs in this section not in the security considerations.  No change

 

7.  Section 2: You are missing some checks that should be done on signing and verification.  Look at the standard text at the end of sections in RFC 8152 for a pattern.  You might also want to add a check on lengths of keys both for a maximum and a minimum length.  No change

 

8.  Section 3:  This should not be the first use of JOSE and COSE and therefore the expansions here make no sense.  That should be in the introduction.  No change

 

9. Section 3.1:  I have only rarely seen this curve as P-256K, it is almost always referred to as secp256k1.  I would ask that this be changed in the COSE representation.  I am agnostic about what should be in the JOSE representation.  Fixed

 

10. Section 3.1:  I don't understand the reason for the last paragraph in the section.  It seems to me that this should just refer to all of the items defined for EC2 in COSE.  No Change

 

11. Section 3.1:  Is there a recommendation on using compressed vs non-compressed points?  No change

 

12.  Section 3.1:  You need to talk about if this is going to be IETF recommended or not.   (And why)  No change

 

13.  Section 3.2:  I don't understand what this section is doing.  If you are really defining a new signature algorithm, then that should be noted as part of the requirements in section 3.1 on the key.  If you are not defining a new signature algorithm then this section makes zero sense.  (You are not saying what the hash algorithm is.)  Both options are reasonable.  This is partly dealt with:

 

A.	Step 1 is incorrect in terms of COSE, it is not the payload that is signed.
B.	The new signature algorithm is being defined without motivation.  There should be text describing why this is ES256K and not ES256 (ECDSA with SHA-256).  I do note that there may be different text being described here for JOSE than for COSE.
C.	Please include text related to deterministic ECDSA in this text.  
D.	Text similar to the end of section 2.1 in draft-ietf-cose-rfc8152bis-algs should be included to nail things down tighter

 

14. Section 3.2:  If this is a new signature algorithm then it should say what curves it operates with.  Else there should be an addition of the algorithms that are legal in section 3.1 Done, but see comment 13

 

15.  Section 4.1 - The correct term is 'provisional' not 'temporary'. Not of sufficient importance to worry about.  However you can just use the provisional numbers without any comment or TBD given they are assigned.

 

16. Section 5.4 - So if somebody changes the crv value, is there any way to tell the difference?  If so then that should be described here.  No change

 

17.  Section 5.3 - This text seems to be self-contradictory.  If you MUST NOT use it, then how can you then use it?  How does an implementation know when it is or is not acceptable practice to use this?  No change

 

New Items:

 

18.  FIDO2 not expanded on first use in abstract and introduction.   Ditto for WebAuthn, COSE,

 

19.  Abstract does not refer to JSON – should it?

 

20.  Should be pointing to the current drafts and not to RFC 8152 in this document.

 

21.  Given that the algorithms in section 2 are already defined in JOSE, there should be text that this section only applies to COSE so there is no confusion.

 

Jim

 

 

From: COSE <[e-mail]> On Behalf Of ivaylo petrov
Sent: Tuesday, September 17, 2019 7:31 AM
To: cose <[e-mail]>
Subject: [COSE] 🔔 WGLC of draft-ietf-cose-webauthn-algorithms

 

Dear all,

This message starts the Working Group Last Call on the draft-ietf-cose-webauthn-algorithms [1].

The working group last call will run for **two weeks**, ending on
October 1, 2019.

Please review and send any comments or feedback to the working group. Even if your feedback is "this is ready", please let us know.

Thank you,

- Matthew and Ivaylo

COSE Chairs

[1]: https://datatracker.ietf.org/doc/draft-ietf-cose-webauthn-algorithms/