Subject: [jose] Direct Compact Serialization

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 25 Mar 2015 06:14:27 -1000

The revised draft is now up. It is essentially a one pager. Which
turns out to be five with the boiler plate and IANA section.

http://tools.ietf.org/html/draft-hallambaker-joseunencoded-01

2. Serialization

   In the JWS Direct Serialization, no JWS Unprotected Header is used.
   In this case, the JOSE Header and the JWS Protected Header are the
   same.

   In the JWS Direct Serialization, a JWS is represented as the
   concatenation:

   UTF8(JWS Protected Header)) || '.' || (JWS Payload) || '.' ||

   (JWS Signature)

   The calculation of the signature is performed over the octet sequence
   that corresponds to the concatenation:

   UTF8(JWS Protected Header)) || '.' || (JWS Payload) || '.'

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 26 Mar 2015 03:44:40 +0900

Thanks.

So, is it correct to understand that this is intended to the environment
that JWS Payload will not be munched by the processing middle-ware etc.?

Also, JWS Payload may include linefeed etc. So, the compact serialization
may appear like:

{"alg":"ES256"}.{"iss":"joe",
 "exp":1300819380,
 "http://example.com/is_root":true}.eyJhbGciOiJQUzI....etc.etc.etc...OJ-LWr

Is it correct?

Best,

Nat

2015-03-26 1:14 GMT+09:00 Phillip Hallam-Baker <[email-masked]>:

> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: Mike Jones <[email-masked]>
Date: Wed, 25 Mar 2015 19:07:17 +0000

Thanks for writing this, Phillip.  I’ll repeat a few comments that I think I made to you in person.

First, I would suggest that any extension that changes the signature computation include syntax for declaring that it’s been changed.  For instance, it could include a header parameter value like “b64”: false – with the meaning that the payload value is used as-is in the signature computation, rather than being base64url encoded.

Putting everything out there, I know that some have also asked for a compact serialization where the signature is computed only over the payload – where all the header parameters are unprotected.  This would be particularly useful for detached payloads, because then there’s no need to prepend BASE64URL(ASCII(JWS Protected Header)) || ‘.’ to payload before computing the signature.  For truly huge payloads, not having to make a copy of it to do the concatenation can be an implementation advantage.  (Matt Miller has told me about some of his experiences related to this in JavaScript.)  I would also want this property to be explicitly declared in some manner.

To Nat’s question, I would hope that this would normally be used with detached payloads, where the JWS communicated would look like this: Header..Signature – thus avoiding the question of how to represent payloads that are not URL-safe.  The answer would simply be “the application knows how to do this”.

I think that it’s at least worth considering an extension spec that enables these options, as it could broaden the applicability of JOSE to additional application contexts.

I’ll note that when the working group previously considered this question, in the context of http://trac.tools.ietf.org/wg/jose/trac/ticket/23.  The thing that makes me personally willing to consider such an extension at this point is that not having to copy a huge detached payload to do the crypto could be the difference between JWS being applicable and not.

Thanks for starting this discussion, Philip.

                                                            -- Mike

From: jose [mailto:[email-masked]] On Behalf Of Nat Sakimura
Sent: Wednesday, March 25, 2015 1:45 PM
To: Phillip Hallam-Baker
Cc: [email-masked]
Subject: Re: [jose] Direct Compact Serialization

Thanks.

So, is it correct to understand that this is intended to the environment that JWS Payload will not be munched by the processing middle-ware etc.?

Also, JWS Payload may include linefeed etc. So, the compact serialization may appear like:

 "exp":1300819380,

Is it correct?

Best,

Nat

2015-03-26 1:14 GMT+09:00 Phillip Hallam-Baker <[email-masked]<mailto:[email-masked]>>:
The revised draft is now up. It is essentially a one pager. Which
turns out to be five with the boiler plate and IANA section.

2. Serialization

   (JWS Signature)

_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 25 Mar 2015 14:10:27 -0500

So what happens if my JWS Payload contains a "." character in it?

> -----Original Message-----
> From: jose [mailto:[email-masked]] On Behalf Of Phillip
Hallam-Baker
> Sent: Wednesday, March 25, 2015 11:14 AM
> To: [email-masked]
> Subject: [jose] Direct Compact Serialization
> 
> The revised draft is now up. It is essentially a one pager. Which turns
out to be
> five with the boiler plate and IANA section.
>

---

From: Justin Richer <[email-masked]>
Date: Wed, 25 Mar 2015 14:21:43 -0500

I’m also confused by this problem. Why not use JSON Text Sequences instead for this use case?

http://www.rfc-editor.org/rfc/rfc7464.txt

 — Justin

> On Mar 25, 2015, at 2:10 PM, Jim Schaad <[email-masked]> wrote:
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 25 Mar 2015 14:32:29 -0500

> So what happens if my JWS Payload contains a "." character in it?

Yes, this seems to be a problem.

You could fix it trivially by moving the signature ahead of the
payload in the serialization.  At the cost of having to buffer the
signature.

---

From: Mike Jones <[email-masked]>
Date: Wed, 25 Mar 2015 19:42:54 +0000

It's been my assumption that this option would only be used for detached payloads, in which the payload is transmitted and delimited in a way known to the application.

As a historical note, the signature comes last in the JWS Compact Serialization to enable computing it in a streaming manner, for algorithms where this is possible.

				-- Mike

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Wednesday, March 25, 2015 2:32 PM
To: Jim Schaad
Cc: Phillip Hallam-Baker; jose
Subject: Re: [jose] Direct Compact Serialization

You could fix it trivially by moving the signature ahead of the payload in the serialization.  At the cost of having to buffer the signature.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 25 Mar 2015 14:51:18 -0500

If this is *only* used for detached payloads, then that's fine, but
you then to define it as just that.  Otherwise you get the problem
that Jim identified.

  JWS Detached Signature =    UTF8(JWS Protected Header)) || '.' ||
(JWS Signature)

> As a historical note, the signature comes last in the JWS Compact Serialization to enable computing it in a streaming manner, for algorithms where this is possible.

Yes, that is the logical place for a signature.

---

From: Justin Richer <[email-masked]>
Date: Wed, 25 Mar 2015 14:21:43 -0500

— Justin

---

From: Justin Richer <[email-masked]>
Date: Wed, 25 Mar 2015 15:15:59 -0500

There’s also nothing stopping the header from having a “.” in it, though, especially if it’s a private header parameter as defined in JWS § 4.3, to say nothing of the values of these parameters. In fact, it is practically guaranteed that the “jku” parameter will have “.” in it several times over, since its value is a URI.

The “.” works in the b64-armored compact version of JOSE because it is a character that does not show up in the B64url alphabet, anywhere. So you can just do a string split, then decode, then parse. Really, really simple to write, but not the case here.

Unless there’s a way to easily separate the fields before they get to a parser, this is going to be problematic to deal with. You can’t really use a regular JSON parser because you don’t know where to start/stop the parsing. You can’t split it ahead of time like with the b64-armored version because of the issues discussed here. If you’ve got a streaming parser, you might be able to do this, but that’s going to be tricky; and if you’re doing a streaming parser, I think you’d be better off going with something like the JSON Text Stream thing that’s already got an RFC definition and a handful of implementations instead of something newly invented.

 — Justin

> On Mar 25, 2015, at 2:51 PM, Martin Thomson <[email-masked]> wrote:
>