Göran: Marco mentioned this to me at IETF 114, and I forgot to change it for -07. I just made the change in my edit buffer, so it will point to [I-D.ietf-core-oscore-groupcomm] in -08.
Russ > On Aug 19, 2022, at 4:40 AM, Göran Selander > <[email protected]> wrote: > > Hi, > > I haven’t read through this thread yet, just reacted on one of the references > below: > > >This document extends the context of a countersignature > to allow it to be applied to all of the security structures defined. > The countersignature needs to be treated as a separate operation from > the initial operation even if it is applied by the same user as is > done in [I-D.ietf-core-groupcomm-bis]. > > Note that the referenced draft does not speak about countersignatures or make > any reference to draft-ietf-cose-countersign because the security processing > is defined in draft-ietf-core-oscore-groupcomm. So, although cose-countersign > is used to secure core-groupcomm-bis, it may be confusing for a reader not > finding any direct reference to countersignatures and perhaps better to > referencecore-oscore-groupcomm (or both). > > Göran > > From: COSE <[email protected] <mailto:[email protected]>> on behalf > of Russ Housley <[email protected] <mailto:[email protected]>> > Date: Thursday, 18 August 2022 at 19:49 > To: Ben Kaduk <[email protected] <mailto:[email protected]>> > Cc: Last Call <[email protected] <mailto:[email protected]>>, Cose Chairs > Wg <[email protected] <mailto:[email protected]>>, cose <[email protected] > <mailto:[email protected]>>, [email protected] > <mailto:[email protected]> > <[email protected] > <mailto:[email protected]>>, Michael Richardson > <[email protected] <mailto:[email protected]>>, Roman D. Danyliw > <[email protected] <mailto:[email protected]>> > Subject: Re: [COSE] [Last-Call] Last Call: > <draft-ietf-cose-countersign-06.txt> (CBOR Object Signing and Encryption > (COSE): Countersignatures) to Internet Standard > > Ben: > > Inline ... > > >>> > >>>> I suggest that we add the following: > >>>> > >>>> With the publication of this document, implementers are encouraged to > >>>> migrate used of the previous countersignature algorithm to the one > >>>> specified in this document. In particular, uses of > >>>> "CounterSignature" will migrate to "CounterSignatureV2", and uses of > >>>> "CounterSignature0" will migrate to "CounterSignature0V2". Of > >>>> course, the validation of "CounterSignature" and "CounterSignature0" > >>>> might be supported to handle previously generated counter signatures. > >>> > >>> The general sense of this looks good to me. > >>> For transparency, RFC-to-be 9052 appears to have all needed approvals > >>> (including Paul's as AD), and says this (in the context of "crit"): > >>> > >>> Additionally, the header parameter "counter signature" (label 7) defined > >>> by [RFC8152] must be understood by new implementations, to remain > >>> compatible with senders that adhere to that document and assume all > >>> implementations will understand it. > >>> > >>> with lowercase "must". So I think the text in this document would better > >>> align with 9052 if we s/might be supported/must be supported/. > >> > >> I suggest: > > > > Looks good modulo nits. > > > >> With the publication of this document, implementers are encouraged to > >> migrate used of the previous countersignature algorithm to the one > >> specified in this document. In particular, uses of > >> "CounterSignature" will migrate to "CounterSignatureV2", and uses of > >> "CounterSignature0" will migrate to "CounterSignature0V2". In > >> additional, verification of "CounterSignature" must be supported by > > > > s/additional/addition/ > > Fixed. > > > > >> new implementations to remain compatible with senders that adhere to > >> [RFC8152], which assumes that all implementations will understand > >> "CounterSignature" as heading label 7. Likewise, verification of > > > > s/heading/header parameter/ > > Also fixed. > > > > >> "CounterSignature0" may be supported for further compatibility. > >> > >> > >>>> > >>>>> In particular, the current state of affairs gives the COSE header > >>>>> parameter > >>>>> with label 7 ("counter signature") privileged treatment in that senders > >>>>> are > >>>>> free to assume that recipients can understand and process it, even if > >>>>> it is > >>>>> not listed in the "crit" header's value. While a reasonable reader > >>>>> might > >>>>> assume that being marked as "deprecated" directs a sender to not omit > >>>>> the > >>>>> parameter (though more concrete guidance on that point seems apropos to > >>>>> me), I do not think that there is a clear implication about whether an > >>>>> impelementation must continue to implement support for processing this > >>>>> header parameter. In order to ensure a smooth deprecation process, I > >>>>> think > >>>>> this document needs to make a specific statement about whether the > >>>>> requirement on implementations to understand this parameter remains. > >>>>> (I am currently grappling with how to describe this situation for > >>>>> RFC-to-be > >>>>> 9052, that does not discuss "counter signature" but does retain RFC > >>>>> 8152's > >>>>> guidance that labels 0-7 SHOULD be omitted from the "crit" value. I > >>>>> believe that the requirement on implementations to understand and be > >>>>> able > >>>>> to process "counter signature" must remain for the purposes of RFC > >>>>> 9052.) > >>>> > >>>> We could also warn that over time implementations are expected to stop > >>>> recognizing "CounterSignature" and "CounterSignature0". That said, i > >>>> would probably be good to have RFC-to-be 9052 and this document handle > >>>> this the same way. > >>> > >>> I support warning that over time we expect implementations to phase out > >>> support for the legacy structures. I mostly expect that we would have a > >>> new document in a year or two that formally Updates 9052 to ease this > >>> requirement (but I also wouldn't mind if we decided to put that change > >>> into > >>> the current -countersign document). I'm not sure if that aligns with your > >>> indicated preference to handle things the same way with 9052 and > >>> -countersign. > >> > >> It sounds like it would be better to wait for that follow-on document to > >> soften the backward compatibility requirement. At that point, RFC-to-be > >> 9052 and -countersign will probably become one document. > > > > Okay. (Obviously we can see if anyone else chimes in on this point, too.) > > Unless someone speaks soon, I'm going to let this one wait for a future > revision. > > > > >>>>> Section 3 > >>>>> > >>>>> timestamp, a time point at which the signature exists. 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 don't think I understand what this is trying to say, as what it seems > >>>>> to say > >>>>> to me doesn't make sense. In particular, this seems to say that the > >>>>> act of > >>>>> applying a countersignature to a COSE_Sign structure is functionally > >>>>> equivalent to just appending to the "signatures" array of the COSE_Sign > >>>>> object, and indeed that appending to "signatures" is preferred. But > >>>>> that > >>>>> seems to provide semantics that are not the (desired) semantics of a > >>>>> true > >>>>> countersignature, which would cover the existing (primary) signature in > >>>>> addition to the content! > >>>> > >>>> Wow. This error has been here a very long time. Thanks for noticing! > >>>> > >>>> ... That is, the countersignature makes a > >>>> statement about the existence of a signature and, when used as a > >>>> timestamp, a point in time at which the signature exists. When a > >>>> timestamp is not used, a countersignature on a COSE_Sign is the same > >>>> as applying a second signature to the payload; therefore, adding a > >>>> parallel signature as a new COSE_Signature is the preferred method. > >>> > >>> I had to read this several times to convince myself that it makes sense, > >>> so > >>> let me write out some description of how I resolved it, to try to > >>> cross-check my reasoning. > >>> Just as a baseline/refresher (since I've confused myself about it in the > >>> past), the primary COSE structures for signatures are COSE_Sign and > >>> COSE_Sign1; the COSE_Signature structure is a substructure that holds "the > >>> signature and information about the signature". When we construct a > >>> countersignature on a COSE_Sign, the procedures have us pull into the > >>> to-be-signed bytes both the payload and "all bstr fields after the second" > >>> (among other things), but since COSE_Sign has only two bstr fields > >>> (protected_headers and payload), that means the "other_fields" element is > >>> omitted. In particular, the "signatures" member of COSE_Sign is an array > >>> and not a bstr, so the other existing signatures in the COSE_Sign are not > >>> included in other_fields and thus not covered by the countersignature -- > >>> we'd need to apply the countersignature on the COSE_Signature object > >>> itself > >>> in order to do that. Having made that insight, the focus in the new text > >>> about timestamp/no-timestamp does make more sense, and in the > >>> no-timestampp > >>> case the countersignature's to-be-signed bytes basically match those of a > >>> primary signature ("new COSE_Signature [in the COSE_Sign]"), and the > >>> recommendation here does make more sense. > >>> > >>> That said, this seems to be the only place in the document where we > >>> mention > >>> "timestamp", so I wonder if we want to put some additional discussion > >>> somewhere about the mechanics of using a countersignature to add a > >>> timestamp (e.g., in external_aad?). > >> > >> I am not sure how to resolve this since RFC-to-be 9052 does not talk about > >> timestamps at all. I think it go in the protected header. > > > > I think I see two possible routes for this, if we want to do anything. > > > > The first would be in §3, around "A normal example of a countersignature is > > the signature that a notary public places on a document as witnessing that > > you have signed the document", which we could extend with something like > > "This notary usage typically also includes a timestamp for when the > > notarization occurs; such a signature timestamp is not defined in core > > COSE, but might be included in a (not-yet-defined) protected header > > parameter". > > > > The second would be as part of the text in §3 that we're discussing, maybe > > something like: > > > > ... That is, the countersignature makes a > > statement about the existence of a signature and, when a timestamp is > > covered by the signature (e.g., in a to-be-defined protected header > > parameter), a point in time at which the signature exists. When a > > timestamp is not used, a countersignature on a COSE_Sign is the same as > > applying a second signature to the payload; therefore, adding a parallel > > signature as a new COSE_Signature is the preferred method. > > > > ... and as I read this again, I'm questioning whether there is actually a > > difference between the timestamp-used and timestamp-not-used cases -- > > couldn't the timestamp at which the signature exists be encoded in the new > > COSE_Signature just as well as the countersignature? > > The point is that a countersignature is a signature over a previous > signature, not just the content that was signed. > > Maybe the statement about "preference" is not worth the effort. Instead, we > can just drop that sentence. That way, the text is focusing on the > structures and their security properties. > > Incorporating the suggestions above (with some wordsmithing), and dropping > the "preference" sentence would gives this for Section 3: > > 3. Version 2 Countersignatures > > A countersignature is normally defined as a second signature that > confirms a primary signature. A normal example of a countersignature > is the signature that a notary public places on a document as > witnessing that you have signed the document. A notary typically > includes a timestamp to indicate when notarization occurs; however, > such a timestamp has not yet been defined for COSE. A timestamp, > once defined in a future document, might be included as a protected > header parameter. Thus applying a countersignature to either the > COSE_Signature or COSE_Sign1 objects match this traditional > definition. This document extends the context of a countersignature > to allow it to be applied to all of the security structures defined. > The countersignature needs to be treated as a separate operation from > the initial operation even if it is applied by the same user as is > done in [I-D.ietf-core-groupcomm-bis]. > > COSE supports two different forms for countersignatures. Full > countersignatures use the structure COSE_Countersignature, which has > the same structure as COSE_Signature. Thus, full countersignatures > can have protected and unprotected attributes, including chained > countersignatures. Abbreviated countersignatures use the structure > COSE_Countersignature0. This structure only contains the signature > value and nothing else. The structures cannot be converted between > each other; as the signature computation includes a parameter > identifying which structure is being used, the converted structure > will fail signature validation. > > The version 2 countersignature changes the algorithm used for > computing the signature from the original version that is specified > Section 4.5 of [RFC8152]. The new version now includes the > cryptographic material generated for all of the structures rather > than just for a subset. > > COSE was designed for uniformity in how the data structures are > specified. One result of this is that for COSE one can expand the > concept of countersignatures beyond just the idea of signing a > signature to being able to sign most of the structures without having > to create a new signing layer. When creating a countersignature, one > needs to be clear about the security properties that result. When > done on a COSE_Signature or COSE_Sign1, the normal countersignature > semantics are preserved. That is, the countersignature makes a > statement about the existence of a signature and, when used with a > yet-to-be-specified timestamp, a point in time at which the signature > exists. When done on a COSE_Mac or COSE_Mac0, the payload is > included as well as the MAC value. When done on a COSE_Encrypt or > COSE_Encrypt0, the existence of the encrypted data is attested to. > It should be noted that there is a distinction between attesting to > the encrypted data as opposed to attesting to the unencrypted data. > If the latter is what is desired, then one needs to apply a signature > to the data and then encrypt that. It is always possible to > construct cases where the use of two different keys will appear to > result in a successful decryption (the tag check success), but which > produce two completely different plaintexts. This situation is not > detectable by a countersignature on the encrypted data. > > Russ > > _______________________________________________ > COSE mailing list > [email protected] <mailto:[email protected]> > https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-53f73e16f328bba6&q=1&e=405053e0-9e53-4f02-a0d9-a3fc1b4daf9e&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcose > > <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-53f73e16f328bba6&q=1&e=405053e0-9e53-4f02-a0d9-a3fc1b4daf9e&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcose>-- > > last-call mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/last-call > <https://www.ietf.org/mailman/listinfo/last-call>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
