Carsten, I went around on this several times and ended up deciding that it was not necessary to have the nils in these locations. It took me a bit to reconstruct my reasoning but here it is.
The most important thing about this structure is that one needs to ensure that both sides will produce the same string of bytes so that they can get the same result in the end. If one looks at this criteria, then the nils are not needed at all as the order of items is going to be the only significant thing to be considered. This means that an attacker could, potentially, change the tag on a transported field but the order of fields can still be same and the resulting structure would be the same. Note that one cannot combine two different fields together as the CBOR encoding provides a length for each of the bstr or int elements. This means that the number of items that must be extant cannot be changed either. So the question is can one mount an attack by changing the tag on a label? This cannot happen if the fields content is specified by the application protocol. I.e. if the content of the identify field is a constant defined by the application then it cannot be shifted by an attacker if it is not transported. And it would need to be of a specific value or form if it were to be transported. If I specify a nonce and send a message, it gets moved to the identify field and no other identify field is going to be specified by the application. Then you would end up with the same value at the end. However, if the application has specified that the identity or field is to be used in some specific manner, the resulting set of fields would not be of the correct form or would not be available to be used correctly. Two examples, if the nonce was moved it would not be available to be used in a response message were the application to say that the partyU nonce is moved to the partyV nonce in the return message. If the identity field is used as part of the trust decision, a value moved from the nonce field. Then the identity is unlikely to be of a valid form as input to the trust decision and thus there would be a failure at a later point. In short, I don't believe that we need to fill in the space where one of these fields is not present as I have not been able to see how it will be usable as realistic attack vector. Jim > -----Original Message----- > From: COSE [mailto:[email protected]] On Behalf Of Carsten Bormann > Sent: Friday, June 10, 2016 12:23 AM > To: [email protected] > Subject: [COSE] PartyInfo > > Maybe a minor nit, but shouldn't be > > PartyInfo = ( > ? nonce : bstr / int, > ? identity : bstr, > ? other : bstr, > ) > > better be done as > > PartyInfo = ( > nonce : bstr / int / nil, > identity : bstr / nil, > ? other : bstr, > ) > > (This is used in an array context, so any non-final optionals create a > potential for > mixup.) > > While the attack surface of any confusion that can be created here is rather > small, I don't think we have to "save those bytes". > > Grüße, Carsten > > PS.: Yes, this could also be done as: > > > PartyInfo = ( > nonce : bstr / int / nil, > ? (identity : bstr / nil, > ? other : bstr), > ) > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
