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. On Dec 19, 2013, at 6:11 PM, Mike Jones <[email protected]> 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? > > Anyway, count me as not worried. > > -- Mike > > -----Original Message----- > From: jose [mailto:[email protected]] On Behalf Of Jim Schaad > Sent: Thursday, December 19, 2013 12:26 PM > To: [email protected] > 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 > > {'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 > > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
