[COSE] COSE Struct Discuss

[Jim Schaad <[e-mail]>]

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