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
