True. You could also do that here. But I think my scheme still works, and is a little simpler.
On Tuesday, June 11, 2013, Jim Schaad wrote: > 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] <javascript:_e({}, 'cvml', > '[email protected]');>] > *Sent:* Tuesday, June 11, 2013 3:41 PM > *To:* Jim Schaad > *Cc:* [email protected] <javascript:_e({}, 'cvml', '[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.**** > > **** > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
