Ah. I see. Guess that's what the '.' character is for in the base64
version. :)
In this version, you could just require that the JWS protected header have
no trailing white space. Then, if you the attacker trims any characters,
it won't be valid.
Senders MUST NOT create a header with trailing white space. Recipient
MUST (1) check that the header is valid JSON, and (2) check that there is
no trailing white space in the header string.
I think this is a flavor of your (2).
On Tuesday, June 11, 2013, Jim Schaad wrote:
> Yes – you are still not understanding the problem.****
>
> ** **
>
> There is an interesting issue that comes up in computing hash values of
> multiple things which are concatenated together. This issue is that it is
> possible to move items from one thing to an adjacent thing and still get
> the same hash value.****
>
> ** **
>
> Thus if field1=”aaa” and field2=”bbb” you get “aaabbb” as the value being
> hashed.****
>
> If field1=”aa” and field2=”abbb” you still get the same “aaabbb” as the
> value being hashed but different ideas of what the two fields are.****
>
> ** **
>
> There are three classic ways to deal with this problem:****
>
> ** **
>
> **1. **Use length prefix on each field – this is the ASN.1 encode
> it version****
>
> **2. **Use fields that are well defined in terms of delimiters****
>
> **3. **Put in separation characters which are not allowed in either
> field.****
>
> ** **
>
> I once tried to argue that this is what we should do and ended up with the
> following: Method one was not considered acceptable, method two was not
> possible given the current state of JSON parsers, method three is what we
> currently do.****
>
> ** **
>
> JSON parsers allow for indefinite amounts of whitespace following a JSON
> object so that will always be a problem. Additionally there are JSON
> parsers which believe they can stop parsing and not produce an error once
> it has fully built a top level object. Thus they consider the string
> ‘{“a”:“b”}FRED” to be something that can be successfully parsed.****
>
> ** **
>
> This allows for an attacker to move items from the content to the
> protected string unless there is an externally imposed rule about what
> happens for trailing characters after the protected content.****
>
> ** **
>
> Jim****
>
> ** **
>
> ** **
>
> *From:* Richard Barnes [mailto:[email protected] <javascript:_e({}, 'cvml',
> '[email protected]');>]
> *Sent:* Tuesday, June 11, 2013 12:51 PM
> *To:* Jim Schaad
> *Cc:* [email protected] <javascript:_e({}, 'cvml', '[email protected]');>
> *Subject:* Re: Issue #23 - Make crypto indepenent of binary encoding****
>
> ** **
>
> 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" }****
>
>
>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
