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