Hi Daisuke, Sorry for the late reply, I want to continue the discussion to hopefully resolve our disagreement below.
On Fri, Oct 13, 2023 at 4:20 AM AJITOMI Daisuke <[email protected]> wrote: > On Mon, Oct 9, 2023 at 12:13 PM Jonathan Hammell <[email protected]> > wrote: >> 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" > > > I disagree with the latter part. Certainly the other cases than > Mac0/Mac/Sign1 can be handled fine with the old > "CounterSignature/CounterSignature0", > but I think Jim intended to use "CounterSignatureV2/CounterSignature0V2" in > all COSE structures. > The following statements make this clear: > > (The last part of Section1, RFC9338) >> >> With the publication of this document, implementers are encouraged to >> migrate uses of the previous countersignature algorithm to the one specified >> in this document. In particular, uses of "CounterSignature" will migrate to >> "CounterSignatureV2", and uses of "CounterSignature0" will migrate to >> "CounterSignature0V2". In addition, verification of "CounterSignature" must >> be supported by new implementations to remain compatible with senders that >> adhere to [RFC8152], which assumes that all implementations will understand >> "CounterSignature" as header parameter label 7. Likewise, verification of >> "CounterSignature0" may be supported for further compatibility. > > > (Section 2, RFC9338) >> >> V2 countersignature: This header parameter holds one or more >> countersignature values. Countersignatures provide a method of having a >> second party sign some data. The countersignature header parameter can occur >> as an unprotected attribute in any of the following structures that are >> defined in [RFC9052]: COSE_Sign1, COSE_Signature, COSE_Encrypt, >> COSE_recipient, COSE_Encrypt0, COSE_Mac, and COSE_Mac0. Details of version 2 >> countersignatures are found in Section 3. There is a semantic difference between the use of the Countersignature version 2 / Countersignature0 version 2 header parameters (i.e. with labels 11 and 12) or standalone version 2 countersignature (i.e. with COSE tag 19) versus the string that is put in the context field of the Countersign_structure. I agree that RFC 9338 says that implementations should migrate to using the version 2 countersignature header parameters and tag. However, the signing and verifying process in Section 3.3 of RFC 9338 states when to use the strings "CounterSignatureV2"/"CounterSignature0V2" or "CounterSignature"/"CounterSignature0" in the context field for a version 2 countersignature. The latter (i.e. the context string) was what I was explaining above based on the COSE message type. Jonathan On Fri, Oct 13, 2023 at 4:20 AM AJITOMI Daisuke <[email protected]> wrote: > > Hi Jonathan, > >> I disagree, I think it is the latter. > > > Ah, sorry for the confusion, you are correct. > By mistake, I wrote the interpretation for the COSE_Sign1/Sign case instead > of the COSE_Signature case. > I also wrote the following in the list in my previous email: > >> >> - COSE_Signature: 1. protected (in a bstr type), 2. signature, 3 (none) > > > The payload of the COSE_Signature is the "signature". The latter > interpretation by Guilherme is correct. > >> > 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: 12. 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. > > > Yes, your interpretation is correct. > >> 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" > > > I disagree with the latter part. Certainly the other cases than > Mac0/Mac/Sign1 can be handled fine with the old > "CounterSignature/CounterSignature0", > but I think Jim intended to use "CounterSignatureV2/CounterSignature0V2" in > all COSE structures. > The following statements make this clear: > > (The last part of Section1, RFC9338) >> >> With the publication of this document, implementers are encouraged to >> migrate uses of the previous countersignature algorithm to the one specified >> in this document. In particular, uses of "CounterSignature" will migrate to >> "CounterSignatureV2", and uses of "CounterSignature0" will migrate to >> "CounterSignature0V2". In addition, verification of "CounterSignature" must >> be supported by new implementations to remain compatible with senders that >> adhere to [RFC8152], which assumes that all implementations will understand >> "CounterSignature" as header parameter label 7. Likewise, verification of >> "CounterSignature0" may be supported for further compatibility. > > > (Section 2, RFC9338) >> >> V2 countersignature: This header parameter holds one or more >> countersignature values. Countersignatures provide a method of having a >> second party sign some data. The countersignature header parameter can occur >> as an unprotected attribute in any of the following structures that are >> defined in [RFC9052]: COSE_Sign1, COSE_Signature, COSE_Encrypt, >> COSE_recipient, COSE_Encrypt0, COSE_Mac, and COSE_Mac0. Details of version 2 >> countersignatures are found in Section 3. > > > >> 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. > > > Certainly my amendment is inaccurate. Yours is better. > >> 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. > > > I saw that your PR was long abandoned when I was implementing the countersign > feature earlier this year. > I believe that the maintenance of the cose-wg/Examples repository should be > resumed. > > Regards, > Daisuke > > > > 2023年10月10日(火) 1:13 Jonathan Hammell <[email protected]>: >> >> 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
