Subject: Re: [COSE] Questions about signatures and countersignatures

From: Russ Housley <[email-masked]>
Date: Mon, 14 Mar 2022 17:15:48 -0400

Christian:

I have been very slow in responding.  Apologies.  I hope this late response is helpful.

1.  I think that RFC 8152, Section 4.3 is the place to look.  I think the detached payload is placed in the 'payload' field for signature calculation.

2.  Countersignatures are signatures over another previously calculated signature. That said, we probably should be more clear in the draft-ietf-cose-countersign about what goes in the payload field. Checking with one implementer, that person also used COSE_Sign1.payload of nil in when the payload is detached.  However, a countersignature is a signature over a previous signature, another approach would be to put the signature_value bstr in the payload.  I am thinking that the second approach make the most sense, and it is parallel to this part of the specification:

	"When done on a COSE_Mac or COSE_Mac0, the payload is included as well as the MAC value".

3.  This seems right to me.  In RFC 5652, I added text to be very clear what a "signature value" means.  It does not include the tag and length.  Is there something that we need to in draft-ietf-cose-countersign to provide similar clarity?

4. Section 3 of draft-ietf-cose-countersign says:

	 "When done on
	a COSE_Sign, this is the same as applying a second signature to the
	payload and adding a parallel signature as a new COSE_Signature is
	the preferred method."

I think you are pointing out that COSE_Sign does not appear in the list of COSE structures in Section 2, where it says:

	"The countersignature header
      parameter can occur as an unprotected attribute in any of the
      following structures: COSE_Sign1, COSE_Signature, COSE_Encrypt,
      COSE_recipient, COSE_Encrypt0, COSE_Mac, and COSE_Mac0."

I think we should add COSE_Sign in Section 2.

5.  A countersignture covers one previously calculated signature.  It does not match the semantics in the question.  One approach would be to define an application that signs another COSE document that already has multiple signatures.  A second approach would be to use countersignature for each of the previously calculated signatures.

The alternative would be for a countersignature to cover the array of signatures.  I have not thought about that, and I wonder what about the semantics of doing so.

6.  I do not know why this document is not an RFC yet.  The approval process is going very slowly.

Russ

> On Feb 11, 2022, at 8:58 AM, Christian Flach <cmfcmf=[email-masked]> wrote:
> 
> Hi everyone,
> 
> We are looking into using COSE for signing some CBOR data. After reading the latest versions of the drafts, we had a few questions and were wondering whether you could provide us some clarification:
> 
> We have a COSE_Sign1 / COSE_Sign structure with a “payload” field set to nil, because we want the payload to not be part of the structure. I’m a bit confused about how to correctly construct the Sig_structure, specifically the “external_aad” and “payload” fields. The description of Sig_structure.external_aad says “The externally supplied data from the application encoded in a bstr type”, and the description of Sig_structure.payload says “The payload to be signed encoded in a bstr type. The payload is placed here independent of how it is transported.”. Both descriptions sound like they would match our detached payload.
> The Java COSE implementation seems to place the detached payload in `payload` and an empty byte string in `external_aad`. Is this the correct way to build the Sig_structure for a COSE_Sign1 / COSE_Sign with a detached payload?
> 
> Section 4.3, which, I think, is about “external_aad”, begins with “One of the features offered in the COSE document is the ability for applications to provide additional data to be authenticated, but that is not carried as part of the COSE object.“. I would appreciate a clearer distinction between “detached payloads” and “externally supplied data”, since both appear to achieve similar goals, namely the data to not be part of the COSE structure. When would an application use one or the other?
> 
> The following questions are all about counter signatures v2.
> 
> I’d like to double check whether I understood the construction of the Countersign_structure correctly: If I want to countersign a COSE_Sign1 structure with a detached payload (COSE_Sign1.payload = nil), is the following correct?
> 
> Countersign_structure = [
>   context : "CounterSignatureV2",			; Identifier
>   body_protected : empty_or_serialized_map,	; Protected headers of COSE_Sign1
>   sign_protected : empty_or_serialized_map,	; Protected headers of COSE_Countersignature
>   external_aad : bstr,						; Empty
>   payload : bstr,							; The detached payload
>   other_fields : [ bstr ]						; An array with a single element: the signature field of COSE_Sign1
> ]
> 
> Similarly, if I wanted to countersign a COSE_Signature that is part of a COSE_Sign structure with a detached payload (COSE_Sign.payload = nil), is the following correct?
> 
> Countersign_structure = [
>   context : "CounterSignature",				; Identifier
>   body_protected : empty_or_serialized_map,	; Protected headers of COSE_Signature
>   sign_protected : empty_or_serialized_map,	; Protected headers of COSE_Countersignature
>   external_aad : bstr,						; Empty
>   payload : bstr,							; The signature field of COSE_Signature
> ]
> 
> If this is correct, is it intentional that the detached payload IS part of the Countersign_structure when countersigning COSE_Sign1, but not when countersigning a COSE_Signature that is part of the COSE_Sign signatures array?
> 
> Section 3 “Version 2 Countersignatures” says “This document extends the context of a countersignature to allow it to be applied to all of the security structures defined”. This sounds like it would be allowed to countersign COSE_Sign (even if it doesn’t make much sense, as is also described in section 3). However, section 2 “Countersignature Header Parameters” says that the countersignature header can only occur on a selected subset of COSE structures, and specifically does not list COSE_Sign as a possible structure to countersign.
> 
> There does not currently seem to be a way to correctly countersign a COSE_Sign structure with a single countersignature. Let’s take the notary analogy: Two people sign a contract, and the notary places their (single) countersignature on the same document, confirming that the two persons signed the contract. The same would not be possible with COSE, I think. With COSE, the notary would need to countersign both signatures separately, i.e. add a countersignature header to both COSE_Signature entries of the the COSE_Sign.signatures array. Is my understanding correct?
> 
> Has there been progress on registering temporary code points in the COSE Header parameters table for counter signatures v2? I found an email from 2020 about this topic (https://mailarchive.ietf.org/arch/msg/cose/88jwAsA4Rh61oP3XR9KGtasNlwo/ <https://mailarchive.ietf.org/arch/msg/cose/88jwAsA4Rh61oP3XR9KGtasNlwo/>), which seems to have been in favor of registering these, but from what I can tell, they haven’t been registered yet.
> 
> Christian
> 
> -- 
> 
> 	
> Christian Flach (he/him)
> Software Engineer
> [email-masked] <mailto:[email-masked]>
> 
> Google Germany GmbH
> Erika-Mann-Straße 33
> 80636 München
> 
> Geschäftsführer: Paul Manicle, Liana Sebastian
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg
> 
> Diese E-Mail ist vertraulich. Falls Sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde. 
>      
> This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose

---

From: Christian Flach <[email-masked]>
Date: Fri, 25 Mar 2022 15:20:59 +0100

Hi Russ,

Thanks a lot for your answers!

Regarding my second question, you write 'However, a countersignature is a
signature over a previous signature, another approach would be to put the
signature_value bstr in the payload'. You are suggesting a change to
draft-ietf-cose-countersign here, correct? Currently, if I read the draft
correctly, the COSE_Sign1.signature field is present in
Countersign_structure.other_fields and Countersign_structure.payload
contains the message payload.

Christian

On Mon, Mar 14, 2022 at 10:15 PM Russ Housley <[email-masked]> wrote:

> 1.  I think that RFC 8152, Section 4.3 is the place to look.  I think the
> detached payload is placed in the 'payload' field for signature calculation.
>
> 2.  Countersignatures are signatures over another previously calculated
> signature. That said, we probably should be more clear in the
> draft-ietf-cose-countersign about what goes in the payload field. Checking
> with one implementer, that person also used COSE_Sign1.payload of nil in
> when the payload is detached.  However, a countersignature is a signature
> over a previous signature, another approach would be to put the
> signature_value bstr in the payload.  I am thinking that the second
> approach make the most sense, and it is parallel to this part of the
> specification:
>
> 3.  This seems right to me.  In RFC 5652, I added text to be very clear
> what a "signature value" means.  It does not include the tag and length.
> Is there something that we need to in draft-ietf-cose-countersign to
> provide similar clarity?
>
> I think you are pointing out that COSE_Sign does not appear in the list of
> COSE structures in Section 2, where it says:
>
> 5.  A countersignture covers one previously calculated signature.  It does
> not match the semantics in the question.  One approach would be to define
> an application that signs another COSE document that already has multiple
> signatures.  A second approach would be to use countersignature for each of
> the previously calculated signatures.
>
> The alternative would be for a countersignature to cover the array of
> signatures.  I have not thought about that, and I wonder what about the
> semantics of doing so.
>
> On Feb 11, 2022, at 8:58 AM, Christian Flach <
> cmfcmf=[email-masked]> wrote:
>
> Hi everyone,
>
> We are looking into using COSE for signing some CBOR data. After reading
> the latest versions of the drafts, we had a few questions and were
> wondering whether you could provide us some clarification:
>
>
>    1. We have a COSE_Sign1 / COSE_Sign structure with a “payload” field
>    set to nil, because we want the payload to not be part of the structure.
>    I’m a bit confused about how to correctly construct the Sig_structure,
>    specifically the “external_aad” and “payload” fields. The description of
>    Sig_structure.external_aad says “The externally supplied data from the
>    application encoded in a bstr type”, and the description of
>    Sig_structure.payload says “The payload to be signed encoded in a bstr
>    type. The payload is placed here independent of how it is transported.”.
>    Both descriptions sound like they would match our detached payload.
>    The Java COSE implementation seems to place the detached payload in
>    `payload` and an empty byte string in `external_aad`. Is this the correct
>    way to build the Sig_structure for a COSE_Sign1 / COSE_Sign with a detached
>    payload?
>
>
> Section 4.3, which, I think, is about “external_aad”, begins with “One of
> the features offered in the COSE document is the ability for applications
> to provide additional data to be authenticated, but that is not carried as
> part of the COSE object.“. I would appreciate a clearer distinction between
> “detached payloads” and “externally supplied data”, since both appear to
> achieve similar goals, namely the data to not be part of the COSE
> structure. When would an application use one or the other?
>
>    1. I’d like to double check whether I understood the construction of
>    the Countersign_structure correctly: If I want to countersign a COSE_Sign1
>    structure with a detached payload (COSE_Sign1.payload = nil), is the
>    following correct?
>
>
>    1. Similarly, if I wanted to countersign a COSE_Signature that is part
>    of a COSE_Sign structure with a detached payload (COSE_Sign.payload = nil),
>    is the following correct?
>
>
> If this is correct, is it intentional that the detached payload IS part of
> the Countersign_structure when countersigning COSE_Sign1, but not when
> countersigning a COSE_Signature that is part of the COSE_Sign signatures
> array?
>
>
>    1. Section 3 “Version 2 Countersignatures” says “This document extends
>    the context of a countersignature to allow it to be applied to all of the
>    security structures defined”. This sounds like it would be allowed to
>    countersign COSE_Sign (even if it doesn’t make much sense, as is also
>    described in section 3). However, section 2 “Countersignature Header
>    Parameters” says that the countersignature header can only occur on a
>    selected subset of COSE structures, and specifically does not list
>    COSE_Sign as a possible structure to countersign.
>
>
>
>    1. There does not currently seem to be a way to correctly countersign
>    a COSE_Sign structure with a single countersignature. Let’s take the notary
>    analogy: Two people sign a contract, and the notary places their (single)
>    countersignature on the same document, confirming that the two persons
>    signed the contract. The same would not be possible with COSE, I think.
>    With COSE, the notary would need to countersign both signatures separately,
>    i.e. add a countersignature header to both COSE_Signature entries of the
>    the COSE_Sign.signatures array. Is my understanding correct?
>    2. Has there been progress on registering temporary code points in the
>    COSE Header parameters table for counter signatures v2? I found an email
>    from 2020 about this topic (
>    https://mailarchive.ietf.org/arch/msg/cose/88jwAsA4Rh61oP3XR9KGtasNlwo/),
>    which seems to have been in favor of registering these, but from what I can
>    tell, they haven’t been registered yet.
>
>
> Christian
>
> --
>
> Christian Flach (he/him)
> Software Engineer
> [email-masked]
>
> Google Germany GmbH
> Erika-Mann-Straße 33
> 80636 München
>
> Diese E-Mail ist vertraulich. Falls Sie diese fälschlicherweise erhalten
> haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter,
> löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen,
> dass die E-Mail an die falsche Person gesendet wurde.
>
>
> This e-mail is confidential. If you received this communication by
> mistake, please don't forward it to anyone else, please erase all copies
> and attachments, and please let me know that it has gone to the wrong
> person.

-- 

Christian Flach (he/him)
Software Engineer
[email-masked]

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Diese E-Mail ist vertraulich. Falls Sie diese fälschlicherweise erhalten
haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter,
löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen,
dass die E-Mail an die falsche Person gesendet wurde.

This e-mail is confidential. If you received this communication by mistake,
please don't forward it to anyone else, please erase all copies and
attachments, and please let me know that it has gone to the wrong person.

---

From: Russ Housley <[email-masked]>
Date: Fri, 25 Mar 2022 16:02:54 -0400

No, I'm not suggesting a change.  I'm trying to describe the reason one performs a countersignature.

Russ

> On Mar 25, 2022, at 10:20 AM, Christian Flach <cmfcmf=[email-masked]> wrote:
> 
> Hi Russ,
> 
> Regarding my second question, you write 'However, a countersignature is a signature over a previous signature, another approach would be to put the signature_value bstr in the payload'. You are suggesting a change to draft-ietf-cose-countersign here, correct? Currently, if I read the draft correctly, the COSE_Sign1.signature field is present in Countersign_structure.other_fields and Countersign_structure.payload contains the message payload.
> 
> Christian
> 
> On Mon, Mar 14, 2022 at 10:15 PM Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
> Christian:
> 
>> On Feb 11, 2022, at 8:58 AM, Christian Flach <cmfcmf=[email-masked] <mailto:cmfcmf=[email-masked]>> wrote:
>> 
>> Hi everyone,
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/cose <https://www.ietf.org/mailman/listinfo/cose>
> 
> 
> 
> -- 
> 
> 	
> Christian Flach (he/him)
> Software Engineer

---

From: Christian Flach <[email-masked]>
Date: Fri, 25 Mar 2022 21:24:52 +0100

Got it, thanks!

On Fri, Mar 25, 2022 at 9:03 PM Russ Housley <[email-masked]> wrote:

> On Mar 25, 2022, at 10:20 AM, Christian Flach <
>> I think you are pointing out that COSE_Sign does not appear in the list
>> of COSE structures in Section 2, where it says:
>>
>> 5.  A countersignture covers one previously calculated signature.  It
>> does not match the semantics in the question.  One approach would be to
>> define an application that signs another COSE document that already has
>> multiple signatures.  A second approach would be to use countersignature
>> for each of the previously calculated signatures.
>>
>>    1. Similarly, if I wanted to countersign a COSE_Signature that is
>>    part of a COSE_Sign structure with a detached payload (COSE_Sign.payload =
>>    nil), is the following correct?
>>
>>
>> If this is correct, is it intentional that the detached payload IS part
>> of the Countersign_structure when countersigning COSE_Sign1, but not when
>>    1. Section 3 “Version 2 Countersignatures” says “This document
>>    extends the context of a countersignature to allow it to be applied to all
>>    of the security structures defined”. This sounds like it would be allowed
>>    to countersign COSE_Sign (even if it doesn’t make much sense, as is also
>>    2. Has there been progress on registering temporary code points in
>>    the COSE Header parameters table for counter signatures v2? I found an
>>    email from 2020 about this topic (

-- 

Christian Flach (he/him)
Software Engineer
[email-masked]

Google Germany GmbH

Erika-Mann-Straße 33

80636 München