Hi Christian, A while ago, I produced some of the countersignature examples for the I-D. I've been reviewing my code in light of the questions you have raised and some discussion that I had with Russ, and I believe that there is ambiguity remaining in the I-D that is leading to these different interpretations.
I would love to work with you to do some interoperability testing and ensure the examples are correct before the I-D is published. Jonathan On Fri, Mar 25, 2022 at 4:25 PM Christian Flach <cmfcmf= [email protected]> wrote: > Got it, thanks! > > On Fri, Mar 25, 2022 at 9:03 PM Russ Housley <[email protected]> wrote: > >> 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 < >> [email protected]> wrote: >> >> 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 protected]> >> wrote: >> >>> 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: >>> >>> >>> 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 >>> >>> >>> >> >> -- >> >> [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 >> >> >> > > -- > > [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 >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
