During the IESG review of draft-ietf-cose-rfc8152bis-struct a DISCUSS was raised that it took a while to convince me was a real problem and I have been since looking at this to try and figure out if there were any good answers. Unfortunately I did not find anything that I really liked. So this is going to the list to try and get some type of resolution for the problem.
All of the structures start out the same * bstr w/ protected attributes * map w/ unprotected attributes * bstr w/ some type of content * Array of items above (i.e. recipients) or nothing For all but four of the COSE message structures, what goes into the second bstr is some type of cryptographically computed value and thus applying a countersignature to that value provides additional benefits. COSE_Signature has this layout, but it does not have any cryptographically computed values so the document describes putting a countersignature on this structure as being the same as adding a parallel signature. The last three structures have one additional bstr added so that you get * bstr w/ protected attributes * map w/ unprotected attributes * bstr w/ some type of content * bstr w/ cryptographic value * Array of items above (i.e. recipients) or nothing In these cases if you wanted to provide additional value with the countersignature you need to be computing it on the fourth value in the structure and not the third. This was correctly indicated for COSE_Mac and COSE_Mac0 in the current document, but it was not correctly indicated for COSE_Sign1. The following are the options that I have come up with so far: 1. Change the text so that it indicates that a countersignature on COSE_Sign1 does not provide a countersignature but only provides an additional signature as is currently done for the two MAC structures. This is going to be somewhat non-intuitive as a countersignature on a signature structure does not produce a countersignature. This is what my current code base does. 2. Change the countersignature algorithm to use the first and last bstr in the structure. This will change the behavior for countersignatures on COSE_Mac and COSE_Mac0, but I would not expect this to have any significant real world issues. Changing the algorithm does mean that any future structures defined for COSE (perhaps some type of combined signature/encryption algorithm) are going to need to be designed so that if a new bstr is added, it needs to ensure that the last one is where the cryptographic value is added to the structure. 3. Change the countersignature algorithm to use every bstr value in the structure. Again, this will change the algorithm for countersignatures on COSE_Mac and COSE_Mac0. The benefit is that every new item added is going to be included in the countersignature so you don't need to have a single value which contains all of the new cryptographic value. 4. Change the countersignature algorithm for COSE_Sign1, but leave it alone for the COSE_Mac and COSE_Mac0 structures. This has the benefit that a countersignature on a COSE_Sign1 produces the type of value one would expect, and it does not change what you get for the current MAC structures. The downside is that you suddenly need to look at the structure before you can do the validation in the cases where the fourth bstr is in the structure. An additional downside is that if a new structure is created with the extra bstr value, the validator will not know which of the two extraction algorithms is to be used. I don't have any preference between the options above. They all have good points and bad points. The first one is the easiest to implement as it would only require adding some text to the document. But the frisson between what one would expect a countersignature to be and what it is in actuality for a COSE_Sign1 is jarring. Please look at this and give me opinions about the correct way to go forward. Jim _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
