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

[Benjamin Kaduk <[e-mail]>]

On Wed, Jul 20, 2022 at 09:18:16AM -0700, The IESG wrote:
> 
> The IESG has received a request from the CBOR Object Signing and Encryption
> WG (cose) to consider the following document: - 'CBOR Object Signing and
> Encryption (COSE): Countersignatures'
>   <draft-ietf-cose-countersign-06.txt> as Internet Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [e-mail] mailing lists by 2022-08-10. Exceptionally, comments may
> be sent to [e-mail] instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
> 
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-cose-countersign/

This draft fills a claer need, providing "actual countersignature"
semantics for COSE.  However, it's also intended to play a second role,
namely to deprecate the original "countersignature" functionality from RFC
8152 (which did not always provide "actual countersignature" semantics).

I think we probably need to expound further on what exactly is done to
achieve this deprecation: the current version uses the stem "deprecate"
only twice, once in text that is essentially duplicated from
draft-ietf-cose-rfc8152bis-struct, and the final time in the IANA
considerations, where IANA is to add "(Deprecated by [[This Document]]" to
the existing registrations.  (Note: the mismatched parentheses are in the
original.)  There is no discussion of what the deprecation means in
practice for implementations, which is a rather serious omission.

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.)

Since I'm posting to last-call, I did make an attempt to read the rest of
the document, and have some additional remarks.

Prior to sending to the RFC Editor, please do a pass to compare the specific
wordings used for definitions and other shared text between this document and
RFC 9052, to avoid needless divergence in phrasing.  A few specific areas
stuck out to me as meriting this comparison (but this should not be assumed
to be an exhaustive list): the introduction in general, but most notably
around "to be a schema-free decoder"; the security considerations, and the
document terminology section.

Section 1

   countersignature, were those that the working group desired, the
   decision was made to remove all of the countersignature text from
   [I-D.ietf-cose-rfc8152bis-struct] and create a new document to both
   deprecate the old countersignature algorithm and to define a new one
   with the desired security properties.

We should probably specifically indicate that the "new document" is this
one, in some fashion.

   The new algorithm is designed to produce the same countersignature
   value in those cases where the cryptographic computed value was
   already included.  This means that for those structures the only
   thing that would need to be done is to change the value of the header
   parameter.

It's not entirely clear to me on first read that this is a feature.
Creating ambiguity about how a given ciphertext was created or should be
processed has historically given rise to vulnerabilities.  That said, since
in this particular case the actual cryptographic content is the same and
this is the scenario where the construction being deprecated did provide
the intended "actual countersignature" semantics, maybe there is not really
any grounds for "confusion" here.

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!


NITS

Section 1.2

   CBOR grammar in the document is presented using CBOR Data Definition
   Language (CDDL) [RFC8610].

singular/plural mismatch

   The collected CDDL can be extracted from the XML version of this
   document via the following XPath expression below.  (Depending on the
   XPath evaluator one is using, it may be necessary to deal with &gt;
   as an entity.)

   //sourcecode[@type='CDDL']/text()

Carsten pointed out for 9052 that the type needs to be lowercase in order to
work.

Section 2

         Generic_Headers /= (
         ? TBD10 => COSE_Countersignature / [+COSE_Countersignature]
         ; V2 Countersignature
         ? TBD11 => COSE_Countersignature0  ; V2 Countersignature0
         )

Since only one of the comments fits to the right, I'd suggest making both be
on their own line, and appearing before the content they describe.

-Ben