Subject: Re: [COSE] [jose] 🔔 WGLC of draft-ietf-cose-webauthn-algorithms
From: Mike Jones <[email-masked]>
To: Benjamin Kaduk <[email-masked]>, Neil Madden <[email-masked]>
Cc: Jim Schaad <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, ivaylo petrov <[email-masked]>
Date: Thu, 24 Oct 2019 23:16:02 +0000
List-Id: CBOR Object Signing and Encryption <cose.ietf.org>

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