No - that is not true.
CMS mitigates this attack by doing an indirect signing on the content. Thus the hash of the content is part of the signed attributes. Jim From: Richard Barnes [mailto:[email protected]] Sent: Tuesday, June 11, 2013 3:41 PM To: Jim Schaad Cc: [email protected] Subject: Re: Issue #23 - Make crypto indepenent of binary encoding Note: This is exactly how CMS mitigates this attack. The SignedAttrs DER structure is appended after the content, so DER parsing will fail if any octets are added or removed. On Tuesday, June 11, 2013, Richard Barnes wrote: 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.
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
