Still not understanding the problem. Things are still clearly separated in
JWS:
{
"protected_header": "eyJhbGciOiJSUzI1NiIsImtpZCI6ImppbSJ9"
"payload": "AQIDBA"
}
Here the protected_header is base64('{"alg":"RS256","kid":"jim"}') and the
payload is base64(0x01020304).
OLD:
Signature is
over: eyJhbGciOiJSUzI1NiIsImtpZCI6ImppbSJ9.eyJhbGciOiJSUzI1NiIsImtpZCI6ImppbSJ9
== 65 79 4a 68 62 47 63 69 4f 69 4a 53 55 7a 49 31 4e 69 49 73 49 6d 74 70
5a 43 49 36 49 6d 70 70 62 53 4a 39 2e 65 79 4a 68 62 47 63 69 4f 69 4a 53
55 7a 49 31 4e 69 49 73 49 6d 74 70 5a 43 49 36 49 6d 70 70 62 53 4a 39
NEW:
Signature is over: {"alg":"RS256","kid":"jim"}
== 01 02 03 04 7b 22 61 6c 67 22 3a 22 52 53 32 35 36 22 2c 22 6b 69 64 22
3a 22 6a 69 6d 22 7d 01 02 03 04
That is, just decode the two octet strings, convert the protected_header to
UTF-8, and concatenate them. (This extends the proposal to also get rid of
the "." in the middle, since it's not necessary. I updated the issue.)
No ambiguity.
--Richard
On Tue, Jun 11, 2013 at 3:16 PM, Jim Schaad <[email protected]> wrote:
> Yes, it is not a problem for JWE, however consider the case of JWS where
> there is no distinction between how the protected data and the content are
> processed.****
>
> ** **
>
> Jim****
>
> ** **
>
> ** **
>
> *From:* Richard Barnes [mailto:[email protected]]
> *Sent:* Tuesday, June 11, 2013 11:43 AM
> *To:* Jim Schaad
> *Cc:* [email protected]
> *Subject:* Re: Issue #23 - Make crypto indepenent of binary encoding****
>
> ** **
>
> I don't know what you mean by "the problem of things drifting back and
> forth". Let me try to be more concrete.****
>
> ** **
>
> Consider the following JWE:****
>
> ** **
>
> {****
>
> "header": { "alg": "dir" }****
>
> "protect":
> "eyJlbmMiOiAiQTEyOEdDTSIsICJraWQiOiAiY2VsdWkKDcOnYQoNCWzDoC1iYXMifQ"****
>
> ...****
>
> }****
>
> ** **
>
> The "protect" here is the encoding of the header '{"enc": "A128GCM",
> "kid": "celui\r\nça\r\n\tlà-bas"}' (hex=63 65 6C 75 69 0A 0D C3 A7 61 0A
> 0D 09 6C C3 A0 2D 62 61 73).****
>
> ** **
>
> In the current draft, the AAD for the AEAD is the base64-encoded version.
> The proposal here is just to make it the UTF-8 version, before
> base64-encoding instead of after:****
>
> ** **
>
> OLD:****
>
> AAD = eyJlbmMiOiAiQTEyOEdDTSIsICJraWQiOiAiY2VsdWkKDcOnYQoNCWzDoC1iYXMifQ *
> ***
>
> (== 65 79 4a 6c 62 6d 4d 69 4f 69 41 69 51 54 45 79 4f 45 64 44 54 53 49
> 73 49 43 4a 72 61 57 51 69 4f 69 41 69 59 32 56 73 64 57 6b 4b 44 63 4f 6e
> 59 51 6f 4e 43 57 7a 44 6f 43 31 69 59 58 4d 69 66 51)****
>
> ** **
>
> NEW: ****
>
> AAD = '{"enc": "A128GCM", "kid": "celui\r\nça\r\n\tlà-bas"}'****
>
> (== 7B 22 65 6E 63 22 3A 20 22 41 31 32 38 47 43 4D 22 2C 20 22 6B 69 64
> 22 3A 20 22 63 65 6C 75 69 0A 0D C3 A7 61 0A 0D 09 6C C3 A0 2D 62 61 73 22
> 7D)****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> On Tue, Jun 11, 2013 at 2:12 PM, Jim Schaad <[email protected]>
> wrote:****
>
> <not chair>****
>
> ****
>
> Richard,****
>
> ****
>
> I do not currently believe that this is a doable item. In order for me to
> believe otherwise you will need to give a concrete proposal about how to
> solve the problem of things drifting back and forth. Given the text****
>
> ****
>
> {xxx}\r\r\rThis is the body****
>
> ****
>
> How does one know where the dividing line between the JSON header and the
> body begins? Until this is completely solved what you propose is not
> doable and the current method of base64 encoding will be required.****
>
> ****
>
> Jim****
>
> ****
>
> ** **
>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
