Subject: [jose] WebCrypto/JOSE Algorithm IDs = Mess

From: Anders Rundgren <[email-masked]>
Date: Tue, 09 Dec 2014 11:36:52 +0100

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

---

From: Richard Barnes <[email-masked]>
Date: Tue, 9 Dec 2014 17:45:19 -0500

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

On Tue, Dec 9, 2014 at 5:36 AM, Anders Rundgren <
[email-masked]> wrote:

> 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"?
> 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-masked]
> https://www.ietf.org/mailman/listinfo/jose
>

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 9 Dec 2014 15:19:17 -0800

We can also blame JOSE for deciding that only authenticated encryption algorithms should be used.

From: jose [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Tuesday, December 09, 2014 2:45 PM
To: Anders Rundgren
Cc: [email-masked]
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

On Tue, Dec 9, 2014 at 5:36 AM, Anders Rundgren <[email-masked]> wrote:
This is just a complaint from a user.
It is sad that the algorithm IDs never were aligned.

Anders

---

From: Breno de Medeiros <[email-masked]>
Date: Tue, 9 Dec 2014 15:28:42 -0800

> 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?

-- 
--Breno

---

From: Richard Barnes <[email-masked]>
Date: Tue, 9 Dec 2014 19:00:19 -0500

Because if you don't, then WebCrypto will come along and add things like
"A128CBC" and "A128CTR".

https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#jwk-mapping-alg

---

From: Breno de Medeiros <[email-masked]>
Date: Tue, 9 Dec 2014 16:01:41 -0800

> Because if you don't, then WebCrypto will come along and add things like

That's hardly a good argument to add support to insecure use cases.

-- 
--Breno

---

From: Richard Barnes <[email-masked]>
Date: Wed, 17 Dec 2014 18:03:25 -0500

> 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

>>>> 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.
>>>>

---

From: John Bradley <[email-masked]>
Date: Wed, 17 Dec 2014 20:12:48 -0300

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-masked]> wrote:
> 
> On Tue, Dec 9, 2014 at 7:01 PM, Breno de Medeiros <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> On Tue, Dec 9, 2014 at 4:00 PM, Richard Barnes <[email-masked] <mailto:[email-masked]>> wrote:
> Because if you don't, then WebCrypto will come along and add things like "A128CBC" and "A128CTR".
> 
> 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-masked] <mailto:[email-masked]>> wrote:
> 
> 
> On Tue, Dec 9, 2014 at 3:19 PM, Jim Schaad <[email-masked] <mailto:[email-masked]>> wrote:
> 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-masked] <mailto:[email-masked]>] On Behalf Of Richard Barnes
> Cc: [email-masked] <mailto:[email-masked]>
> 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-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/jose <https://www.ietf.org/mailman/listinfo/jose>
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/jose <https://www.ietf.org/mailman/listinfo/jose>
> 
> 
> 
> -- 
> --Breno
> 
> 
> 
> 
> -- 
> --Breno

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 18 Dec 2014 07:10:46 +0100

> I'm not arguing for it, I'm just saying that it's already happened.  So JOSE's principled stand amounted to nothing.

+1

Authenticated encryption can be supported through other means on the wire like a MAC over
the encrypted container.

The opportunity defining a more complete set of on-the-wise algorithms is BTW not gone :-)
It is OK to continue saying that only a subset are endorsed for use with JWE.

Anders

---

From: Harry Halpin <[email-masked]>
Date: Thu, 18 Dec 2014 13:18:45 +0100

> 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

---

From: Breno de Medeiros <[email-masked]>
Date: Thu, 18 Dec 2014 06:59:01 -0800

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-masked]> 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.
> >
> > 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.
>
> <
> <
> [email-masked] <mailto:[email-masked]>>
> wrote:
> >> 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

---

From: John Bradley <[email-masked]>
Date: Thu, 18 Dec 2014 12:05:30 -0300

+1

> On Dec 18, 2014, at 11:59 AM, Breno de Medeiros <[email-masked]> 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-masked] <mailto:[email-masked]>> wrote:
> 
> 
> >> On Tue, Dec 9, 2014 at 7:01 PM, Breno de Medeiros <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> >>
> >>
> >> On Tue, Dec 9, 2014 at 4:00 PM, Richard Barnes <[email-masked] <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> >> 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-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> >>
> >>
> >> On Tue, Dec 9, 2014 at 3:19 PM, Jim Schaad <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> >> From: jose [mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>] On Behalf Of Richard Barnes
> >> Cc: [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >> 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-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >> 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>>
> >>
> >>
> >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >> 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

---

From: Harry Halpin <[email-masked]>
Date: Thu, 18 Dec 2014 19:56:45 +0100

> 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-masked]
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

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 19 Dec 2014 06:34:33 +0100

> 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

>     > 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.
>     >