Hi Jim, I am not talking about using AES-CBC and AES-CTR for encrypting a key. In the WebCrypto spec we support import/export of Key objects in JWK. Key objects in WebCrypto have an associated algorithm. WebCrypto supports AES-CTR and AES-CBC amongst many other things. What they are used for us up to the developer using WebCrypto.
It would be useful to be able to signal the WebCrypto algorithm in the JWK object when a Key is imported / exported (including when a Key is wrapped / unwrapped), hence a desire for a JWK "alg" value for every WebCrypto algorithm. Is there a problem with that ? ...Mark On Mon, Nov 11, 2013 at 10:36 AM, Jim Schaad <[email protected]> wrote: > Ii mean that I would like to prohibit anyone from registering a non-AEAD > algorithm. > > > > Good practice says that you should have an AEAD type algorithm for > encrypting a key so that it includes an integrity check as part of the > decryption process. Any such algorithm would qualify as an AEAD > algorithm. AES-CBC and AES-CTR do not have this property and therefore > should be prohibited from being registered and used. > > > > Jim > > > > > > *From:* Mark Watson [mailto:[email protected]] > *Sent:* Sunday, November 10, 2013 5:37 PM > *To:* Jim Schaad > *Cc:* Michael Jones; [email protected]; > [email protected] > > *Subject:* Re: [jose] #187: Define algorithm names for symmetric keys in > for JWK > > > > Jim, > > > > Do you mean that JOSE will not register non-AEAD algorithms in future or > that you would like to prohibit anyone from registering such algorithms ? > > > > In W3C WebCrypto we support import / export of a WebCrypto Key object in > JWK format and so I believe we will need alg / use / other attributes to > reflect all the algorithms / usages and other properties that WebCrypto Key > objects can have. > > > > ...Mark > > > > On Mon, Nov 11, 2013 at 5:30 AM, Jim Schaad <[email protected]> > wrote: > > While I agree this item is appropriately addressed as Won't Fix. I > disagree > that it would be appropriate for a later specification to define non-AEAD > algorithm for encryption purposes. If you feel it is appropriate then I > would like to make a change to the registration template to forbid it. > > Jim > > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf Of > > jose issue tracker > > Sent: Friday, November 08, 2013 4:46 PM > > To: [email protected]; > [email protected]; > > [email protected] > > Cc: [email protected] > > Subject: Re: [jose] #187: Define algorithm names for symmetric keys in > for > > JWK > > > > #187: Define algorithm names for symmetric keys in for JWK > > > > > > Comment (by [email protected]): > > > > A JOSE working group decision was made early on to only support > > authenticated encryption algorithms. Neither of AES CBC or AES CTR are > > authenticated encryption algorithms. > > > > There are registered algorithms for the composite AES-CBC-HMAC-SHA2 > > algorithms, which do provide authenticated encryption, which could be > used > > when applicable. > > > > That being said, it would be fine for non-JOSE specifications to define > and > > register the values A{128,192,256}CTR and A{128,192,256}CBC. For > instance, > > a W3C WebCrypto specification could do this. But I believe that JOSE > specs > > defining these values is out of scope. > > > > Therefore, I believe that this issue should be closed as "wontfix". > > > > -- > > -------------------------+---------------------------------------------- > > > -------------------------+--- > > > Reporter: | Owner: draft-ietf-jose-json-web- > > [email protected] | [email protected] > > Type: defect | Status: new > > Priority: minor | Milestone: > > Component: json-web- | Version: > > algorithms | Resolution: > > Severity: - | > > Keywords: | > > -------------------------+---------------------------------------------- > > > -------------------------+--- > > > > > Ticket URL: < > http://trac.tools.ietf.org/wg/jose/trac/ticket/187#comment:2> > > jose <http://tools.ietf.org/jose/> > > > > > _______________________________________________ > > jose mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/jose > > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
