Hi Guilherme and Daisuke, On Sat, Sep 30, 2023 at 7:44 AM AJITOMI Daisuke wrote: > On Thu, Sep 14, 2023 at 11:16 PM Guilherme Balena Versiani wrote: >> 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.
I disagree, I think it is the latter. That is, the payload of the Countersign_structure is the "signature" field from the COSE_Signature/COSE_Countersignature structures. Otherwise the COSE countersignature procedure would be processing differently for the COSE_Signature/COSE_Countersignature structures. On Sat, Sep 30, 2023 at 7:44 AM AJITOMI Daisuke wrote: > On Thu, Sep 14, 2023 at 11:16 PM Guilherme Balena Versiani wrote: >> 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 just want to clarify that enumerated list of fields above for each COSE structure refer to the bstr fields from each COSE structure, such that item 3 would be the first item of the other_fields array in the Countersign_structure should item 3 not be "(none)". Under that interpretation, I agree with Daisuke's summary. Consequently, this summary makes it clear that the context field would be "CounterSignatureV2"/"CounterSignature0V2" for COSE_Mac0, COSE_MAC, and COSE_Sign1, where item 3 is not "(none)"; and otherwise "CounterSignature"/"CounterSignature0" On Sat, Sep 30, 2023 at 7:44 AM AJITOMI Daisuke wrote: > 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. That is correct. On Sat, Sep 30, 2023 at 7:44 AM AJITOMI Daisuke wrote: > 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". While I agree that there may be a mistake in the last sentence of your quote from RFC 9338, I don't think replacing COSE_Signature with COSE_Sign is the correct solution. COSE_Sign does have cryptographically computed values in the signatures array, but since the signatures field is not a bstr it is not included in the Countersign_structure. I would propose to replace this last sentence with the following: "Under this new countersign algorithm, COSE_Sign remains an exception that does not include a cryptographically computed value in the countersignature." > On Thu, Sep 14, 2023 at 11:16 PM Guilherme Balena Versiani wrote: >> 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? Yes, that is correct. Both your interpretation stated and the fact that the current master branch of the Examples repository is based on the deprecated approach in RFC 8152. The countersignature on COSE_Sign essentially results in another signature on the payload and does not sign the signatures array. To countersign the signatures (which is the traditional use case for a countersignature), you must apply it individually to a COSE_Signature in the signature array, such that a verifier would have to verify both the countersignature and then the COSE_Signature on the original COSE_Sign payload. You may not view that as the most efficient process, but it allowed the countersignature process to apply generically to any COSE structure. As for the Examples repository, I submitted a PR (#101) a few years ago to update it to the new approach in RFC 9338. That was based on my experimental implementation that was also used to generate some of the examples in Appendix A of RFC 9338. I didn't see anyone else confirming interop, unfortunately. I believe the PR was never merged due to lack of maintainership over the repository, but I may in fact need to revise the PR to fix some JSON representation issues that I discovered since. Best regards, Jonathan _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
