[core] Re: Orie Steele's No Objection on draft-ietf-core-oscore-groupcomm-27: (with COMMENT)

[Marco Tiloca <[e-mail]>]

Hello Orie,

Thanks a lot for your review! Please find in line below our detailed replies to your comments.

A GitHub PR where we have addressed your comments is available at [PR].

Unless any concern is raised, we plan to soon merge this PR (and the other ones related to other received reviews) and to submit the result as version -28 of the document.

Thanks,
/Marco

[PR] https://github.com/core-wg/oscore-groupcomm/pull/120

________________________________
From: Orie Steele via Datatracker <[e-mail]>
Sent: Wednesday, October 1, 2025 9:57 PM
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Orie Steele's No Objection on draft-ietf-core-oscore-groupcomm-27: (with COMMENT)

Orie Steele has entered the following ballot position for
draft-ietf-core-oscore-groupcomm-27: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot-positions%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cdb3eb402e80242e7f7ad08de0124d16c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638949454807041367%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Xl%2FKWx0RPIX85mNA6ACa8JSOq4KfQtqJhOjAkT8lePc%3D&reserved=0<https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/>
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-core-oscore-groupcomm%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cdb3eb402e80242e7f7ad08de0124d16c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638949454807061224%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=fUqCG8h5LyBs4mnn%2FlPFPi7xlNAtkV3sRUqoXNlEKy8%3D&reserved=0<https://datatracker.ietf.org/doc/draft-ietf-core-oscore-groupcomm/>



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# Orie Steele, ART AD, comments for draft-ietf-core-oscore-groupcomm-27
CC @OR13

* line numbers:
  -
  https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fapi%2Fidnits%3Furl%3Dhttps%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-core-oscore-groupcomm-27.txt%26submitcheck%3DTrue&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cdb3eb402e80242e7f7ad08de0124d16c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638949454807074685%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2BK4finErYttOLJrMRnxB59opl9X1rBTVDwbW1F8v6gM%3D&reserved=0<https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-core-oscore-groupcomm-27.txt&submitcheck=True>

* comment syntax:
  - https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmnot%2Fietf-comments%2Fblob%2Fmain%2Fformat.md&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cdb3eb402e80242e7f7ad08de0124d16c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638949454807087425%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=WvHuIEwbVJCo1B7k%2BnbusNA1tMlXdt3Q5APx9JeG3lA%3D&reserved=0<https://github.com/mnot/ietf-comments/blob/main/format.md>

* "Handling Ballot Positions":
  - https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot-positions%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cdb3eb402e80242e7f7ad08de0124d16c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638949454807100644%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=jC%2BONDsawIxXgJBM%2FZFS4zs0wMz%2BAGlGKdHKqgRu2cc%3D&reserved=0<https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/>

## Comments

Thanks to Patrik Fältström for the ARTART review.
The review contains security related comments which I am not in a position to
comment on.

### public key algorithm is fully described?

```
776        If authentication credentials are CBOR Web Tokens (CWTs) or CWT
777        Claims Sets (CCSs), the public key algorithm is fully described by a
778        COSE key type and its "kty" and "crv" parameters.
```

https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fcose%2Fcose.xhtml%23elliptic-curves&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cdb3eb402e80242e7f7ad08de0124d16c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638949454807113810%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=DhUUhbT41FmUpfshsZTVlwZJDzMSmPwuDD7vzLFQsHU%3D&reserved=0<https://www.iana.org/assignments/cose/cose.xhtml#elliptic-curves>

Later:

```
897           In case the other endpoint's public key has COSE Key Type "EC2"
898           [RFC9053] (e.g., for the curves P-256, P-384, and P-521), then the
899           public key is used as is.  In case the other endpoint's public key
900           has COSE Key Type "OKP" [RFC9053], the procedure is described in
901           Section 5 of [RFC7748].  In particular, if the public key is for
902           X25519 or X448, it is used as is.  Otherwise, if the public key is
903           for the curve Ed25519 or Ed448, it is first mapped to Montgomery
904           coordinates (see Section 2.5.2).
```

X25519 is curve value 4, but Ed25519 is curve value 6, both are OKP (good).
However, P-256 is curve value 1, and supports many algorithms and is of key
type EC2.

> This document defines these algorithms to be used with the curves P-256,
P-384, P-521, X25519, and X448. Implementations MUST verify that the key type
and curve are correct.

https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc9053.html%23section-6.3.1-8&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cdb3eb402e80242e7f7ad08de0124d16c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638949454807129313%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=FetqLu46ka%2BKUigoHpDoPeDKS49IrbVxeg1xmsAcQ9I%3D&reserved=0<https://www.rfc-editor.org/rfc/rfc9053.html#section-6.3.1-8>

I don't understand what "fully described" means in this context.
A key type and curve do not fully describe a key agreement or signature
algorithm in absence of additional information.


==>MT

We have rephrased the quoted paragraph in Section 2.4 as below, also fixing s/COSE key type/COSE Key structure.

OLD
> If authentication credentials are CBOR Web Tokens (CWTs) or CWT Claims Sets (CCSs), the public key algorithm is fully described by a COSE key type and its "kty" and "crv" parameters.

NEW
> If authentication credentials are CBOR Web Tokens (CWTs) or CWT Claims Sets (CCSs), then a COSE Key structure and its "kty" and "crv" parameters identify the types of pertinent public key algorithms. For example: the pair ("crv" = X25519, "kty" = OKP) indicates that the public key is meant to be used with X25519 ECDH key agreement; the pair ("crv" = Ed25519, "kty" = OKP) indicates that the public key is meant to be used with the signature algorithm EdDSA; the pair ("crv" = P-256, "kty" = EC2) indicates that the public key is meant to be used with the signature algorithm ECDSA and/or with P-256 ECDH key agreement.

For consistency, we have also made a minor fix in the previous paragraph of the same section. In that case, we are referring to a parameter that explicitly points to a precise algorithm by its identifier.

OLD
> If the authentication credentials are X.509 certificates or C509 certificates, the public key algorithm is fully described by the "algorithm" field of the "SubjectPublicKeyInfo" structure, and by the "subjectPublicKeyAlgorithm" element, respectively.

NEW (emphasis mine)
> If the authentication credentials are X.509 certificates or C509 certificates, the public key algorithm is **identified** by the "algorithm" field of the "SubjectPublicKeyInfo" structure, and by the "subjectPublicKeyAlgorithm" element, respectively.

<==