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