Hi Johathan,
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.
I finally understand what you are saying.
I should have separated the discussion of context strings from the
discussion of tags. It seems that your opinion is correct.
On the other hand, I still don't understand why we need to use the olg
context strings ("CounterSignature", "Countersignature0") continuously.
Is it to send old signatures together with the new tag? It doesn't seem
like a requirement that needs to be supported at the cost of complicating
specifications or implementations.
Anyway, thanks for the explanation.
Best,
Daisuke
2023年11月7日(火) 19:31 Jonathan Hammell <[email protected]>:
> 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
