Subject: [jose] signing an existing JWT

From: Dick Hardt <[email-masked]>
Date: Mon, 29 Oct 2012 08:57:11 -0700

Let's say we have created a JWE as such:
	
	headerOne.encryptedKeyOne.initializationVectorOne.ciphertextOne.integritityVectorOne

This is now the payload to a JWS. Rather than increasing the token size by 4/3 by URL safe base 64 encoding the payload (since it is already URL safe), it would be useful to have a JWS header parameter that indicates the payload was not re-encoded and does not need to be URL safe base 64 decoded.

As there are more periods than expected in a JWS, decoding would ignore all periods except the first and last one for separating out the header, payload and signature.

The indicating parameter would seem to be either "tip" or "cty". I'm still confused about the difference between the two parameters, so not sure which one is appropriate.

-- Dick

---

From: Axel Nennker <[email-masked]>
Date: Tue, 30 Oct 2012 01:10:08 +0100

An answer not related to the size issue which might be relevant regardless:
http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html

--Axel

2012/10/29 Dick Hardt <[email-masked]>

> This is now the payload to a JWS. Rather than increasing the token size by
> 4/3 by URL safe base 64 encoding the payload (since it is already URL
> safe), it would be useful to have a JWS header parameter that indicates the
> payload was not re-encoded and does not need to be URL safe base 64 decoded.
>
> As there are more periods than expected in a JWS, decoding would ignore
> all periods except the first and last one for separating out the header,
> payload and signature.
>
> The indicating parameter would seem to be either "tip" or "cty". I'm still
> confused about the difference between the two parameters, so not sure which
> one is appropriate.
>
> -- Dick
>
>
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 29 Oct 2012 19:14:46 -0700

Thanks Axel. I'm familiar with naive sign and encrypt issues (hopefully!)

As I reflected on my implementation, I have to include other parameters in my payload besides the JWT, so an optimization does not look simple. I can use POST here as well, so size is not as much of an issue as it is with a redirect over GET.

-- Dick

On Oct 29, 2012, at 5:10 PM, Axel Nennker <[email-masked]> wrote:

> An answer not related to the size issue which might be relevant regardless: http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html 
> 
> --Axel
>