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
> <[email protected]> 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 protected] <mailto:[email protected]>
>
> 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 protected]
> https://www.ietf.org/mailman/listinfo/cose
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
