CBOR Object Signing and Encryption
charter-ietf-cose-03

* "Potential candidate would not" -> "Potential candidates would not"

Not familiar with COSE, but, is "attributes for COSE" a well-understood terminology ?

If not mistaken, "i.e." must be followed by a comma (but, hey, English is not my native language, so, can be wrong).

In "The WG currently has two deliverables", suggest replace "deliverables" by "work items".

The amount of descriptions/restrictions for the CBOR encoding for a certificate compared to nearly no descriptions/restrictions for the other "deliverable" is really surprising. Is there a COSE WG consensus on this second deliverable ?

Suggest to move the § starting with "The working group will coordinate its progress " at the end of the charter as it is often the case.

Paragraph 9, comment:
> 2. A CBOR encoding of the certificate profile defined in RFC 5280.
> It is expected that the encoding works with RFC 7925 and takes into
> consideration any updates in draft-ietf-uta-tls13-iot-profile-00.  The
> encoding may also include other important IoT certificate profiles like IEEE
> 802.1AR.
> The main objective is to define a method of encoding current X.509
> certificates that meet a specific profile into a smaller format. This encoding
> is invertible so they can be expanded and normal X.509 certificate processing
> used.  The data structures used for such encoding of X.509 certificates are
> expected to produce a compact encoding for certificate information, and are
> not necessarily tied specifically to X.509 certificates.  Accordingly, a
> secondary objective is to reuse these data structures to produce a natively
> signed CBOR certificate encoding; such a structure is relevant in situations
> where DER parsing and the machinery to convert between CBOR and DER encodings
> are unnecessary overhead, such as embedded implementations.  The possibility
> of a joint certificate artifact, conveyed in CBOR encoding but including
> signatures over both the CBOR and DER encodings, may be explored.  CBOR
> encoding of other X.509 certificate related data structures may also be
> specified to support relevant functions such as revocation: Certificate
> Revocation List (RFC 5280) or OSCP Request/Response (RFC 6960); or certificate
> enrolment: Certificate Signing Request (RFC 2986).  This work will be based on
> draft-mattsson-cose-cbor-cert-compress.  The working group will collaborate
> and coordinate with other IETF WGs such as TLS, UTA, LAKE to understand and
> validate the requirements and solution.

This seems very detailed for a charter. Also, basing chartered work on
(individual) I-Ds might run into issues.

-------------------------------------------------------------------------------
All comments below are very minor change suggestions that you may choose to
incorporate in some way (or ignore), as you see fit. There is no need to let me
know what you did with these suggestions.

Paragraph 1, nit:
- within the IETF (i.e. ACE, CORE, ANIMA, 6TiSCH and SUIT) as well as
                                                            ^^^^^^^^^
- outside of the IETF (i.e. W3C and FIDO). There are a number of
         ---
+ within the IETF (i.e., ACE, CORE, ANIMA, 6TiSCH and SUIT) and
                       +                                     ^^
+ outside the IETF (i.e., W3C and FIDO). There are a number of
                        +

Paragraph 3, nit:
- which would fit the criteria of being IETF consensus algorithms.
  ^ ^^^
- Potential candidates would include those algorithms which have been evaluated by
                                                      ^ ^^^
+ that would fit the criteria of being IETF consensus algorithms.
  ^ ^^
+ Potential candidates would include those algorithms that have been evaluated by
                                                      ^ ^^

Paragraph 4, nit:
- Potential candidate would not include national standards based algorithms
                                                ^         ^
- which have not gone through a similar public review process.
  ^ ^^^
+ Potential candidates would not include national-standards-based algorithms
                     +                           ^         ^
+ that have not gone through a similar public review process.
  ^ ^^

Paragraph 5, nit:
- attributes which are not in charter but are of general public interest.
             ^ ^^^           ^
+ attributes that are not in-charter but are of general public interest.
             ^ ^^           ^

Paragraph 6, nit:
- CORE working groups to ensure that we are fulfilling the needs of
                                     ^^ ^^^
+ CORE working groups to ensure that it is fulfilling the needs of
                                     ^^ ^^

Paragraph 9, nit:
- is invertible so they can be expanded and normal X.509 certificate processing
+ is invertible, so they can be expanded and normal X.509 certificate processing be
               +                                                                +++

Paragraph 9, nit:
- enrolment: Certificate Signing Request (RFC 2986).  This work will be based on
+ enrollment: Certificate Signing Request (RFC 2986).  This work will be based on
      +