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. 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? 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. 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]] > 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]] > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
