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

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]."

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.

# É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

# 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