Subject: [jose] JOSE in Python

From: Richard Barnes <[email-masked]>
Date: Thu, 15 Aug 2013 19:47:24 -0400

Hey all,

I've just pushed to GitHub a pretty complete JOSE library I've worked up in
Python.
<https://github.com/bifurcation/pyjose>

It supports pretty much all of the current specs, including:

-- JSON and compact serializations
-- Custom levels of header protection (all/none/some)
-- Multi-signer JWS and multi-recipient JWE
-- All JWA algorithms besides "none" (which should not be used anyway)

It successfully processes the examples in the current specs (except the
"ES512" one, which is broken), and successfully interoperates with itself
in all 288 different configurations ("alg" + "enc" + "protected").  I have
not yet tested it against any other JOSE implementations.

I also took this opportunity to start up a list of implementations on the
JOSE wiki.  Right now it's pretty short because I don't know of that many
off the top of my head.
<http://trac.tools.ietf.org/wg/jose/trac/wiki/WikiStart>

Comments / bugs welcome!

Thanks,
--Richard

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 16 Aug 2013 01:19:46 +0100

On 08/16/2013 12:47 AM, Richard Barnes wrote:
> interoperates with itself
> in all 288 different configurations 

288? Really?

Sounds like a fail to me to be honest.

S.

---

From: Mike Jones <[email-masked]>
Date: Fri, 16 Aug 2013 00:38:21 +0000

How is the ES512 example broken and what needs to be done to fix it?

Did you also verify that you can reproduce the key agreement result at http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-14#appendix-D?  I ask that because since it was published, three other implementations have produced the key value usEpwFIC_qrmBExntFwxMA rather than jSNmj9QK9ZGQJ2xg5_TJpA as published.

                                                                -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Thursday, August 15, 2013 4:47 PM
To: [email-masked]
Subject: [jose] JOSE in Python

Hey all,

I've just pushed to GitHub a pretty complete JOSE library I've worked up in Python.
<https://github.com/bifurcation/pyjose>

It successfully processes the examples in the current specs (except the "ES512" one, which is broken), and successfully interoperates with itself in all 288 different configurations ("alg" + "enc" + "protected").  I have not yet tested it against any other JOSE implementations.

I also took this opportunity to start up a list of implementations on the JOSE wiki.  Right now it's pretty short because I don't know of that many off the top of my head.
<http://trac.tools.ietf.org/wg/jose/trac/wiki/WikiStart>

Comments / bugs welcome!

Thanks,
--Richard

---

From: Richard Barnes <[email-masked]>
Date: Thu, 15 Aug 2013 22:12:29 -0400

> Sounds like a fail to me to be honest.

To break that out:
JWS: 36 = 12 JWS "alg" values * 3 header protection levels (some/all/none)
JWE: 288 = 16 "alg" values * 6 "enc" values * 3 header protection levels
Plus 2 for multi-signer and multi-recipient

So it seems I mis-counted, and there are actually 326 tests.  (I tried to
be thorough!)

If you tried to do something similar with CMS or IKE, I think the
combinatorics would be similar.  The TLS cipher suite registry is of
comparable size, and less organized (flat list instead of separate
parameters).

---

From: Brian Campbell <[email-masked]>
Date: Thu, 15 Aug 2013 21:52:17 -0600

> How is the ES512 example broken and what needs to be done to fix it?

Looks like maybe the encoded payload got hosed up somehow in the final
compact serialization. It's UGF5bG9hZA earlier in the example but the
final CS has it as
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ
- the signature validates for me with the former but not the latter.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 16 Aug 2013 12:13:39 -0400

Exactly.  Just need to change the example:

OLD:
"""
     eyJhbGciOiJFUzUxMiJ9
     .
     eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
     cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
     .
     AdwMgeerwtHoh-l192l60hp9wAHZFVJbLfD_UxMi70cwnZOYaRI1bKPWROc-mZZq
     wqT2SI-KGDKB34XO0aw_7XdtAG8GaSwFKdCAPZgoXD2YBJZCPEX3xKpRwcdOO8Kp
     EHwJjyqOgzDO7iKvU8vcnwNrmxYbSW9ERBXukOXolLzeO_Jn

"""
NEW:
"""
     eyJhbGciOiJFUzUxMiJ9
     .
     UGF5bG9hZA
     .
     AdwMgeerwtHoh-l192l60hp9wAHZFVJbLfD_UxMi70cwnZOYaRI1bKPWROc-mZZq
     wqT2SI-KGDKB34XO0aw_7XdtAG8GaSwFKdCAPZgoXD2YBJZCPEX3xKpRwcdOO8Kp
     EHwJjyqOgzDO7iKvU8vcnwNrmxYbSW9ERBXukOXolLzeO_Jn
"""

On Thu, Aug 15, 2013 at 11:52 PM, Brian Campbell <[email-masked]
> wrote:

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 16 Aug 2013 17:55:45 +0100

On 08/16/2013 03:12 AM, Richard Barnes wrote:
> comparable size,

So I need to go read the jose drafts again I guess but
if anything like 300 of anything are MTI then I reckon
that's a fail. (I also think the TLS ciphersuite registry
is an example of an IETF fail btw, maybe one that we
can improve on with TLS1.3 though hopefully;-)

S.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 16 Aug 2013 13:08:13 -0400

After some bug fixes in my code (to be committed soon), I agree with the
"usEpwFIC_qrmBExntFwxMA" group (so I disagree with the spec).

The input to SHA256 invocation inside of concat should be (in hex, line
breaks and comments for convenience):
00000001  # Counter
9e56d91d817135d372834283bf84269cfb316ea3da806a48f6daa7798cfe90c4 # Z
4131323847434d00000005416c69636500000003426f6200000080 # otherInfo

The otherInfo string is as presented in the spec
(0x4131323847434d00000005416c69636500000003426f6200000080).  And I assume
the folks matching the spec have the counter right.  So the error has to be
in how they're computing Z.  I tried to reproduce the error in a couple of
different ways, but none of them yielded the result in the spec.  I tried:
-- Starting the counter at 0 instead of 1 (yielded: lGZD7e8MGEHfW_miuv-PNg)
-- Instead of X, setting Z to X||Y (yielded: z0MmMHWswff5FElNp1-vQg)
-- Instead of X, setting Z to Y||X (yielded: P51_EtE5Fe7SJPpz2JgA0g)
-- Instead of X, setting Z to Y (yielded: PgBvVvYjmlP-XxNCO_w-ng)
-- Using "epk" for both private and public keys (yielded: header["epk"])
-- Using public key for both private and public keys (yielded:
_YWu37A851QNMpnI1KFCEg)

So, without some code to look at, I'm not sure how people are getting the
result in the spec.  Maybe it has to do with how the points are getting
decoded.

On Thu, Aug 15, 2013 at 8:38 PM, Mike Jones <[email-masked]>wrote:

>  How is the ES512 example broken and what needs to be done to fix it?  ***
> *
>
> ** **
>
> Did you also verify that you can reproduce the key agreement result at
> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-14#appendix-D?
> I ask that because since it was published, three other implementations have
> produced the key value usEpwFIC_qrmBExntFwxMA rather than
> jSNmj9QK9ZGQJ2xg5_TJpA as published.****
>
> ** **
>
>                                                                 -- Mike***
> *
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Richard Barnes
> *Sent:* Thursday, August 15, 2013 4:47 PM
> *To:* [email-masked]
> *Subject:* [jose] JOSE in Python****
>
> ** **
>
> Hey all,****
>
> ** **
>
> I've just pushed to GitHub a pretty complete JOSE library I've worked up
> in Python.  ****
>
> <https://github.com/bifurcation/pyjose>****
>
> ** **
>
> It supports pretty much all of the current specs, including:****
>
> ** **
>
> -- JSON and compact serializations****
>
> -- Custom levels of header protection (all/none/some)****
>
> -- Multi-signer JWS and multi-recipient JWE****
>
> -- All JWA algorithms besides "none" (which should not be used anyway)****
>
> ** **
>
> not yet tested it against any other JOSE implementations.  ****
>
> ** **
>
> off the top of my head.****
>
> <http://trac.tools.ietf.org/wg/jose/trac/wiki/WikiStart>****
>
> ** **
>
> Comments / bugs welcome!****
>
> ** **
>
> Thanks,****
>
> --Richard****
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 16 Aug 2013 13:09:31 -0400

On Fri, Aug 16, 2013 at 12:55 PM, Stephen Farrell <[email-masked]

> can improve on with TLS1.3 though hopefully;-)

There aren't 300 separate things you need to implement.  There are 12 for
JWS and 22 (16 + 6) for JWE.  And not all of those are MTI.

The big scary numbers just come from trying out the combinations.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 16 Aug 2013 14:10:40 -0400

To see what I mean, latest test results are here:
<http://pastebin.com/k2pfj34T>

On Fri, Aug 16, 2013 at 1:09 PM, Richard Barnes <[email-masked]> wrote:

> On Fri, Aug 16, 2013 at 12:55 PM, Stephen Farrell <
> [email-masked]> wrote:
>
>>
>>

---

From: Mike Jones <[email-masked]>
Date: Wed, 21 Aug 2013 22:34:16 +0000

Thanks guys.  I've corrected this in my editor's working copy.

                                                            -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Friday, August 16, 2013 9:14 AM
To: Brian Campbell
Cc: Mike Jones; [email-masked]
Subject: Re: [jose] JOSE in Python

OLD:
"""
     eyJhbGciOiJFUzUxMiJ9
     .

"""
NEW:
"""
     eyJhbGciOiJFUzUxMiJ9
     .
     UGF5bG9hZA
     .

On Thu, Aug 15, 2013 at 11:52 PM, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote: