On 12/18/2014 03:59 PM, 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.
+1. Glad to see folks are concuring. Again, I think a high-level API built on top of Web Crypto that matches more near a JOSE use-cases is possible and we can pull that off, but right now W3C is still pushing out WebCrypto as it stands as the WG agreed with Ryan, who has been doing a great job. Nonetheless, the work the WebCrypto have done so far on matching IDs should help, see here: https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#jwk-mapping Having the JOSE WG double-check that would be great and make sure it maps latest JOSE versions. Just email [email protected] or (better) at a comment to our bugzilla: https://www.w3.org/Bugs/Public/enter_bug.cgi?product=Web%20Cryptography&component=Web%20Cryptography%20API%20Document > On Dec 18, 2014 4:18 AM, "Harry Halpin" <[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]>> wrote: >>>> >>>> >>>> On Tue, Dec 9, 2014 at 4:00 PM, Richard Barnes <[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]>> wrote: >>>> >>>> >>>> On Tue, Dec 9, 2014 at 3:19 PM, Jim Schaad <[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]>] >> On Behalf Of Richard Barnes >>>> Sent: Tuesday, December 09, 2014 2:45 PM >>>> To: Anders Rundgren >>>> Cc: [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]>> >> 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]> >>>> https://www.ietf.org/mailman/listinfo/jose < >> https://www.ietf.org/mailman/listinfo/jose> >>>> >>>> >>>> _______________________________________________ >>>> jose mailing list >>>> [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] >>>> 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
