Subject: [jose] JWK use in the absense of an algorithm value

From: "Jim Schaad" <[email-masked]>
Date: Thu, 19 Dec 2013 12:25:37 -0800

In trying to go through the issues with the WebCrypto group and the JOSE WG
dealing with the content of the use field.  I ended up with a problem that I
had not recognized as being an issue when talking to John in Berlin.  I want
to bring this issue up and see if anybody other myself is worried about it.

Consider the JWK

{'typ':'oct', 'use':'enc',"k":"GawgguFyGrWKav7AX4VKUg" }

We have stated that the value of 'enc' in this case can only be correctly
interpreted in the content of an algorithm restriction in the JWK as well.
In this case it is not possible for an importing function to change the
external 'enc' value to either 'encryption' or 'key-wrapping'.  This means
that an implementation that imports the key and does not keep it in a JWK
formation will potentially reject the key as being mal-formed.  Note that
this would not be an issue if we had both 'enc' and 'wrap' as key usages
because it would be unambigious.

Jim

---

From: Mike Jones <[email-masked]>
Date: Thu, 19 Dec 2013 21:11:14 +0000

If you're importing a key into a context where you don't know the algorithm to be used from context, then I'd recommend including an "alg" field.  (This isn't required, because sometimes you do know this from context.)  Do you have a specific scenario in mind where this approach wouldn't work?

Anyway, count me as not worried.

				-- Mike

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Thursday, December 19, 2013 12:26 PM
To: [email-masked]
Subject: [jose] JWK use in the absense of an algorithm value

In trying to go through the issues with the WebCrypto group and the JOSE WG dealing with the content of the use field.  I ended up with a problem that I had not recognized as being an issue when talking to John in Berlin.  I want to bring this issue up and see if anybody other myself is worried about it.

Consider the JWK

We have stated that the value of 'enc' in this case can only be correctly interpreted in the content of an algorithm restriction in the JWK as well.
In this case it is not possible for an importing function to change the external 'enc' value to either 'encryption' or 'key-wrapping'.  This means that an implementation that imports the key and does not keep it in a JWK formation will potentially reject the key as being mal-formed.  Note that this would not be an issue if we had both 'enc' and 'wrap' as key usages because it would be unambigious.

Jim

_______________________________________________
jose mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jose

---

From: Richard Barnes <[email-masked]>
Date: Fri, 27 Dec 2013 13:18:49 -0500

+1 to Mike's lack of worry.

On Thu, Dec 19, 2013 at 4:11 PM, Mike Jones <[email-masked]>wrote:

> If you're importing a key into a context where you don't know the
> algorithm to be used from context, then I'd recommend including an "alg"
> field.  (This isn't required, because sometimes you do know this from
> context.)  Do you have a specific scenario in mind where this approach
> wouldn't work?
>
> In trying to go through the issues with the WebCrypto group and the JOSE
> WG dealing with the content of the use field.  I ended up with a problem
> that I had not recognized as being an issue when talking to John in Berlin.
>  I want to bring this issue up and see if anybody other myself is worried
> about it.
>
> Consider the JWK
>

---

From: John Bradley <[email-masked]>
Date: Fri, 27 Dec 2013 17:48:05 -0300

If it is ambiguous then including the alg field is the correct thing.   It is not really that you care so much if the use is encryption or wrapping if the alg is the same(OK you should care a bit).  What you are trying to do is keep the same key from being used in two different encryption algorithms typically bulk encryption and wrapping tend to use different algs so separating bulk vs wrap is better than nothing but not as good as specifying the alg in my opinion.

John B.