Hi Guilherme, Since I've implemented the countersignature feature experimentally before, I'd like to share my interpretation.
While forming the ToBeSigned value, chances are the “payload” may get > different interpretations. The section 3.3 says “the payload to be signed, > encoded in a bstr type”. In this case, may it be the target message payload > (say from COSE_Sign1 / COSE_Sign), or is it just the “signature” field of > the COSE_Signature/COSE_Countersignature structures? To my understanding, the "payload" means the former. The question is how to interpret the “other_fields” from same section 3.3. > It says “all bstr fields after the second”. I'm considering the first, the second, and the third field (which is placed in other_fields) of each COSE structure (which can be countersigned) to be as follows: - COSE_Mac0: 1. protected (in a bstr type), 2. payload, *3. tag*. - COSE_Mac: 2. protected (in a bstr type), 2. payload, *3. tag*. - COSE_Sign1: 1. protected (in a bstr type), 2. payload, *3. signature*. - COSE_Sign: 1. protected (in a bstr type), 2. payload, 3 (none) - COSE_Encrypt0: 1. protected (in a bstr type), 2. ciphertext, 3 (none) - COSE_Encrypt: 1. protected (in a bstr type), 2. ciphertext, 3 (none) - COSE_Signature: 1. protected (in a bstr type), 2. signature, 3 (none) I interpret that in the previous countersign spec (defined in RFC8152) where "other_fields" didn't exist, it was a problem that we couldn't sign the underscored "signature" above. I feel the interpretation aligns with the description (especially, underscored parts) in RFC9338 (Section.1) as follows: A countersignature is a second signature that confirms the primary > signature. During the process of advancing CBOR Object Signing and > Encryption (COSE) to Internet Standard, *it was noticed that the > description of the security properties of countersignatures was incorrect > for the COSE_Sign1* structure mentioned in Section 4.5 of [RFC8152]. To > remedy this situation, the COSE Working Group decided to remove all of the > countersignature text from [RFC9052], which obsoletes [RFC8152]. This > document defines a new countersignature with the desired security > properties. > *The problem with the previous countersignature algorithm was that the > cryptographically computed value was not always included. The initial > assumption that the cryptographic value was in the third slot of the array > was known not to be true at the time, but in the case of the Message > Authentication Code (MAC) structures this was not deemed to be an issue. > The new algorithm defined in this document requires the inclusion of more > values for the countersignature computation. The exception to this is the > COSE_SignatureCOSE_Sign structure where there is no cryptographically > computed value.* The last part, "COSE_Signature", is likely a mistake and should be "COSE_Sign". What do you think? I'm happy if my comments can be somewhat helpful for you. Best, Daisuke 2023年9月15日(金) 12:16 Guilherme Balena Versiani <guibv= [email protected]>: > Hello, > > While proposing an extension to go-cose ( > https://github.com/veraison/go-cose) for supporting countersignatures > using RFC 9338, I felt a certain difficulty to follow the documentation. > > They were: > > 1. How to countersign COSE_Signature and COSE_Countersignature structures? > > While forming the ToBeSigned value, chances are the “payload” may get > different interpretations. The section 3.3 says “the payload to be signed, > encoded in a bstr type”. In this case, may it be the target message payload > (say from COSE_Sign1 / COSE_Sign), or is it just the “signature” field of > the COSE_Signature/COSE_Countersignature structures? I understand it would > be the latter, so the countersignature attests just the parent's signature, > which means the entity had to go over the signature’s parent to verify it, > working recursively, towards the root’s structure. > > 2. How to countersign a COSE_Sign structure? > > The question is how to interpret the “other_fields” from same section 3.3. > It says “all bstr fields after the second”. COSE_Sign has “signatures” as > third field, which is a list of COSE_Signatures, so technically the third > field is not a bstr but an array. In this case, the ToBeSigned value would > be formed by protected headers and the payload, but wouldn't include any > signature, and doing so means that a COSE_Sign countersignature would work > just as another COSE_Signature, except it may be placed as unprotected > header. On the other hand, the COSE_Sign “signatures” field can be > serialized in a bstr, similarly to what happens to “protected” headers. > This would allow countersignatures to attest the protected headers, the > document and all signatures appended to it until the signature was placed; > however, prohibits further countersignatures at individual signatures and > other modifications at the unprotected headers. A third possibility, which > is not stated anywhere, but I wonder if it wouldn't be handy, is the > ability to include in the ToBeSigned value only the protected headers and > signature fields of each COSE_Signature structure appended to COSE_Sign; > this would allow extensibility of the structure, except of course appending > further signatures. > > The example provided in > https://github.com/cose-wg/Examples/blob/master/countersign/signed-03.json > formed > a ToBeSigned like > > ["CounterSignature", h'A10300', h'A10127', h'', > h'546869732069732074686520636F6E74656E742E’] > > Which corresponds to: > - context: “CounterSignature” > - body_protected: / content-type / {3: 0} / text/plain; charset=utf-8 / > - sign_protected: / alg / {1: -8} / EdDSA / > - external_aad: none > - payload: "This is the content.” > > Compare it with the COSE_Signature also from this same example: > > ["Signature", h'A10300', h'A10127', h'', > h'546869732069732074686520636F6E74656E742E’] > > - context: “Signature” > - body_protected: / content-type / {3: 0} / text/plain; charset=utf-8 / > - sign_protected: / alg / {1: -8} / EdDSA / > - external_aad: none > - payload: "This is the content.” > > The only diference is in the context, and it means a countersignature of a > COSE_Sign would be attesting the protected headers and the payload only, > excluding all signatures. I’m under the impression the > https://github.com/cose-wg/Examples repository is still following the > deprecated RFC 8152, but if the above is still the intent of RFC 9338, it > means the COSE_Sign countersignature is limited to witnessing the protected > headers and the payload, which, even though it is definitely an use case, > may be a restrictive case. As a corollary, COSE_Sign1 countersignature > encompasses the signature, why COSE_Sign would not? > > Regards, > Guilherme. > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
