CBOR Object Signing and Encryption (COSE): Countersignatures
draft-ietf-cose-countersign-10

[Ballot comment]
Thanks for addressing my DISCUSS. I updated my ballot to YES.

Old DISCUSS:

        gem install cbor-diag

I am concerned about adding install commands for "programs from the internet"
within an RFC. If the rubygem for some reason becomes malicious, we cannot
pull it from the RFC (even if we pull it from the datatracker link, it would
still live on in copies of the RFC elsewhere and malicious people could point
to copies of those original RFCs to point people to downlod the malicious rubygem.

I would be okay with an iet.org download location of a ruby gem.

NITS:

        CBOR grammar in this document is uses

Remove "is"

        to deal with > as an entity

This is a render error for '>'  ?

        they apply

these apply

        Languages: There are three different languages that are currently
        supported: Java and C#.

That's two not three? Text below suggests there might be a 3rd one in C ?

[Ballot comment]
# GEN AD review of draft-ietf-cose-countersign-09

CC @larseggert

Thanks to Elwyn Davies for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/jrTPQpNSafEhkpyMYn3r250_ghM).

## Comments

### Missing references

No reference entries found for: `[RFC8949]`.

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `traditional`; alternatives might be `classic`, `classical`, `common`,
  `conventional`, `customary`, `fixed`, `habitual`, `historic`,
  `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
  `time-honored`, `universal`, `widely used`, `widespread`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Outdated references

Reference `[RFC8152]` to `RFC8152`, which was obsoleted by `RFC9052` and
`RFC9053` (this may be on purpose).

### Grammar/style

#### Section 1, paragraph 3
```
structure where there is no cryptographic computed value. The new algorithm d
                            ^^^^^^^^^^^^^^^^^^^^^^
```
Make sure that the adjective "cryptographic" is correct. Possibly, it should be
an adverb (typically ~ly) that modifies "computed". Possibly, it should be the
first word in a compound adjective (hyphenated adjective). Possibly, it is
correct.

#### Section 1, paragraph 5
```
mar CBOR grammar in this document is uses the CBOR Data Definition Language
                                  ^^^^^^^
```
The verb form seems incorrect.

#### Section 1.2, paragraph 7
```
of the context can come from several different sources including: protocol i
                              ^^^^^^^^^^^^^^^^^
```
Consider using "several".

#### Section 3.2, paragraph 1
```
untersignature needs to have all of it's cryptographic functions finalized b
                                    ^^^^
```
Did you mean "its" (possessive pronoun) instead of "it's" (short for "it is")?

#### Section 3.3, paragraph 22
```
Value Registry column will be blank and the Reference column will be [[This
                                    ^^^^
```
Use a comma before "and" if it connects two independent clauses (unless they
are closely connected and short).

#### Section 7, paragraph 4
```
e and algorithm in the document. Currently examples dealing with countersign
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Currently".

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

there are editorial nits in https://www.ietf.org/archive/id/draft-ietf-cose-countersign-09.html#name-cose-header-parameters-regi

The description text in existing registrations is not using title case, and I believe "V2 Abbreviated Countersignature” shouldn’t either.
Unfortunately, the text of the specification has a lot of variance in how things are named, and it is not easy to determine which names should be used in the registration.

(Table 1, with which this Table 2 needs to be aligned, uses different names in several places.
It also has a typo, “vesion”.)

There don’t appear to be any substantive issues with the registration in Section 5.2.
Assuming that the names are aligned after an editorial round, the registration can go forward.

[Ballot comment]
I support Paul's DISCUSS.

The shepherd writeup is over a year old.  It says Ben Kaduk is the sponsoring AD.

BCP 14 language is so sparsely used that you might consider not using it at all.

We miss you, Jim.

[Ballot comment]
The shepherd writeup is over a year old.  It says Ben Kaduk is the sponsoring AD.

BCP 14 language is so sparsely used that you might consider not using it at all.

We miss you, Jim.

[Ballot comment]
The shepherd writeup is over a year old.  It says Ben Kaduk is the sponsoring AD.

BCP 14 language is so sparsely used that you might consider not using it at all.

[Ballot discuss]
        gem install cbor-diag

I am concerned about adding install commands for "programs from the internet"
within an RFC. If the rubygem for some reason becomes malicious, we cannot
pull it from the RFC (even if we pull it from the datatracker link, it would
still live on in copies of the RFC elsewhere and malicious people could point
to copies of those original RFCs to point people to downlod the malicious rubygem.

I would be okay with an iet.org download location of a ruby gem.

[Ballot comment]
ITS:

        CBOR grammar in this document is uses

Remove "is"

        to deal with > as an entity

This is a render error for '>'  ?

        they apply

these apply

        Languages: There are three different languages that are currently
        supported: Java and C#.

That's two not three? Text below suggests there might be a 3rd one in C ?

[Ballot discuss]
# GEN AD review of draft-ietf-cose-countersign-09

CC @larseggert

Thanks to Elwyn Davies for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/jrTPQpNSafEhkpyMYn3r250_ghM).

## Discuss

### IANA

This document seems to have unresolved IANA issues. Holding a DISCUSS for IANA,
so we can determine next steps during the telechat.

[Ballot comment]
## Comments

### Missing references

No reference entries found for: `[RFC8949]`.

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `traditional`; alternatives might be `classic`, `classical`, `common`,
  `conventional`, `customary`, `fixed`, `habitual`, `historic`,
  `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
  `time-honored`, `universal`, `widely used`, `widespread`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Outdated references

Reference `[RFC8152]` to `RFC8152`, which was obsoleted by `RFC9052` and
`RFC9053` (this may be on purpose).

### Grammar/style

#### Section 1, paragraph 3
```
structure where there is no cryptographic computed value. The new algorithm d
                            ^^^^^^^^^^^^^^^^^^^^^^
```
Make sure that the adjective "cryptographic" is correct. Possibly, it should be
an adverb (typically ~ly) that modifies "computed". Possibly, it should be the
first word in a compound adjective (hyphenated adjective). Possibly, it is
correct.

#### Section 1, paragraph 5
```
mar CBOR grammar in this document is uses the CBOR Data Definition Language
                                  ^^^^^^^
```
The verb form seems incorrect.

#### Section 1.2, paragraph 7
```
of the context can come from several different sources including: protocol i
                              ^^^^^^^^^^^^^^^^^
```
Consider using "several".

#### Section 3.2, paragraph 1
```
untersignature needs to have all of it's cryptographic functions finalized b
                                    ^^^^
```
Did you mean "its" (possessive pronoun) instead of "it's" (short for "it is")?

#### Section 3.3, paragraph 22
```
Value Registry column will be blank and the Reference column will be [[This
                                    ^^^^
```
Use a comma before "and" if it connects two independent clauses (unless they
are closely connected and short).

#### Section 7, paragraph 4
```
e and algorithm in the document. Currently examples dealing with countersign
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Currently".

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]
Thanks, Russ, for your work on getting this very readable document over the
finish line. Below are a few nits I noted while reviewing it.

- "migrate used of the previous" --> "migrate uses of the previous"
- "CBOR grammar in this document is uses" --> "CBOR grammar in this document uses"
- "More information on how countersignatures
  is used" --> "More information on how countersignatures
  are used"
- "it's cryptographic functions" -> "its cryptographic functions"
- "The deterministic encoding rules defined in Section 4.2 of [RFC8949]." -> "The deterministic encoding rules are defined in Section 4.2 of [RFC8949]."

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-cose-countersign-09
CC @evyncke

Thank you, Russ, for finishing the work put into this document.

Please find below some non-blocking COMMENT points , and some nits.

Special thanks to Michael Richardson for the shepherd's detailed write-up including the WG consensus even if there is no justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### Abstract and/or introduction

A concise definition of countersignature (e.g., from section 3) would make the document more readable.

### Section 1

```
  With the publication of this document, implementers are encouraged to
  migrate used of the previous countersignature algorithm to the one
  specified in this document.
```
Is it "used" or "uses" ?

### STD94

The reference in 4 should be to STD94 rather than RFC8949 (or change the anchor in the references).

### Section 3.2

`The attribute is defined below.` perhaps adding a reference (even if just to confirm that it is section 3.3) ?

### Section 3.3

`external_aad` adding an expansion for "aad" will probably help the reader.

### IANA considerations

`The majority of the actions are to update the references to point to this document.`, suggest to add a sub-section for this part and be specific about the registry.

## NITS

### Section 1.2
```
  CBOR grammar in this document is uses the CBOR Data Definition
  Language (CDDL) [RFC8610].
```
"is" should probably be removed

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot comment]
Russ, I would like to say thank you for shepherding this document through the IETF process on Jim's behalf.

Minor level comments:

(2) p 4, sec 2.  Countersignature Header Parameters

      following structures: COSE_Sign1, COSE_Signature, COSE_Encrypt,
      COSE_recipient, COSE_Encrypt0, COSE_Mac, and COSE_Mac0.

It wasn't intuitive to me where these structures are defined.  I found them in RFC 8152, but perhaps it would be clearer if the document terminology explicitly referenced them?


(3) p 5, sec 2.  Countersignature Header Parameters

  every map; header parameters required in specific maps are discussed
  above.

It's not clear to me what this sentence is referring to, i.e., where parameters are specified as actually being required.


(4) p 9, sec 3.3.  Signing and Verification Process

  3.  Call the signature verification algorithm passing in K (the key
      to verify with), alg (the algorithm used sign with), ToBeSigned
      (the value to sign), and sig (the signature to be verified).

This may be a daft question, but is the signature to be verified the "COSE_Countersignature[0] structure, or the "signature" field contained within it?  I presume the latter, will this be obvious to readers?



Nit level comments:

(5) p 7, sec 3.1.  Full Countersignatures

  term archiving services.  More information on how countersignatures
  is used can be found in the evidence record syntax described in

s/is used/are used/


(6) p 7, sec 3.1.  Full Countersignatures

        COSE_Countersignature_Tagged = #6.9999(COSE_Countersignature)
        COSE_Countersignature = COSE_Signature

Am I right to presume that #6.9999 is a temporary value to replaced with CBOR TBD0, perhaps worth flagging this to the RFC editor so that it doesn't get missed during the editing process?


(7) p 12, sec 7.1.  Author's Versions

  *  Languages: There are three different languages that are currently
      supported: Java and C#.

Should that be two languages, or are you missing one?


(8) p 12, sec 7.1.  Author's Versions

  *  Coverage: Both implementations can produce and consume both the
      old and new countersignatures.

Both implies two, but the beginning of section 7.1. states 3 implementations.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-cose-countersign-06. If any part of this review is inaccurate, please let us know.

IANA has a question about one of the actions requested in the current draft.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the CBOR Tags registry located on the Concise Binary Object Representation (CBOR) Tags registry page located at:

https://www.iana.org/assignments/cbor-tags/

a new registration will be made as follows:

Tag: [ TBD-at-Registration ]
Data Item: COSE_Countersignature
Semantics: COSE standalone V2 countersignature
Reference: [ RFC-to-be ]

IANA Question --> What range in the CBOR Tags registry should this registration come from?

Second, in the COSE Header Parameters registry on the CBOR Object Signing and Encryption (COSE) registry page located at:

https://www.iana.org/assignments/cose/

two new registrations will be made as follows:

Name: Countersignature version 2
Label: [ TBD-at-Registration ]
Value Type: COSE_Countersignature / [+ COSE_Countersignature ]
Value Registry:
Description: V2 countersignature attribute
Reference: [ RFC-to-be ]

Name: Countersignature0 version 2
Label: [ TBD-at-Registration ]
Value Type: COSE_Countersignature0
Value Registry:
Description: V2 Abbreviated Countersignature
Reference: [ RFC-to-be ]

IANA Question --> What range in the COSE Header Parameters registry should these registrations come from?

Third, also in the COSE Header Parameters registry on the CBOR Object Signing and Encryption (COSE) registry page located at:

https://www.iana.org/assignments/cose/

the following two, existing registrations:

Name: counter signature
Label: 7

Name: CounterSignature0
Label: 9

will have their description fields supplemented with the words "(Deprecated by [ RFC-to-be ])."

The IANA Functions Operator understands that these three actions are the only ones required to be completed upon approval of this document.


Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

Michelle Thangtamsatid
IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-08-10):

From: The IESG
To: IETF-Announce
CC: cose-chairs@ietf.org, cose@ietf.org, draft-ietf-cose-countersign@ietf.org, mcr+ietf@sandelman.ca, rdd@cert.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (CBOR Object Signing and Encryption (COSE): Countersignatures) to Internet Standard


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'
  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@ietf.org mailing lists by 2022-08-10. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Concise Binary Object Representation (CBOR) is a data format designed
  for small code size and small message size.  CBOR Object Signing and
  Encryption (COSE) defines a set of security services for CBOR.  This
  document defines a countersignature algorithm along with the needed
  header parameters and CBOR tags for COSE.  This document updates RFC
  INSERT the number assigned to [I-D.ietf-cose-rfc8152bis-struct].




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-cose-countersign/



No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper
type of RFC? Is this type of RFC indicated in the title page header?

This is a Standards Track RFC.
This is the correct type, and it is indicated in the document.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

When RFC8152 was evaluated in it's move from Proposed Standard to Internet
Standard (and split into Algs and Structures documents), it was realized that
the Countersign aspects of RFC8152 were inconsistently described in certain
uses.  While current users of RFC8152 do not use countersignatures in the way
that is inconsistent, new users could wind up with non-interoperable
implementations.
Countersignatures were therefore considered not mature enough to move to
Internet Standard, and were removed from RFC8152bis, and placed into this
document.

Technical Summary:

  During the process of advancing COSE to an Internet Standard, it was
  noticed the description of the security properties of
  countersignatures was incorrect for the COSE_Sign1 structure.  Since
  the security properties that were described, those of a true
  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.

Working Group Summary:

  The WG thought long and hard about what result they wanted, and ultimately
  the decision to remove countersignatures from RFC8152bis-struct was made
  in a mature and well reasoned fashion.
  Jim Schaad led process, and this documents is among the last that he authored.

Document Quality:

There is an implementation status in the Internet-draft, and it includes only
an implementation in Java and C# by Jim Schaad.

While CBOR, and COSE, particularly COSE_Sign1 is widely implemented, the use
of counter signatures is a niche solution to unique situations.
OSCORE (RFC8613) is a user of countersignatures in their original,
non-ambiguous formulation.

Personnel:

Who is the Document Shepherd?          Michael Richardson
Who is the Responsible Area Director?  Ben Kaduk

(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the IESG.

The document shepherd read all of the versions of the document as they were
produced in 2020.

(4) Does the document Shepherd have any concerns about the depth or breadth
of the reviews that have been performed?

The document shepherd has a minor concern that there are not more
implementation efforts, but that is not a requirement for PS.

(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has
with this document that the Responsible Area Director and/or the IESG should
be aware of? For example, perhaps he or she is uncomfortable with certain
parts of the document, or has concerns whether there really is a need for
it. In any event, if the WG has discussed those issues and has indicated that
it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?

No. The primary author is deceased.

(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR is known.

(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does
the WG as a whole understand and agree with it?

The WG was heavily involved in creating this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate email
messages to the Responsible Area Director. (It should be in a separate email
because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No nits.

(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None required.

(13) Have all references within this document been identified as either normative or informative?

Yes.
(Probably I-D.ietf-cbor-7049bis could be replaced with RFC8949 now, but the
RFC-editor will take care of that)

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.
The document has a normative reference to I-D.ietf-cose-rfc8152bis-algs,
which perhaps could be replaced with RFC8152 itself.
It is probably not a problem if they are published as a group.

(15) Are there downward normative references references (see RFC 3967)? If
so, list these downward references to support the Area Director in the Last
Call procedure.

No.

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the abstract,
and discussed in the introduction? If the RFCs are not listed in the Abstract
and Introduction, explain why, and point to the part of the document where
the relationship of this document to the other RFCs is discussed. If this
information is not in the document, explain why the WG considers it
unnecessary.

*maybe* draft-ietf-cose-countersign-02 be marked as Updates: RFC8152 (Amends).

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes are
associated with the appropriate reservations in IANA registries. Confirm that
any referenced IANA registries have been clearly identified. Confirm that
newly created IANA registries include a detailed specification of the initial
contents for the registry, that allocations procedures for future
registrations are defined, and a reasonable name for the new registry has
been suggested (see RFC 8126).

No concerns.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries.

none.

(19) Describe reviews and automated checks performed by the Document Shepherd
to validate sections of the document written in a formal language, such as
XML code, BNF rules, MIB definitions, YANG modules, etc.

idnits.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No YANG MODULE.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper
type of RFC? Is this type of RFC indicated in the title page header?

This is a Standards Track RFC.
This is the correct type, and it is indicated in the document.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

When RFC8152 was evaluated in it's move from Proposed Standard to Internet
Standard (and split into Algs and Structures documents), it was realized that
the Countersign aspects of RFC8152 were inconsistently described in certain
uses.  While current users of RFC8152 do not use countersignatures in the way
that is inconsistent, new users could wind up with non-interoperable
implementations.
Countersignatures were therefore considered not mature enough to move to
Internet Standard, and were removed from RFC8152bis, and placed into this
document.

Technical Summary:

  During the process of advancing COSE to an Internet Standard, it was
  noticed the description of the security properties of
  countersignatures was incorrect for the COSE_Sign1 structure.  Since
  the security properties that were described, those of a true
  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.

Working Group Summary:

  The WG thought long and hard about what result they wanted, and ultimately
  the decision to remove countersignatures from RFC8152bis-struct was made
  in a mature and well reasoned fashion.
  Jim Schaad led process, and this documents is among the last that he authored.

Document Quality:

There is an implementation status in the Internet-draft, and it includes only
an implementation in Java and C# by Jim Schaad.

While CBOR, and COSE, particularly COSE_Sign1 is widely implemented, the use
of counter signatures is a niche solution to unique situations.
OSCORE (RFC8613) is a user of countersignatures in their original,
non-ambiguous formulation.

Personnel:

Who is the Document Shepherd?          Michael Richardson
Who is the Responsible Area Director?  Ben Kaduk

(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the IESG.

The document shepherd read all of the versions of the document as they were
produced in 2020.

(4) Does the document Shepherd have any concerns about the depth or breadth
of the reviews that have been performed?

The document shepherd has a minor concern that there are not more
implementation efforts, but that is not a requirement for PS.

(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has
with this document that the Responsible Area Director and/or the IESG should
be aware of? For example, perhaps he or she is uncomfortable with certain
parts of the document, or has concerns whether there really is a need for
it. In any event, if the WG has discussed those issues and has indicated that
it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?

No. The primary author is deceased.

(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR is known.

(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does
the WG as a whole understand and agree with it?

The WG was heavily involved in creating this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate email
messages to the Responsible Area Director. (It should be in a separate email
because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No nits.

(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None required.

(13) Have all references within this document been identified as either normative or informative?

Yes.
(Probably I-D.ietf-cbor-7049bis could be replaced with RFC8949 now, but the
RFC-editor will take care of that)

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.
The document has a normative reference to I-D.ietf-cose-rfc8152bis-algs,
which perhaps could be replaced with RFC8152 itself.
It is probably not a problem if they are published as a group.

(15) Are there downward normative references references (see RFC 3967)? If
so, list these downward references to support the Area Director in the Last
Call procedure.

No.

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the abstract,
and discussed in the introduction? If the RFCs are not listed in the Abstract
and Introduction, explain why, and point to the part of the document where
the relationship of this document to the other RFCs is discussed. If this
information is not in the document, explain why the WG considers it
unnecessary.

*maybe* draft-ietf-cose-countersign-02 be marked as Updates: RFC8152 (Amends).

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes are
associated with the appropriate reservations in IANA registries. Confirm that
any referenced IANA registries have been clearly identified. Confirm that
newly created IANA registries include a detailed specification of the initial
contents for the registry, that allocations procedures for future
registrations are defined, and a reasonable name for the new registry has
been suggested (see RFC 8126).

No concerns.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries.

none.

(19) Describe reviews and automated checks performed by the Document Shepherd
to validate sections of the document written in a formal language, such as
XML code, BNF rules, MIB definitions, YANG modules, etc.

idnits.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No YANG MODULE.