+1 > On Dec 18, 2014, at 11:59 AM, Breno de Medeiros <[email protected]> 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. > > 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> > >> > >> <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> > >> > >> <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> > >> <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> > >> <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 > >> <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> > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
