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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
