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? The following questions are all about counter signatures v2. 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? 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 ] 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? 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? 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 -- [image: Google Logo] Christian Flach (he/him) Software Engineer [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
