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:17 AM
To: Neil Madden <[email protected]>; Jim Schaad <[email protected]>
Cc: [email protected]; [email protected]; ivaylo petrov <[email protected]>
Subject: RE: [COSE] [jose] πŸ”” WGLC of draft-ietf-cose-webauthn-algorithms

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

                                                       -- Mike

From: COSE <[email protected]<mailto:[email protected]>> On Behalf Of 
Neil Madden
Sent: Friday, September 20, 2019 8:09 AM
To: Jim Schaad <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; 
ivaylo petrov <[email protected]<mailto:[email protected]>>
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 protected]<mailto:[email protected]>> wrote:



From: jose <[email protected]<mailto:[email protected]>> On Behalf Of 
Neil Madden
Sent: Friday, September 20, 2019 2:35 AM
To: ivaylo petrov <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>
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
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose

Reply via email to