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

From: Mike Jones <[email-masked]>
Date: Mon, 21 Oct 2019 23:59:40 +0000

Thanks for your review, Jim.  Responses are inline, prefixed by “Mike>”.

                                                       -- Mike

From: Jim Schaad <[email-masked]>
Sent: Tuesday, September 17, 2019 6:46 PM
To: 'cose' <[email-masked]>
Cc: [email-masked]
Subject: RE: [COSE] 🔔 WGLC of draft-ietf-cose-webauthn-algorithms

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

Mike> Understood.  I’ll reword so that the text remains correct after the IANA registrations have been performed.

4.  Section 1:  See abstract comment.  No change

Mike> Ditto

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

Mike> I assume the column you’re talking about is the one requested in the next comment.

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

Mike> OK, I can add an “Implementation Requirements” column, paralleling the treatment in https://tools.ietf.org/html/rfc7518#section-3.1.

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

Mike> Key size considerations for the RSA algorithms are already covered in https://tools.ietf.org/html/draft-ietf-cose-webauthn-algorithms-01#section-5.1.  For ES256K, I can say that the X and Y values for the public key must both be exactly 256 bits.  What are the specific checks you wanted added?  I couldn’t tell which sections of RFC 8152 you were referring to.  Also, note that between draft-jones-00 and draft-ietf-01, the descriptions of the use of hash functions were beefed up, in response to other comments received.

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

Mike> I’ll look into expanding abbreviations on first uses and not on subsequent uses.

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

Mike> OK

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

Mike> I will state that uncompressed point representations are to be used for JWKs, as a compressed representation for key type “EC” is not defined.  And I will state that the uncompressed must also be used for CWKs, as I don’t know that the Galois y² = x³ + 7 finite field form used with secp256k1 is amenable to compression.  (However, if the CRFG or other experts tell me that it is, I will also allow for the compressed representation with COSE.)

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

Mike> https://tools.ietf.org/html/draft-ietf-cose-webauthn-algorithms-01#section-4.1 has it being recommended.  I will describe why in the next version, as requested.

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:

Mike> This is intentionally exactly parallel to RFC 7518, which defines the “ES256” algorithm identifier to be used with the “P-256” curve.  In this case, it is defining the “ES256K” algorithm identifier to be used with the “secp256k1” curve.

  1.  Step 1 is incorrect in terms of COSE, it is not the payload that is signed.

Mike> I’ll revise the description here to align with correct COSE terminology.

  1.  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.

Mike> “ES256” is defined by RFC 7518 to be always used with the P-256 curve.  A different algorithm identifier is therefore required to use with secp256k1.  This is by design.  And the use of identifiers is being kept intentionally parallel between JOSE and COSE.

  1.  Please include text related to deterministic ECDSA in this text.

Mike> What do you want this text to say?  I’m reluctant to use the text at https://tools.ietf.org/html/rfc8152#section-8.1, which says that “implementations SHOLUD use a deterministic algorithm”, which is misleading, in that it implies that there are many such algorithms that could be used.  In fact, exactly one is being specified.

  1.  Text similar to the end of section 2.1 in draft-ietf-cose-rfc8152bis-algs should be included to nail things down tighter

Mike> Are you talking about the text starting “When using a COSE key for this algorithm, the following checks are made:”?  Are you requesting those same checks?

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

Mike> The way that you can tell that the “crv” value has been changed is that “crv” parameter will have a different value.  That’s so simple as to be practically tautological and not worth explicitly saying.  I’m guessing you want me to say something else, but I don’t know what it is.

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

Mike> I will add the description agreed to in the on-list conversation with Neil Madden.

New Items:

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

Mike> Will do

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

Mike> I’ll look into editorially where to best introduce JSON.

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

Mike> I’ll plan to update this specification once the bis versions are RFCs.  But there’s no need to take a normative dependence on the new versions, as this spec uses nothing new being introduced by them.

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.

Mike> Sure

Jim

From: COSE <[email-masked]<mailto:[email-masked]>> On Behalf Of ivaylo petrov
Sent: Tuesday, September 17, 2019 7:31 AM
To: cose <[email-masked]<mailto:[email-masked]>>
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/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-cose-webauthn-algorithms%2F&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cb65306e054df4a68cc4b08d73bda0c93%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637043680013925141&sdata=MpyFQf0Mdxd6PEXtNUJJLJBjSDWGacfLnCIEsMBTqhg%3D&reserved=0>

---

From: Jim Schaad <[email-masked]>
Date: Mon, 21 Oct 2019 17:53:43 -0700

From: Mike Jones <[email-masked]> 
Sent: Monday, October 21, 2019 5:00 PM
To: Jim Schaad <[email-masked]>; 'cose' <[email-masked]>
Cc: [email-masked]
Subject: RE: [COSE] 🔔 WGLC of draft-ietf-cose-webauthn-algorithms

                                                       -- Mike

From: Jim Schaad <[email-masked] <mailto:[email-masked]> > 
Sent: Tuesday, September 17, 2019 6:46 PM
To: 'cose' <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> 
Subject: RE: [COSE] 🔔 WGLC of draft-ietf-cose-webauthn-algorithms

Mike> Ditto

When using a COSE key for this algorithm, the following checks are

   made:

   o  The 'kty' field MUST be present, and it MUST be 'EC2'.

   o  If the 'alg' field is present, it MUST match the ECDSA signature

      algorithm being used.

   o  If the 'key_ops' field is present, it MUST include 'sign' when

      creating an ECDSA signature.

   o  If the 'key_ops' field is present, it MUST include 'verify' when

      verifying an ECDSA signature.

Mike> OK

https://bitcoin.stackexchange.com/questions/76181/bitcoin-public-keys-from-uncompressed-to-compressed-version-with-code-sample

[JLS] But that is not the decision that was made for COSE.   Only the hash algorithm was fixed.

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

[JLS] So, If I take your sep256k1 key and change the curve to P-256 that cannot be detected?

New Items:

Mike> Will do

Mike> Sure

Jim

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

Dear all,

Thank you,

- Matthew and Ivaylo

COSE Chairs

[1]:  <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-cose-webauthn-algorithms%2F&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cb65306e054df4a68cc4b08d73bda0c93%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637043680013925141&sdata=MpyFQf0Mdxd6PEXtNUJJLJBjSDWGacfLnCIEsMBTqhg%3D&reserved=0> https://datatracker.ietf.org/doc/draft-ietf-cose-webauthn-algorithms/

---

From: Jim Schaad <[email-masked]>
Date: Tue, 22 Oct 2019 08:14:40 -0700

I forgot to respond to this one

                                                       -- Mike

 

A.	Please include text related to deterministic ECDSA in this text.

[JLS] I was unaware that there is only one possible deterministic algorithm, any keyed hash algorithm can be used to generate the deterministic ‘k’ to be used for the signature algorithm.  There is not a requirement that the secret value be the private key for the signature key pair, one could generate a private value just for that purpose.  Independent of that, the default ECDSA algorithm specifications all say use a random value of ‘k’ rather than a deterministic value and the use of the deterministic value is far more secure.

---

From: Mike Jones <[email-masked]>
Date: Tue, 22 Oct 2019 16:02:53 +0000

Thanks for your replies, Jim.  My additional replies are prefixed by “Mike2>”.

                                                       -- Mike

From: Jim Schaad <[email-masked]>
Sent: Monday, October 21, 2019 5:54 PM
To: Mike Jones <[email-masked]>; 'cose' <[email-masked]>
Cc: [email-masked]
Subject: RE: [COSE] 🔔 WGLC of draft-ietf-cose-webauthn-algorithms

From: Mike Jones <[email-masked]<mailto:[email-masked]>>
Sent: Monday, October 21, 2019 5:00 PM
To: Jim Schaad <[email-masked]<mailto:[email-masked]>>; 'cose' <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [COSE] 🔔 WGLC of draft-ietf-cose-webauthn-algorithms

                                                       -- Mike

From: Jim Schaad <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, September 17, 2019 6:46 PM
To: 'cose' <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [COSE] 🔔 WGLC of draft-ietf-cose-webauthn-algorithms

Mike> Ditto

Mike> OK, I can add an “Implementation Requirements” column, paralleling the treatment in https://tools.ietf.org/html/rfc7518#section-3.1<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc7518%23section-3.1&data=02%7C01%7CMichael.Jones%40microsoft.com%7C624ed39d427e40f5fdee08d7568a5535%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637073024454068673&sdata=oaD2rqxWUF8y35F%2BWReXRRD2LV4iCtI%2FzpkjwDBNzmk%3D&reserved=0>.

Mike> Key size considerations for the RSA algorithms are already covered in https://tools.ietf.org/html/draft-ietf-cose-webauthn-algorithms-01#section-5.1<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-cose-webauthn-algorithms-01%23section-5.1&data=02%7C01%7CMichael.Jones%40microsoft.com%7C624ed39d427e40f5fdee08d7568a5535%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637073024454078667&sdata=8V3Rqg0NBhtkOnBxqgdxJB7DLEYitJ7vHRdcpk33J6w%3D&reserved=0>.  For ES256K, I can say that the X and Y values for the public key must both be exactly 256 bits.  What are the specific checks you wanted added?  I couldn’t tell which sections of RFC 8152 you were referring to.  Also, note that between draft-jones-00 and draft-ietf-01, the descriptions of the use of hash functions were beefed up, in response to other comments received.

Mike2> OK

Mike> OK

Mike2> OK, then I’ll allow the compressed representation for COSE.

Mike> https://tools.ietf.org/html/draft-ietf-cose-webauthn-algorithms-01#section-4.1<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-cose-webauthn-algorithms-01%23section-4.1&data=02%7C01%7CMichael.Jones%40microsoft.com%7C624ed39d427e40f5fdee08d7568a5535%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637073024454078667&sdata=pkRVavDRZdeWdgWW75YxOd5OXQWqPqC6%2FJyTOa5HoeE%3D&reserved=0> has it being recommended.  I will describe why in the next version, as requested.

Mike2> The parallel treatment also works fine in COSE.  One must only use “secp256k1” for signing with “ES256K” and not with other algorithm identifiers.  I’ll make this clearer in the next version.

Mike> What do you want this text to say?  I’m reluctant to use the text at https://tools.ietf.org/html/rfc8152#section-8.1<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8152%23section-8.1&data=02%7C01%7CMichael.Jones%40microsoft.com%7C624ed39d427e40f5fdee08d7568a5535%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637073024454088659&sdata=cgfgH23Mdi9Uw93%2FbeEiHEMoQA%2BKSh9hGDAJsCqJyOQ%3D&reserved=0>, which says that “implementations SHOLUD use a deterministic algorithm”, which is misleading, in that it implies that there are many such algorithms that could be used.  In fact, exactly one is being specified.

Mike2>  Yes, it can be detected because if the algorithm identifier used is “ES256K” and the “crv” value is not “secp256k1”, it’s illegal input, and MUST be rejected.  I’ll add this to the checks.

New Items:

Mike> Will do

Mike> Sure

Jim

Dear all,

Thank you,

- Matthew and Ivaylo
COSE Chairs

[1]: https://datatracker.ietf.org/doc/draft-ietf-cose-webauthn-algorithms/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-cose-webauthn-algorithms%2F&data=02%7C01%7CMichael.Jones%40microsoft.com%7C624ed39d427e40f5fdee08d7568a5535%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637073024454088659&sdata=YoZb6DDcwWZAWqLbfuShGwe8G7tTMKbHeS7gJBH17%2FU%3D&reserved=0>

---

From: Mike Jones <[email-masked]>
Date: Tue, 22 Oct 2019 16:04:47 +0000

OK, I now understand that you’re talking about the algorithm to generate “k” – not the signature algorithm.  I’ll add text suggesting using a deterministic method to generate “k”.

                                                       -- Mike

Sent: Tuesday, October 22, 2019 8:15 AM

                                                       -- Mike

Mike> What do you want this text to say?  I’m reluctant to use the text at https://tools.ietf.org/html/rfc8152#section-8.1<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8152%23section-8.1&data=02%7C01%7CMichael.Jones%40microsoft.com%7Ca948ad48ca7e4f9ac50d08d75702a9b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637073541256638088&sdata=EdlWIkUIFWNi1ruduhitG25xBKP7RfvTeoT%2BbF9rFAs%3D&reserved=0>, which says that “implementations SHOLUD use a deterministic algorithm”, which is misleading, in that it implies that there are many such algorithms that could be used.  In fact, exactly one is being specified.

---

From: Mike Jones <[email-masked]>
Date: Tue, 22 Oct 2019 16:17:15 +0000

Thanks again for the review, Neil.  My replies are inline, prefixed by “Mike>”.

                                                       -- Mike

From: COSE <[email-masked]> On Behalf Of Neil Madden
Sent: Friday, September 20, 2019 8:09 AM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]; [email-masked]; ivaylo petrov <[email-masked]>
Subject: Re: [COSE] [jose] 🔔 WGLC of draft-ietf-cose-webauthn-algorithms

Thanks for the reply, comments in-line marked with [NEM]:

On 20 Sep 2019, at 15:31, Jim Schaad <[email-masked]<mailto:[email-masked]>> wrote:

From: jose <[email-masked]<mailto:[email-masked]>> On Behalf Of Neil Madden
Sent: Friday, September 20, 2019 2:35 AM
To: ivaylo petrov <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] 🔔 WGLC of draft-ietf-cose-webauthn-algorithms

Thanks, I wasn't aware of this draft. It looks ok, just a few comments from me:

secp256k1 is mentioned in the context of signatures and the new ES256K JWS algorithm, but when it is registered in the JOSE Elliptic Curve registry it will also be usable for ECDH-ES encryption. The current draft mentions JOSE but only links to RFC 7515 (JWS). Is the intention that the curve be only used for signatures, or is it also intended for encryption?

[JLS] That is an interesting question.  Right now I would say that it is only for signatures, but it could be expanded to key agreement quite easily.  Is there any need for it or are you just speculating?  The big use I know of is bit coin which is only signatures and WebAuthn which is only signatures.

[NEM] As soon as it is registered as a JOSE elliptic curve it can be used for ECDH-ES, so the draft should make a statement one way or another as to whether this is intended rather than standardizing that usage by side-effect IMO.

Mike> Having thought about this some more, given that no one on the thread has presented an argument why secp256k1 should or should not be used with ECDH-ES, I now plan to make an explicit statement that whether it can or cannot be used is explicitly out of scope of this specification, and the topic could be covered by a future specification.  The question doesn’t have to be decided to achieve the goals of the current specification.

I'm glad RS1 is not being registered for JOSE, although I'm still a bit surprised that it is being registered (even as deprecated) for a standard as new as COSE. I can't find any justification in the linked WebAuthn or CTAP specs for why this algorithm needs to exist at all. Section 5.3 says that it needs to be registered because some WebAuthn TPM attestations use it, but the very same section says that the algorithm MUST NOT be used by COSE implementations (is a WebAuthn implementation not a COSE implementation?). If the normative language in the spec is obeyed then the algorithm will never be used and so the registered identifier isn't needed.

[JLS] For better or for worse, RS1 is already registered for JOSE, so that is the reason it is not registered here.

Ouch, I hadn't seen this. The WebCrypto group really did a number on the registry. Thankfully most of them (including RS1) are only registered for JWK usage and marked as Prohibited. (What does it even mean for things like "A128CBC" to be registered as a JWK "alg" value?)

My main point still stands that section 5.3 of the draft is self-contradictory as it says that the reason for registry is because some TPMs are using the algorithm but then also says that those implementations MUST NOT use the algorithm, negating the reason for registering it in the first place.

Mike> I will include the explanation arrived at in the discussion on the JOSE mailing list.

-- Neil

---

From: Neil Madden <[email-masked]>
Date: Wed, 23 Oct 2019 14:21:36 +0100

A couple of additional data points with regard to deterministic ECDSA (sorry Mike!):

 - While deterministic ECDSA is generally more secure, I gather that is not (yet?) a FIPS-approved nonce-generation method. So people with FIPS requirements won't be able to use it, sigh.

 - In the specific context of IoT where devices may be physically vulnerable, deterministic ECDSA and EdDSA have both been shown to be susceptible to fault attacks (see e.g. [1] and [2]). In particular, deterministic ECDSA may be *more* vulnerable to such attacks than randomized ECDSA. The linked papers offer some proposed countermeasures. For CWT usage, I believe including a fresh random "cti" claim in every signed token would reduce the effectiveness of these attacks dramatically as the signature generation will be effectively randomized while also being nonce reuse misuse-resistant.

If I was going to propose wording, perhaps something along these lines:

====
Implementations SHOULD use a deterministic algorithm to generate the ECDSA nonce, k, such as [RFC 6979]. In situations where devices are vulnerable to physical attacks, deterministic ECDSA has been shown to be susceptible to fault injection attacks [refs]. Where this is a possibility, implementations SHOULD implement appropriate countermeasures. Where there are specific certification requirements (such as FIPS approval), implementors should check whether deterministic ECDSA is an approved nonce generation method.
====

[1]: https://research.kudelskisecurity.com/2017/10/04/defeating-eddsa-with-faults/ <https://research.kudelskisecurity.com/2017/10/04/defeating-eddsa-with-faults/> 
[2]: https://eprint.iacr.org/2017/1014.pdf <https://eprint.iacr.org/2017/1014.pdf> 

--
 <http://www.forgerock.com/>	Neil Madden
Security Director  |  ForgeRock
e [email-masked] <mailto:[email-masked]>
web https://www.forgerock.com <http://www.forgerock.com/>

> On 22 Oct 2019, at 16:14, Jim Schaad <[email-masked]> wrote:
> 
> From: Mike Jones <[email-masked] <mailto:[email-masked]>> 
> To: Jim Schaad <[email-masked] <mailto:[email-masked]>>; 'cose' <[email-masked] <mailto:[email-masked]>>
> From: Jim Schaad <[email-masked] <mailto:[email-masked]>> 
> To: 'cose' <[email-masked] <mailto:[email-masked]>>
> Please include text related to deterministic ECDSA in this text.
>  
> Mike> What do you want this text to say?  I’m reluctant to use the text at https://tools.ietf.org/html/rfc8152#section-8.1 <https://tools.ietf.org/html/rfc8152#section-8.1>, which says that “implementations SHOLUD use a deterministic algorithm”, which is misleading, in that it implies that there are many such algorithms that could be used.  In fact, exactly one is being specified.
>  
> _______________________________________________
> COSE mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/cose <https://www.ietf.org/mailman/listinfo/cose>

---

From: Mike Jones <[email-masked]>
Date: Wed, 23 Oct 2019 19:20:22 +0000

Don’t apologize.  You provided proposed wording, which is extremely helpful!

                                                       Thanks Neil,
                                                       -- Mike

From: Neil Madden <[email-masked]>
Sent: Wednesday, October 23, 2019 6:22 AM
To: Jim Schaad <[email-masked]>
Cc: Mike Jones <[email-masked]>; cose <[email-masked]>; [email-masked]
Subject: Re: [COSE] 🔔 WGLC of draft-ietf-cose-webauthn-algorithms

====

[1]: https://research.kudelskisecurity.com/2017/10/04/defeating-eddsa-with-faults/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fresearch.kudelskisecurity.com%2F2017%2F10%2F04%2Fdefeating-eddsa-with-faults%2F&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cdcdbe24007c54a9ff34b08d757bbf158%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637074338381682694&sdata=32po778mehZquVzzUvWCY6zILSaSa9LsVfEbjIExSZE%3D&reserved=0>
[2]: https://eprint.iacr.org/2017/1014.pdf<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Feprint.iacr.org%2F2017%2F1014.pdf&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cdcdbe24007c54a9ff34b08d757bbf158%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637074338381692694&sdata=zko7f8Kur0aRA4wnNGsMJoxhU4XoQg2jm0pUwoGUHSA%3D&reserved=0>

--
[https://drive.google.com/a/forgerock.com/uc?id=1ZTkSK458MKu3N5i-lczIaaITaTV4znhV&export=download]<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.forgerock.com&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cdcdbe24007c54a9ff34b08d757bbf158%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637074338381692694&sdata=TdXp1zlBwft8dTzU7QWIyfIXV8LXVm6r5hZBvFPzO38%3D&reserved=0>
Neil Madden
Security Director  |  ForgeRock
e [email-masked]<mailto:[email-masked]>
web https://www.forgerock.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.forgerock.com%2F&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cdcdbe24007c54a9ff34b08d757bbf158%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637074338381702713&sdata=WrPKhjnvg4JLL5lu%2BCEO4P%2FMpTt1k4pUpeuQ%2Bt7woPE%3D&reserved=0>

On 22 Oct 2019, at 16:14, Jim Schaad <[email-masked]<mailto:[email-masked]>> wrote:

                                                       -- Mike

Mike> What do you want this text to say?  I’m reluctant to use the text at https://tools.ietf.org/html/rfc8152#section-8.1<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8152%23section-8.1&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cdcdbe24007c54a9ff34b08d757bbf158%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637074338381702713&sdata=eanVngXAzr%2FrDPZE2rB5KhnlIv0wrSEN4LXb%2BCWU8L0%3D&reserved=0>, which says that “implementations SHOLUD use a deterministic algorithm”, which is misleading, in that it implies that there are many such algorithms that could be used.  In fact, exactly one is being specified.

[JLS] I was unaware that there is only one possible deterministic algorithm, any keyed hash algorithm can be used to generate the deterministic ‘k’ to be used for the signature algorithm.  There is not a requirement that the secret value be the private key for the signature key pair, one could generate a private value just for that purpose.  Independent of that, the default ECDSA algorithm specifications all say use a random value of ‘k’ rather than a deterministic value and the use of the deterministic value is far more secure.
_______________________________________________
COSE mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cose<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcose&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cdcdbe24007c54a9ff34b08d757bbf158%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637074338381702713&sdata=EdmrXriv5X9rr6B1NT9donpBInd8CgcMO0JnmKymIG4%3D&reserved=0>

---

From: Mike Jones <[email-masked]>
Date: Thu, 24 Oct 2019 23:12:34 +0000

These issue resolutions have been incorporated in https://tools.ietf.org/html/draft-ietf-cose-webauthn-algorithms-02.  Thanks again for your useful review!

                                                                -- Mike

From: Mike Jones
Sent: Tuesday, October 22, 2019 9:03 AM
To: Jim Schaad <[email-masked]>; 'cose' <[email-masked]>
Cc: [email-masked]
Subject: RE: [COSE] 🔔 WGLC of draft-ietf-cose-webauthn-algorithms

                                                       -- Mike

To: Mike Jones <[email-masked]<mailto:[email-masked]>>; 'cose' <[email-masked]<mailto:[email-masked]>>

                                                       -- Mike

Mike> Ditto

Mike2> OK

Mike> OK

New Items:

Mike> Will do

Mike> Sure

Jim

Dear all,

Thank you,

- Matthew and Ivaylo
COSE Chairs

---

From: Mike Jones <[email-masked]>
Date: Thu, 24 Oct 2019 23:13:43 +0000

-- Mike

From: Mike Jones
Sent: Tuesday, October 22, 2019 9:17 AM
To: Neil Madden <[email-masked]>; Jim Schaad <[email-masked]>
Cc: [email-masked]; [email-masked]; ivaylo petrov <[email-masked]>
Subject: RE: [COSE] [jose] 🔔 WGLC of draft-ietf-cose-webauthn-algorithms

                                                       -- Mike

From: COSE <[email-masked]<mailto:[email-masked]>> On Behalf Of Neil Madden
Sent: Friday, September 20, 2019 8:09 AM
To: Jim Schaad <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; ivaylo petrov <[email-masked]<mailto:[email-masked]>>
Subject: Re: [COSE] [jose] 🔔 WGLC of draft-ietf-cose-webauthn-algorithms

-- Neil

---

From: Mike Jones <[email-masked]>
Date: Thu, 24 Oct 2019 23:14:37 +0000

These issue resolutions have been incorporated in https://tools.ietf.org/html/draft-ietf-cose-webauthn-algorithms-02.  Thanks again for your useful review, and especially for providing wording!

                                                                -- Mike

From: Mike Jones
Sent: Wednesday, October 23, 2019 12:20 PM
To: Neil Madden <[email-masked]>; Jim Schaad <[email-masked]>
Cc: cose <[email-masked]>; [email-masked]
Subject: RE: [COSE] 🔔 WGLC of draft-ietf-cose-webauthn-algorithms

                                                       Thanks Neil,
                                                       -- Mike

From: Neil Madden <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, October 23, 2019 6:22 AM
To: Jim Schaad <[email-masked]<mailto:[email-masked]>>
Cc: Mike Jones <[email-masked]<mailto:[email-masked]>>; cose <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [COSE] 🔔 WGLC of draft-ietf-cose-webauthn-algorithms

====

                                                       -- Mike

---

From: Mike Jones <[email-masked]>
Date: Thu, 24 Oct 2019 23:16:02 +0000

These issue resolutions have been incorporated in https://tools.ietf.org/html/draft-ietf-cose-webauthn-algorithms-02.  Thanks again for your useful reviews!

				-- Mike

-----Original Message-----
From: Benjamin Kaduk <[email-masked]> 
Sent: Monday, September 23, 2019 10:37 AM
To: Neil Madden <[email-masked]>
Cc: Mike Jones <[email-masked]>; Jim Schaad <[email-masked]>; [email-masked]; [email-masked]; ivaylo petrov <[email-masked]>
Subject: Re: [jose] 🔔 WGLC of draft-ietf-cose-webauthn-algorithms

On Sat, Sep 21, 2019 at 11:47:53AM +0100, Neil Madden wrote:
> On 21 Sep 2019, at 01:44, Mike Jones <Michael.Jones=[email-masked]> wrote:
> > 
> > RSA SHA-1 is used by TPMs, which produce attestations used by W3C WebCrypto.  That can’t be changed.  That’s why an algorithm identifier is needed for it.  It’s use is prohibited for new applications but TPMs are an existing application.  I can work to make this clearer when resolving the WGLC comments.
> 
> I think clarifying the text along those lines would help a lot. It is worrying that these TPMs have to continue to use a known weak signature method and they apparently cannot be changed, but at least with the MUST NOT you give people a clue that this is something they want to run away from pretty quickly.
> 
> >  
> > As for secp256k1, the “ES256K” algorithm is registered, whose definition is “ECDSA using secp256k1 curve and SHA-256”.  That’s only for signing.  The draft is currently silent on whether the registered curve can also be used for other things.  I think that’s how it should be, unless there are security reasons to the contrary.
> 
> Well section 4.4 registers secp256k1 as a JWK Elliptic Curve so it will be usable with the existing ECDH-ES family of algorithms without any additional registrations. There *are* some security concerns about using secp256k1 outside of signatures - see e.g. [1] which lists the theoretical problems with the curve. In particular, fast implementations of scalar multiplication (used in ECDH) for secp256k1 are not constant time making it a riskier choice for ECDH than for ECDSA. As far as I'm aware though, that just puts it in the same category as the other NIST/SECG standard curves that are already registered for JOSE. So I'm not against it being available for both JWS and JWE usage, I'd just like that to be an explicit documented decision rather than an accident.

I'm also inclined to agree that making an explicit statement is preferred; I have less-strong feelings about whether that statement is to allow or disallow the usage.

-Ben

> [1]: 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcryp
> to.stackexchange.com%2Fa%2F68286%2F26028&amp;data=02%7C01%7CMichael.Jo
> nes%40microsoft.com%7Cfa969966b9eb45afa24808d7404cbdca%7C72f988bf86f14
> 1af91ab2d7cd011db47%7C1%7C0%7C637048570666413397&amp;sdata=HWxwbJIZZfN
> gHhyX1GIJ8%2FahQC8FsrMH0SnLxrrX%2BDo%3D&amp;reserved=0 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcry
> pto.stackexchange.com%2Fa%2F68286%2F26028&amp;data=02%7C01%7CMichael.J
> ones%40microsoft.com%7Cfa969966b9eb45afa24808d7404cbdca%7C72f988bf86f1
> 41af91ab2d7cd011db47%7C1%7C0%7C637048570666413397&amp;sdata=HWxwbJIZZf
> NgHhyX1GIJ8%2FahQC8FsrMH0SnLxrrX%2BDo%3D&amp;reserved=0>
> 
> -- Neil

> jose mailing list
> [email-masked]
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fjose&amp;data=02%7C01%7CMichael.Jones%
> 40microsoft.com%7Cfa969966b9eb45afa24808d7404cbdca%7C72f988bf86f141af9
> 1ab2d7cd011db47%7C1%7C0%7C637048570666413397&amp;sdata=Q6DuWQduwTgUYcx
> OnZ7znz0bwfMSGYdCeSSb1PZiRjs%3D&amp;reserved=0