I'm sorry, I've been pretty much unaware of the 8152bis effort. I feel rather embarrassed about that, having written some code that did not (yet) fully interoperate with Jim's code (That TODO item shouts at me daily)
Jim Schaad <[email protected]> wrote: > 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. I found your words "second bstr" mystyfing because it maps to "* bstr w/ some type of content" rather than the "second" item, "map w/ unprotected attributes" :-) Next time, can we number the items... > 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. I understand this part. > 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 "Last three structures"... I think you must mean COSE_Encrypt, COSE_recipient and COSE_Mac. (Why on page 16 are they: COSE_Sign1, COSE_Signature, COSE_Encrypt, COSE_recipient, COSE_Encrypt0, COSE_Mac, and COSE_Mac0. In this order, rather than: COSE_Signature, COSE_Sign1, COSE_Encrypt0, COSE_Encrypt, COSE_recipient, COSE_Mac, and COSE_Mac0. ) But, COSE_Encrypt combines: "* bstr w/ some type of content"/"* bstr w/ cryptographic value" because it's encrypted, right? > 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: Can you give a use case here? I think that I get that we are either breaking COSE_Sign1 (which has been rarely used so far), or COSE_Mac*, in-so-far as they need countersignatures with additional values. If no additional values, then not a problem. > 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. I think that I'm okay with breaking/updating COSE_Sign1. Don't we need Sign1 for SUIT? I believe that Henk's SBOM proposal (outside of the IETF), does. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] [email protected] http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
