Here is review I did about draft-ietf-cose-hpke-05.
> title: Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object
> Signing and Encryption (COSE)
> abbrev: COSE HPKE
> ipr: pre5378Trust200902
Why pre5378? What content does that (rather annoying seeming
disclaimer) refer to (I can't find anything relevant)?
> normative:
> RFC2119:
> RFC8174:
> RFC9180:
> RFC9052:
> RFC9053:
I think RFC 9053 is a border case if it is normative or informative
(the only real use is one optional structure). If this remains std
track, moving the reference would avoid a downref (the downref to
9180 is not going to be a problem).
> The HPKE specification defines several features for use with public
> key encryption and a subset of those features is applied to COSE
> ({{RFC9052}}, {{RFC9053}}). Since COSE provides constructs for
> authentication, those are not re-used from the HPKE specification.
> This specification uses the "base" mode, as it is called in HPKE
> specification language.
Is there a need to reference RFC 9053 here?
> The CDDL grammar describing the HPKE_sender_info structure is:
>
> ~~~
> HPKE_sender_info = [
> kem_id : uint, ; kem identifier
> kdf_id : uint, ; kdf identifier
> aead_id : uint, ; aead identifier
> enc : bstr, ; encapsulated key
> ]
> ~~~
If one wanted to be really precise, the type of 'kem_id' and 'kdf_id' is
'uint .lt 65536' and type of 'aead_id' is 'uint .lt 65535' (aead_id
65535 has a special meaning in HPKE).
> - Layer 1 (corresponding to a recipient structure) contains parameters
> needed for HPKE to generate a shared secret used to encrypt the CEK.
> This layer conveys the encrypted CEK in the encCEK structure. The
> protected header MUST contain the HPKE alg parameter and the
> unprotected header MUST contain the HPKE_sender_info structure.
> The unprotected header MAY contain the kid parameter to identify the
> static recipient public key the sender has been using with HPKE.
encCEK structure? I would not call bstr a structure. And looks like
RFC 9052 calls that field 'ciphertext'.
> The external_aad field in the Enc_structure contains the Externally
> Supplied Data described in Section 4.3 and Section 5.3 in RFC 9052.
> In the COSE_Encrypt case this AAD information is also input to the
> AAD at layer 0, if an AEAD cipher is used at layer 0. If this field
> is not supplied, it defaults to a zero-length byte string.
I think that AAD at layer 0 and layer 1 should be specified
independently, both defaulting to zero-length byte string.
> This section provides a suggestion for constructing the info
> structure, when used with SealBase() and OpenBase(). HPKE leaves the
> info parameter for these two functions as optional. Application
> profiles of this specification MAY populate the fields of the
> COSE_KDF_Context structure or MAY use a different structure as input
> to the "info" parameter. If no content for the "info" parameter is not
> supplied, it defaults to a zero-length byte string.
Any guidance how to set keyDataLength if using COSE_KDF_Context? 0?
HPKE uses multiple different KDF output lengths, and does the
length separation internally anyway.
> This specification re-uses the context information structure defined
> in {{RFC9053}} as a foundation for the info structure. This payload
> becomes the content of the info parameter for the HPKE functions,
> when utilized. For better readability of this specification the
> COSE_KDF_Context structure is repeated in {{cddl-cose-kdf}}.
This seems to be a holdover text? One could move the RFC 9053
reference to the previous paragraph.
> ## Single Recipient / One Layer Example {#one-layer-example}
Maybe specify the example private key used, so it is possible to test
decrypting it.
> It uses the following algorithm combination:
> - KEM: DHKEM(P-256, HKDF-SHA256)
> - KDF: HKDF-SHA256
> - AEAD: AES-128-GCM
This list has messed up formatting in -05.
> // payload: "This is the content", aad: ""
Might also specify info: "" or omit aad (as it is default).
> ## Multiple Recipients / Two Layer {#two-layer-example}
Ditto about example private keys and specifying info or omitting
aad.
And perhaps one of the recipients could be using P-256 and the
other X25519.
> To offer authentication of the sender the payload in
> {{hpke-example-two}} is signed with a COSE_Sign1 wrapper, which is
> shown in {{hpke-example-sign}}. The payload in {{hpke-example-sign}}
> corresponds to the content shown in {{hpke-example-two}}.
The payload given looks odd. The payload given would AFAICT start with
D860 (tag 96), and end with 7E4D (the last two bytes of last encrypted
CEK). The signature can be made to be as shown by picking suitable key.
-Ilari
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
