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 > last-call@xxxxxxxx mailing lists by 2022-08-10. Exceptionally, comments may > be sent to iesg@xxxxxxxx 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 > 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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
