On Mon, Nov 11, 2013 at 2:43 PM, John Bradley <[email protected]> wrote:
> Web Crypto should certainly implement the lower level functions like > AES-CBC. > > If we are talking about carrying keys in JWK and and wanting to mark the > key usage as AES-128-CBC that gets dangerous as people will assume that is > a valid JWE alg. > So, there could presumably be some way, within the registry, that we can indicate the algorithms that are "valid JWE algorithms" and those that have been added for other reasons. > > Can someone explain why you would need to create a JWK with a AES-CBC key > usage if AES-CBC is a primitive operation and not intended for JWE? > A Javascript application creates a WebCrypto Key object and indicates that it may only be used with AES-CBC. The Javascript application uses that key for encrypting some data - just raw encryption, not JWE. At some point, for whatever application-specific reason, the application wishes to export the Key, possibly wrapped with another Key, and send it somewhere else. We would like the usages (AES-CBC) to be preserved and having those indicated inside the JWK would achieve that. Equally, you could imagine a Key being delivered in JWK format and we want to avoid that the usages are tampered with. In the case that the key is delivered wrapped, then there may be policy in the UA that polices the Key usages and again ensures that the usages remain exactly what they are supposed to be. > > If there is a reason to have the key use of those algorithms specified in > a JWK it needs to be clear that they are not valid JWE algorithms. > Seems like that would be quite easy to make clear. ...Mark > John B. > > On Nov 10, 2013, at 8:47 PM, Mike Jones <[email protected]> > wrote: > > I disagree with Jim and John on this. WebCrypto is a much lower-level API > than JOSE. It intentionally enables the use of raw cryptographic > primitives. For instance, when building a JOSE implementation on > WebCrypto, one would definitely use WebCrypto’s support for AES CBC to > build the composite authenticated algorithmA128CBC-HS256. Likewise, one > would likely use WebCrypto’s AES EBC support to build A128KW. > > The high-level API that WebCrypto is talking about **is** a JOSE > implementation. We should do everything we can to encourage that being > specified and built. > > Therefore, I believe we want to encourage WebCrypto to use JWKs for their > key format. Yes – even for algorithms that aren’t inherently safe. > > I understand Jim’s desire not to sanction the use of non-authenticated > encryption algorithms **with JWE**. That doesn’t mean that we should > prohibit all JWKs that contains keys for algorithms use them. > > I believe the way to do this is to expend the definition of “Algorithm > Usage Location(s)” in the JSON Web Signature and Encryption Algorithms > registry > to permit additional usage locations. Currently they must be “alg” or > “enc”. Jim has already discussed a possible extension (key management for > MAC) in which other usage locations might be used. WebCrypto could define > another usage location for their registrations. Then we could prohibit the > registration of non-authenticated encryption algorithms for “enc”, but > allow them for other cases. > > Would that work for people? > > -- Mike > > *From:* Mark Watson [mailto:[email protected] <[email protected]>] > *Sent:* Sunday, November 10, 2013 7:09 PM > *To:* John Bradley > *Cc:* Jim Schaad; Mike Jones; > [email protected]; [email protected] > *Subject:* Re: [jose] #187: Define algorithm names for symmetric keys in > for JWK > > John, > > I want to check that we have a common context here. The W3C WebCrypto API > allows Javascript content on a web page to generate / agree / import keys > which can then be used to encrypt arbitrary data, using a variety of > algorithms (including non-AEAD ones). What data and what algorithms is up > to the page developer and WebCrypto provides *plenty* of rope with which > people can hang themselves, security-wise. There is an ambition to create a > different, higher-level, API which would not provide so much rope. What > we're working on now, though, is explicitly a low-level API with all the > caveats that go with that. > > WebCrypto also allows keys to be imported and exported in JWK format. > > Are you saying that JWK is not really intended for this application ? Or > that WebCrypto should not provide support for AES-CTR and AES-CBC at all > (and if it does you want no part in supporting that with JWK) ? > > What about an application that wants to pass keys around in JWK format and > then use those keys to decrypt some legacy data structure encrypted with > AES-CTR ? > > ...Mark > > > > On Mon, Nov 11, 2013 at 10:45 AM, John Bradley <[email protected]> wrote: > I agree that JOSE should not allow non-AEAD algorithms to be registered. > I understand some people will want them. > In the words of Nancy Reagan "Just say No" I think she also said > something about your brain on non-AEAD. Who an I to argue with Nancy:) > > John B. > > > On Nov 10, 2013, at 6:36 PM, 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] <[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 > > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
