Re: [Last-Call] [COSE] Last Call: <draft-ietf-cose-countersign-06.txt> (CBOR Object Signing and Encryption (COSE): Countersignatures) to Internet Standard

[Russ Housley <housley@xxxxxxxxxxxx>]

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 <goran.selander=40ericsson.com@xxxxxxxxxxxxxx> 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 <cose-bounces@xxxxxxxx> on behalf of Russ Housley <housley@xxxxxxxxxxxx>
Date: Thursday, 18 August 2022 at 19:49
To: Ben Kaduk <kaduk@xxxxxxx>
Cc: Last Call <last-call@xxxxxxxx>, Cose Chairs Wg <cose-chairs@xxxxxxxx>, cose <cose@xxxxxxxx>, draft-ietf-cose-countersign@xxxxxxxx <draft-ietf-cose-countersign@xxxxxxxx>, Michael Richardson <mcr+ietf@xxxxxxxxxxxx>, Roman D. Danyliw <rdd@xxxxxxxx>
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
COSE@xxxxxxxx
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
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call