On 2014-12-18 15:59, Breno de Medeiros wrote:
The assumption here is that WebCrypto and JOSE consistency in crypto specification is the greatest possible good. I challenge that assumption. The security requirements for the two solutions are not the same. So convergence will come either at the cost of flexibility for WebCrypto or at the cost of an unnecessarily flexible (and thus with greater potential for insecure usage) JOSE specification. I think agreeing that we are solving different problems and need to come up with different solutions is the best outcome.
That's great but I guess there are max 10 people on the planet who fully understands the rationale for supporting AES-CBC in WebCrypto but not in JOSE. The other problem, that everybody have to invent their own algorithm identifiers like S256 (for SHA-256) indicates that the JOSE WG has more work to do. Anders
On Dec 18, 2014 4:18 AM, "Harry Halpin" <[email protected] <mailto:[email protected]>> wrote: On 12/18/2014 12:12 AM, John Bradley wrote: > I wouldn't say that it counts for nothing. > > JOSE dosen't controll all the other crypto things in the world. Our stand at-least discourages people from doing insecure crypto on the wire with JWE. > > Controlling what other things people do with WebCrypto is out of scope for us. > > The best we can hope for is that people will at-least wonder why we took the stand we did and might think twice about non authenticated encryption. To be clear, we are hoping there would be a "high-level" API that would default to authenticated encryption. However, the level of abstraction for WebCrypto and JOSE are different. Nonetheless, it was the editor from Google, who argued most convincingly for not adopting JOSE IDs directly and the WG agreed with him. Furthermore, Mike Jones was in our WG and we discussed with him, he agreed. We do have conversion tables and use/consume JOSE keys, so we do think that given the differences between the API and JOSE's level of abstraction, the split in IDs is reasonable. The WebCrypto API is *not* a this point supposed to enforce protocol best practices, but assumes you know what you are doing. If you have suggestions for how a "high level" API, please do send it to me, we're collecting advice now. If Breno has an issue with a fellow Googler's stance on related work, perhaps some internal co-ordination would help :) cheers, harry > > John B. > >> On Dec 17, 2014, at 8:03 PM, Richard Barnes <[email protected]> wrote: >> >> On Tue, Dec 9, 2014 at 7:01 PM, Breno de Medeiros <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> wrote: >> >> >> On Tue, Dec 9, 2014 at 4:00 PM, Richard Barnes <[email protected] <mailto:[email protected] <mailto:[email protected]>>> wrote: >> Because if you don't, then WebCrypto will come along and add things like "A128CBC" and "A128CTR". >> >> That's hardly a good argument to add support to insecure use cases. >> >> I'm not arguing for it, I'm just saying that it's already happened. So JOSE's principled stand amounted to nothing. >> >> --Richard >> >> >> >> >> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#jwk-mapping-alg <https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#jwk-mapping-alg> >> >> On Tue, Dec 9, 2014 at 6:28 PM, Breno de Medeiros <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> wrote: >> >> >> On Tue, Dec 9, 2014 at 3:19 PM, Jim Schaad <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> wrote: >> We can also blame JOSE for deciding that only authenticated encryption algorithms should be used. >> >> Apart from supporting legacy use cases there's no reason to support non-authenticated encryption. But given that JOSE is a new technology, why should it support legacy use cases? >> >> >> >> >> From: jose [mailto:[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>] On Behalf Of Richard Barnes >> Sent: Tuesday, December 09, 2014 2:45 PM >> To: Anders Rundgren >> Cc: [email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> >> Subject: Re: [jose] WebCrypto/JOSE Algorithm IDs = Mess >> >> Blame JOSE for using aggregated identifiers. Blame WebCrypto for using deaggregated identifiers. >> Or just accept that the two camps refused to align, and make yourself a translation table. >> http://dxr.mozilla.org/mozilla-central/source/dom/crypto/KeyAlgorithmProxy.cpp#123 <http://dxr.mozilla.org/mozilla-central/source/dom/crypto/KeyAlgorithmProxy.cpp#123> >> >> On Tue, Dec 9, 2014 at 5:36 AM, Anders Rundgren <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> wrote: >> This is just a complaint from a user. >> It is sad that the algorithm IDs never were aligned. >> >> A few examples of what I stumbled into: >> >> 1. AES-CBC doesn't exist in JOSE >> >> 2. WebCrypto: {name: 'RSA-OAEP', hash: {name: 'SHA-256'}} = JOSE: RSA-OAEP-256 >> >> 3. Let's say that you wanted to create a protocol that would hash something and then you would supply an algorithm ID, >> then what would use? AFAICT, there's nothing that would be aligned with JOSE (it doesn't need hash). Using "SHA-256"? >> Well, then you would be mixing algorithm IDs from different dictionaries which sounds like a rather ugly hack. >> >> That x5c elements are (unlike everything else binary) not base64url-encoded also feels a bit strange but I guess this a legacy thing. >> >> Anders >> >> _______________________________________________ >> jose mailing list >> [email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> >> https://www.ietf.org/mailman/listinfo/jose <https://www.ietf.org/mailman/listinfo/jose> >> >> >> _______________________________________________ >> jose mailing list >> [email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> >> https://www.ietf.org/mailman/listinfo/jose <https://www.ietf.org/mailman/listinfo/jose> >> >> >> >> -- >> --Breno >> >> >> >> >> -- >> --Breno >> _______________________________________________ >> jose mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/jose > > > > > _______________________________________________ > jose mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/jose >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
