Original text:
RFC8613 and I-D.ietf-core-groupcomm-bis.  However, COSE is not restricted to just these cases and can be used in any place where one would consider either JOSE or CMS RFC5652 for the purpose of <del> providing security services.  The use of COSE, like JOSE and CMS, is only for use in store and forward or offline protocols.  The use of COSE in online protocols needing encryption, require that an online key establishment process be done before sending objects back and forth.  Any application which uses COSE for security services first needs to determine what security services are required and then select the appropriate COSE structures and cryptographic algorithms based on those needs.  app-considerations provides additional information on what applications need to specify when using COSE. </del>  One feature that is present in CMS that is not present in this standard is a digest structure.  This omission is deliberate.  It is are going to be common to all applications, the two values may not always be adjacent as the algorithm could be defined once with multiple values.  Applications may additionally want to define <del> additional data fields as part of the structure.  A one such </del>  application-specific element would be to include a URI or other pointer to where the data that is being hashed can be obtained.  I- D.ietf-cose-hash-algs contains one such possible structure along with cryptographic key, we use the term "label" for this usage as a map key. <del> The presence a label that is neither a a text string or an integer, in a CBOR map, is an error.  Applications can either fail processing or process messages by ignoring incorrect labels; however, they MUST NOT create messages with incorrect labels. </del>  A CDDL grammar fragment defines the non-terminal 'label', as in the previous paragraph, and 'values', which permits any value to be used. different types of cryptographic concepts.  As an example of how this works, consider the COSE_Encrypt message (EnvelopedData).  This message type is broken into two layers: the content layer and the <del> recipient layer.  The content layer contains the plaintext is encrypted and information about the encrypted message.  The recipient layer contins the content encryption key (CEK) is encrypted and information about how it is encrypted for each recipient.  A single layer version of the encryption message COSE_Encrypt0 (EnvelopedData0) is provided for cases where the CEK is pre-shared. </del>  Identification of which type of message has been presented is done by the following methods: along with the signature itself.  These header parameters may be authenticated by the signature, or just present.  An example of a header parameter about the content is the content type header <del> parameter.  An examples of a header parameter about the signature </del>  would be the algorithm and key used to create the signature. RFC 5652 indicates that: message, all of the signature algorithms are going to be required to consume the same bytes of message content.  This means that the mixing of the signature with message recovery and signature with <del> appendix schemes in a single message is not supported, and if a recovery signature scheme is used. </del>  The signature functions for this scheme are: there is a high probability that additional issues will arise when integrating message recovery signature algorithms.  The first algorithm defined is going to need to make decisions about these <del> issues and those decisions re likely to be binding on any further </del>  algorithms defined. We use the following terms below: <del> Some of the issue2 that have already been identified are: </del>  Signature algorithms are used with the COSE_Signature and COSE_Sign1 structures.  At the time of this writing, only signatures with 11. The registries and registrations listed below were created during <del> processing of RFC 8152 RFC8152.  The majority of the actions are to update the references to point to this document. </del>  11.1. IANA created a registry titled "COSE Header Parameters" as part of processing RFC8152.  IANA is requested to update the reference for <del> all entries, except "counter signature" and "CounterSignature0", in the table from RFC8152 to this document.  The reference for "counter signature" and "CounterSignature0" are to be left alone. </del>  11.2. IANA created a registry titled "COSE Key Common Parameters" as part of the processing of RFC8152.  IANA is requested to update the <del> reference for entries in the table from RFC8152 to this document. </del>  11.3.

Reviewer comments:
This PR addresses the remaining comments from Ben Kaduk. NAME do these changes match your expectations?
Ah, that's the one. Will add. I do note that Göran's name is still too "ASCII-ized"; how to include the unicode here is not immediately clear (it's not in an , it's not , etc). I suggest adding an RFC Editor's note about it?
NAME Looking again, there is a CBOR Tags section in this document, at the end of the IANA section instead of the beginning. I think we're good to go, once this is merged. This looks pretty good (some suggestions inline). Comparing against my ballot position (at URL), I don't see anything to match: incorporated still (and the report verified, presuming it is correct). but my recollection is that that one is already incorporated, just into -algs, and I should mark it verified and allocating a codepoint for COSE_Signature). I think we need to bring back a stub section with the directive to update the references from 8152 to this document. which may still be outstanding (I don't remember any other clarifications about that point having gone by).	 authentication check of the contents algorithm" -> "authentication check of the contents" ? How should I read this sentence about AE?  It seems to be copied from 8152, but I kinda feel like the 3rd (last) use of the word "algorithm" could be removed? Table 1, CBOR tag 17: "COSE Mac w/o" -> "COSE MAC w/o" "This is same" -> "This is the same" "That is the counter signature..." -> "That is, the counter signature..." Isn't #6.98 for COSE_Sign_Tagged?  I think the CDDL fragment needs to fixed temporarily to: COSE_CounterSignature_Tagged = #TBD0(COSE_CounterSignature) "of other than direct" -> "if other than direct"? #2: "COSE_MAC" -> "COSE_Mac"? "this new algorithms" -> "these new algorithms" "the key from next layer down" -> "the key from the next layer down" In the interests of brevity, my review focused on the diff between this document and RFC 8152. I agree with Benjamin's concern that we seem to be leaving the Designated Experts for the IANA registries described here with advice in RFC 8152, which this document renders obsolete.   I think that prose should be copied to this document so that it lives someplace current.  I was originally tempted to DISCUSS this but I'm hesitating, so I'll just say I hope this is resolved appropriately. "... structure for the CBOR objects which are ..." -- s/which/that/ "... or offline protocols, different solutions ..." -- "different" should start a new sentence "Any application which uses COSE for security ..." -- s/which/that/ The last sentence in the first paragraph: "This is same structure ..." -- s/same/the same/ "That is the counter signature ..." -- comma after "is" "... existence of the encrypted data is attested to." -- maybe "asserted" instead of "attested to"? "New algorithms will be created which will not fit ..." -- s/which/that/ In the final bullet, why aren't these MUSTs?  Or in the alternative, when would one legitimately deviate from those SHOULDs? I've only reviewed the diffs, not the historical approved text.  Everything looks okay to me.  A few minor comments/nits: I'm not familiar with the CDDL grammar, and specifically whether there is any tooling that can use the grammar to generate structures/etc.  If there is, then I think that it would be helpful if the CDDL grammar was also normative, in the sense that readers of the spec should be able to assume that the CDDL is correct.  I would still be okay with a statement that says that if there is any ambiguity between the two then the prose description should be taken as being definitive. This sentence was changed from the original formulation, but I find it slightly clunky.  Perhaps: The presence of a label, that is neither a text string nor an integer, in a CBOR map, is an error. Nit, this -> these Thanks for making an easy to read and compare bis document. Thank you for addressing my DISCUSS and COMMENT items around Counter Signatures. Thank you for the work put into this document. I really appreciate the section 1 with the detailed and clear introduction. My current workload prevented me to do a deep review, I will then rely mainly on the other Area Directors. Mostly just nits left, though the lingering errata report and the IANA updates seem somewhat significant.  (It would probably be fine to leave the nits for the RFC Editor.) It seems that https://www.rfc-editor.org/errata/eid5066 needs to be incorporated still (and the report verified, presuming it is correct). nit: we probably can just start the sentence with "COSE", since the "use in" has moved to later in the sentence. nit: s/A one/One/. nit: s/a a/a/ nit: s/plaintext is encrypted/encrypted plaintext/ (or similar?) nit: s/content encryption key (CEK) is encrypted/encrypted content encryption key (CEK)/. nit: s/An examples/An example/ I guess this is where the difficulty that Jim mentioned comes in -- the signature recovery scheme gives you the intended recovered content but also some of the other framing and such that was added as input to the signature algorithm, and you have to properly figure out where the end of the actual payload is.  (I'm not sure whether it would be useful to try to have text about the issue in this location, though.) nit: this sentence just trails off ....  I think it would be okay to just end the sentence after "is not supported", since we covered the "must recover the same [number of] bytes" previously. nit: s/ re / are / nit: s/issue2/issues/ I see that a bunch of things were changed from COSE_Encrypt to COSE_Recipient, apparently prompted by my earlier review.  I would feel more comfortable if someone confirmed that each change is correct, as I have lost some of the context here. nit: s/guidence/guidance/ We lost the section about the "CBOR Tags" registry (where we were previously allocating a codepoint for COSE_Signature).  I think we need to bring back a stub section with the directive to update the references from 8152 to this document. The references to the COSE registries should not be Normative. Thanks for addressing my issue with the IANA registration rules.
authentication check of the contents algorithm" -> "authentication check of the contents" ? How should I read this sentence about AE?  It seems to be copied from 8152, but I kinda feel like the 3rd (last) use of the word "algorithm" could be removed? Table 1, CBOR tag 17: "COSE Mac w/o" -> "COSE MAC w/o" "This is same" -> "This is the same" "That is the counter signature..." -> "That is, the counter signature..." Isn't #6.98 for COSE_Sign_Tagged?  I think the CDDL fragment needs to fixed temporarily to: COSE_CounterSignature_Tagged = #TBD0(COSE_CounterSignature) "of other than direct" -> "if other than direct"? #2: "COSE_MAC" -> "COSE_Mac"? "this new algorithms" -> "these new algorithms" "the key from next layer down" -> "the key from the next layer down" In the interests of brevity, my review focused on the diff between this document and RFC 8152. I agree with Benjamin's concern that we seem to be leaving the Designated Experts for the IANA registries described here with advice in RFC 8152, which this document renders obsolete.   I think that prose should be copied to this document so that it lives someplace current.  I was originally tempted to DISCUSS this but I'm hesitating, so I'll just say I hope this is resolved appropriately. "... structure for the CBOR objects which are ..." -- s/which/that/ "... or offline protocols, different solutions ..." -- "different" should start a new sentence "Any application which uses COSE for security ..." -- s/which/that/ The last sentence in the first paragraph: "This is same structure ..." -- s/same/the same/ "That is the counter signature ..." -- comma after "is" "... existence of the encrypted data is attested to." -- maybe "asserted" instead of "attested to"? "New algorithms will be created which will not fit ..." -- s/which/that/ In the final bullet, why aren't these MUSTs?  Or in the alternative, when would one legitimately deviate from those SHOULDs? I've only reviewed the diffs, not the historical approved text.  Everything looks okay to me.  A few minor comments/nits: I'm not familiar with the CDDL grammar, and specifically whether there is any tooling that can use the grammar to generate structures/etc.  If there is, then I think that it would be helpful if the CDDL grammar was also normative, in the sense that readers of the spec should be able to assume that the CDDL is correct.  I would still be okay with a statement that says that if there is any ambiguity between the two then the prose description should be taken as being definitive. This sentence was changed from the original formulation, but I find it slightly clunky.  Perhaps: The presence of a label, that is neither a text string nor an integer, in a CBOR map, is an error. Nit, this -> these Thanks for making an easy to read and compare bis document. Thank you for addressing my DISCUSS and COMMENT items around Counter Signatures. Thank you for the work put into this document. I really appreciate the section 1 with the detailed and clear introduction. My current workload prevented me to do a deep review, I will then rely mainly on the other Area Directors. Mostly just nits left, though the lingering errata report and the IANA updates seem somewhat significant.  (It would probably be fine to leave the nits for the RFC Editor.) It seems that https://www.rfc-editor.org/errata/eid5066 needs to be incorporated still (and the report verified, presuming it is correct). nit: we probably can just start the sentence with "COSE", since the "use in" has moved to later in the sentence. nit: s/A one/One/. nit: s/a a/a/ nit: s/plaintext is encrypted/encrypted plaintext/ (or similar?) nit: s/content encryption key (CEK) is encrypted/encrypted content encryption key (CEK)/. nit: s/An examples/An example/ I guess this is where the difficulty that Jim mentioned comes in -- the signature recovery scheme gives you the intended recovered content but also some of the other framing and such that was added as input to the signature algorithm, and you have to properly figure out where the end of the actual payload is.  (I'm not sure whether it would be useful to try to have text about the issue in this location, though.) nit: this sentence just trails off ....  I think it would be okay to just end the sentence after "is not supported", since we covered the "must recover the same [number of] bytes" previously. nit: s/ re / are / nit: s/issue2/issues/ I see that a bunch of things were changed from COSE_Encrypt to COSE_Recipient, apparently prompted by my earlier review.  I would feel more comfortable if someone confirmed that each change is correct, as I have lost some of the context here. nit: s/guidence/guidance/ We lost the section about the "CBOR Tags" registry (where we were previously allocating a codepoint for COSE_Signature).  I think we need to bring back a stub section with the directive to update the references from 8152 to this document. The references to the COSE registries should not be Normative. Thanks for addressing my issue with the IANA registration rules.

Revised text:
RFC8613 and I-D.ietf-core-groupcomm-bis.  However, COSE is not restricted to just these cases and can be used in any place where one would consider either JOSE or CMS RFC5652 for the purpose of  <ins> providing security services.  COSE, like JOSE and CMS, is only for use in store and forward or offline protocols.  The use of COSE in online protocols needing encryption, require that an online key establishment process be done before sending objects back and forth. Any application which uses COSE for security services first needs to determine what security services are required and then select the appropriate COSE structures and cryptographic algorithms based on those needs.  app-considerations provides additional information on what applications need to specify when using COSE. </ins> One feature that is present in CMS that is not present in this standard is a digest structure.  This omission is deliberate.  It is are going to be common to all applications, the two values may not always be adjacent as the algorithm could be defined once with multiple values.  Applications may additionally want to define  <ins> additional data fields as part of the structure.  One such </ins> application-specific element would be to include a URI or other pointer to where the data that is being hashed can be obtained.  I- D.ietf-cose-hash-algs contains one such possible structure along with cryptographic key, we use the term "label" for this usage as a map key.  <ins> The presence a label that is neither a text string or an integer, in a CBOR map, is an error.  Applications can either fail processing or process messages by ignoring incorrect labels; however, they MUST NOT create messages with incorrect labels. </ins> A CDDL grammar fragment defines the non-terminal 'label', as in the previous paragraph, and 'values', which permits any value to be used. different types of cryptographic concepts.  As an example of how this works, consider the COSE_Encrypt message (EnvelopedData).  This message type is broken into two layers: the content layer and the  <ins> recipient layer.  The content layer contains the encrypted plaintext and information about the encrypted message.  The recipient layer contains the encrypted content encryption key (CEK) and information about how it is encrypted for each recipient.  A single layer version of the encryption message COSE_Encrypt0 (EnvelopedData0) is provided for cases where the CEK is pre-shared. </ins> Identification of which type of message has been presented is done by the following methods: along with the signature itself.  These header parameters may be authenticated by the signature, or just present.  An example of a header parameter about the content is the content type header  <ins> parameter.  An example of a header parameter about the signature </ins> would be the algorithm and key used to create the signature. RFC 5652 indicates that: message, all of the signature algorithms are going to be required to consume the same bytes of message content.  This means that the mixing of the signature with message recovery and signature with  <ins> appendix schemes in a single message is not supported. </ins> The signature functions for this scheme are: there is a high probability that additional issues will arise when integrating message recovery signature algorithms.  The first algorithm defined is going to need to make decisions about these  <ins> issues and those decisions are likely to be binding on any further </ins> algorithms defined. We use the following terms below:  <ins> Some of the issues that have already been identified are: </ins> Signature algorithms are used with the COSE_Signature and COSE_Sign1 structures.  At the time of this writing, only signatures with 11. The registries and registrations listed below were created during  <ins> processing of RFC 8152 RFC8152.  The majority of the following actions are to update the references to point to this document. Note that while I-D.ietf-cose-rfc8152bis-algs also updates the registries and registrations originally established by RFC8152, the requested updates are mutually exclusive.  The updates requested in this document do not conflict or overlap with the updates requested in I-D.ietf-cose-rfc8152bis-algs, and vice versa. </ins> 11.1. IANA created a registry titled "COSE Header Parameters" as part of processing RFC8152.  IANA is requested to update the reference for  <ins> this registry from RFC8152 to this document.  IANA is also requested to update the reference for all entries, except "counter signature" and "CounterSignature0", in the table from RFC8152 to this document. The reference for "counter signature" and "CounterSignature0" are to be left as-is. </ins> 11.2. IANA created a registry titled "COSE Key Common Parameters" as part of the processing of RFC8152.  IANA is requested to update the  <ins> reference for this registry from RFC8152 to this document.  IANA is also requested to update the reference for entries in the table from RFC8152 to this document. </ins> 11.3.