I am the assigned ART directorate reviewer for this document. These comments 
were written primarily for the benefit of the ART area directors. Document editors 
and WG chairs should treat these comments just like any other last call comments.

The document defines hybrid public-key encryption (HPKE) for use with CBOR Object Signing and Encryption (COSE).


Minor issues.

1. Section 3.1, last para.
"The PSK value itself is an external input to HPKE and MUST NOT be encoded in the COSE structure."

I think that "MUST NOT" is not appropriate here. It implies that it is ever _possible_
for a sender to encode PSK, but it is _forbidden_ by this specification. In fact, this specification 
does not provide any means to encode PSK, so it is _not_possible_ for a sender to encode it.
Thus, the text should just say: "The PSK value itself is an external input to HPKE and is not encoded in the COSE structure."

2. Section 3.2, 3rd para.
"If the COSE_Encrypt0 structure includes a "kid" parameter, the recipient MAY
use it to select the corresponding private key.". 

What is the purpose of this sentence (especially that it includes an RFC 2119 language)? As far as I understand, 
the use of the "kid" parameter is defined in RFC 9052 Sections 3.1
("The value of this header parameter can be matched against the "kid" member in a COSE_Key structure."), 
so why to repeat it here? Am I missing something and the use of "kid" for COSE-HPKE is different?

3. Section 3.2, 2 instances.
"Externally provided AAD information MAY be provided and
MUST be passed into the Enc_structure via the external_aad field.". 

What "MUST be passed" if AAD is not provided?
Perhaps more formally: "Externally provided AAD information MAY be provided and, if provided, 
MUST be passed into the Enc_structure via the external_aad field.".

4. Section 3.3.2, 6th para
"While the "alg" header parameter is not strictly required in the
COSE_Recipient, if present, it must be the ciphersuite used to
specify the HPKE algorithms.  See Section 4.  If the "alg" header
parameter is present, it MUST be a protected header parameter."

Why the lowercase "must" is used for the first requirement and the 
uppercase "MUST" for the second one? Sholdn't both be "MUST"?



Nits:

1. Section 3.1, last para.
"HPKE defines several authentication modes, as described in Table 1 of [I-D.ietf-hpke-hpke].".

In fact, the HPKE specification defines exactly 2 authentication modes. Perhaps it is more helpful
for readers if the text will be changed to "HPKE defines two authentication modes, as described 
in Table 1 of [I-D.ietf-hpke-hpke].", especially since all the following discussions imply that
there are only two possible modes.

2. Section 3.3.1, first para.
The first mention of COSE_KDF_Context does not provide any reference where it is defined.
It is only clarified in Section 3.3.3. Since it is not part of core COSE specification
and is defined in an Informational RFC, I think that it would be helpful for readers if 
a reference is given on first use.

3. Section 3.4, 1st bullet in the list.
"*  If the "kty" field is "AKP", then the public and private keys
SHALL be the raw HPKE public and private keys (respectively) for
the KEM used by the algorithm." 

This is the only use of "SHALL" in the document. Can it be changed to "MUST" just for consistency?