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
