Original text:
D.ietf-cose-rfc8152bis-struct. An example of a countersignature on a signature can be found in <del> Appendix_B_1_3.  An example of a countersignature in an encryption object can be found in Appendix_B_3_3. </del>  It should be noted that only a signature algorithm with appendix (see I-D.ietf-cose-rfc8152bis-struct) can be used for countersignatures. processing RFC8152. IANA is requested to register the following new items in the <del> registry. </del>  IANA is requested to modify the Description field for "counter signature" and "CounterSignature0" to include the words "(Deprecated 6. <del> TODO - review and trim as needed. </del> There are a number of security considerations that need to be taken into account by implementers of this specification.  While some considerations have been highlighted here, additional considerations multiple algorithms has been demonstrated in some cases to leak information about that key, provide the opportunity for attackers to forge integrity tags, or gain information about encrypted content. <del> Binding a key to a single algorithm prevents these problems.  Key creators and key consumers are strongly encouraged not only to create new keys for each different algorithm, but to include that selection of algorithm in any distribution of key material and strictly enforce the matching of algorithms in the key structure to algorithms in the message structure.  In addition to checking that algorithms are correct, the key form needs to be checked as well.  Do not use an 'EC2' key where an 'OKP' key is expected. </del>  Before using a key for transmission, or before acting on information received, a trust decision on a key needs to be made.  Is the data or with this trust decision.  Some of the ones that are highlighted here are: <del> One area that has been getting exposure is traffic analysis of encrypted messages based on the length of the message.  This specification does not provide for a uniform method of providing padding as part of the message structure.  An observer can distinguish between two different messages (for example, 'YES' and 'NO') based on the length for all of the content encryption algorithms that are defined in I-D.ietf-cose-rfc8152bis-algs document.  This means that it is up to the applications to document how content padding is to be done in order to prevent or discourage such analysis.  (For example, the text strings could be defined as 'YES' and 'NO '.) </del>  7.

Reviewer comments:
Remove the sections from the Examples Applenix that were blank, clean up the Security Considerations, and narrow the table in the IANA considerations.
Looks good to me! Thanks! Let us know if you want us to merge it or you plan to do that yourself.

Revised text:
D.ietf-cose-rfc8152bis-struct. An example of a countersignature on a signature can be found in  <ins> Appendix_A_1_1.  An example of a countersignature in an encryption object can be found in Appendix_A_2_1. </ins> It should be noted that only a signature algorithm with appendix (see I-D.ietf-cose-rfc8152bis-struct) can be used for countersignatures. processing RFC8152. IANA is requested to register the following new items in the  <ins> registry.  For these entries, the Value Registry column will be blank and the Reference column will be [[This Document]]. </ins> IANA is requested to modify the Description field for "counter signature" and "CounterSignature0" to include the words "(Deprecated 6.  There are a number of security considerations that need to be taken into account by implementers of this specification.  While some considerations have been highlighted here, additional considerations multiple algorithms has been demonstrated in some cases to leak information about that key, provide the opportunity for attackers to forge integrity tags, or gain information about encrypted content.  <ins> Binding a key to a single algorithm prevents these problems. Key creators and key consumers are strongly encouraged not only to create new keys for each different algorithm, but to include that selection of algorithm in any distribution of key material and strictly enforce the matching of algorithms in the key structure to algorithms in the message structure.  In addition to checking that algorithms are correct, the key form needs to be checked as well.  Do not use an 'EC2' key where an 'OKP' key is expected. </ins> Before using a key for transmission, or before acting on information received, a trust decision on a key needs to be made.  Is the data or with this trust decision.  Some of the ones that are highlighted here are:  <ins> Analysis of the size of encrypted messages can provide information about the plaintext messages.  This specification does not provide a uniform method for padding messages prior to encryption.  An observer can distinguish between two different messages (for example, 'YES' and 'NO') based on the length for all of the content encryption algorithms that are defined in I-D.ietf-cose-rfc8152bis-algs.  This means that it is up to the applications to specify how content padding is to be done to prevent or discourage such analysis.  (For example, the text strings could be defined as 'YES' and 'NO '.) </ins> 7.