I support publication. I like the examples which make the implementation of the products much smoother and better interoperability.
I have two comments which might be discussed in the past and already resolved, but writing here anyway. There are very simple descriptions of how COSE-HPKE will evolve in the future once post-quantum cryptographic algorithms have been standardized. When I see the examples on Fig. 3 and Fig. 5, I prefer having a very short brief explanation of the benefits of COSE-HPKE in the section of Abstract or Introduction that it is easy to adopt PQC without changing the overall protocol structure. If having the word PQC in this draft will cause noise and make the delays for becoming a RFC then current description is fine. The HPKE is designed to be able to plug in different KEMs, including post-quantum algorithms. By supporting hybrid encryption, combining classical (e.g., X25519) and post-quantum KEMs (e.g., Kyber), it may provide a bridge during the transition of supporting classical and quantum algorithms. Another comment is minor, in the section 3.1.2.1, having the explanation of background on “but is specifically for a COSE_recipient, never a COSE_Encrypt.” which might make it easier to understand for the implementers. This is a question, would section 4.1. have an impact on recent ESP256, Ed25519 clarification on this draft? https://www.ietf.org/archive/id/draft-ietf-jose-fully-specified-algorithms-12.html Akira On Tue, Jun 17, 2025 at 8:09 PM Laurence Lundblade <[email protected]> wrote: > I’d feel a lot better about the “yes, let’s publish” if there was some > comment and confirmation that next_layer_alg in Recipient_structure > [3.1.2.1] secures the bulk encryption algorithm ID well enough that a > non-AEAD can be used. I think it does, but we should have a little > consensus on this. > > LL > > [3.1.2.1]: > https://www.ietf.org/archive/id/draft-ietf-cose-hpke-13.html#name-hpke-key-encryption-mode > > > On Jun 17, 2025, at 10:08 AM, Michael Prorock <mprorock= > [email protected]> wrote: > > I support publication > > (and thank Thomas for the editorial notes that will be helpful I believe, > whether they are addressed at a later editorial stage or now) > > On Tue, Jun 17, 2025 at 5:33 AM Thomas Fossati <[email protected]> > wrote: > >> On Wed, Jun 04, 2025 at 08:28:52PM +0100, Michael Jones wrote: >> > This note starts a two-week Working Group Last Call (WGLC) for the Use >> > of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and >> > Encryption (COSE) specification >> > https://www.ietf.org/archive/id/draft-ietf-cose-hpke-13.html. The >> > WGLC will run for two weeks, ending on Friday, June 20, 2025. >> > >> > Please review and send any comments or feedback to the COSE working >> > group at [email protected]<mailto:[email protected]>. Even if your feedback >> > is "this is ready for publication", please let us know. >> >> I hadn't read this draft before. At first glance, the mechanics look >> fine, but I may be missing some important details. >> >> Here are a few editorial comments from a quick scan of the document. >> >> ---- >> s/this documents/this document/ >> s/public key the sender/public key that the sender/ >> s/recipient protected/recipient-protected/ >> s/the whole COSE encrypt/the whole COSE_Encrypt0/ (or COSE_Encrypt???) >> s/public key the sender/public key that the sender/ >> >> I was unable to parse: "It also mitigates attacks where a >> person-in-the-middle changes the following layer algorithm from an AEAD >> algorithm to one that is not foiling the protection of the following >> layer headers)". Could this be simplified? >> >> Grammar: >> >> OLD >> When encrypting the content at layer 0 then the instructions in Section >> 5.3 of [RFC9052] MUST to be followed, which includes the calculation of >> the authenticated data strcture. >> NEW >> When encrypting the content at layer 0, the instructions in Section 5.3 >> of [RFC9052] MUST be followed, including the calculation of the >> authenticated data structure. >> >> Straighten a backwards sentence: >> >> OLD >> For the algorithms defined in this document, the valid combinations of >> the KEM, "kty" and "crv" are shown in Figure 1. >> NEW >> The valid combinations of KEM, "kty" and "crv" for the algorithms >> defined in this document are shown in Figure 1. >> >> s/to some extend/to some extent/ >> s/maintain the tradeoff between/strike a balance between/ >> s/consitute/constitute/ >> s/examples that shows/examples that show/ >> >> some mildly invalid EDN: >> * Figure 2: extra commas >> * Figure 3: extra commas >> >> s/COSE_MAC/COSE_Mac/ >> s/COSE_MAC0/COSE_Mac0/ >> s/random number generations/random number generation/ >> >> De-clunkify paragraph: >> >> OLD >> HPKE assumes the sender is in possession of the public key of the >> recipient and HPKE COSE makes the same assumptions. Hence, some form of >> public key distribution mechanism is assumed to exist but outside the >> scope of this document. >> NEW >> Both HPKE and HPKE COSE assume that the sender possesses the recipient's >> public key. Therefore, some form of public key distribution mechanism is >> assumed to exist, but this is outside the scope of this document. >> >> The IANA registration requests appear as an inextricable cluster . >> I suggest adding an NL to separate the blocks logically. >> ----- >> >> cheers, t >> >> > Note that this WGLC is intentionally running concurrently with a JOSE >> > WGLC for >> > https://www.ietf.org/archive/id/draft-ietf-jose-hpke-encrypt-08.html >> > because the drafts are closely related and their functionality is >> > intended to be aligned. Please reply to the JOSE WGLC on the >> > [email protected]<mailto:[email protected]> mailing list. >> > >> > Thank >> you, >> > -- Mike and Ivaylo, COSE >> Chairs >> > >> >> _______________________________________________ >> COSE mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > _______________________________________________ > COSE mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > > _______________________________________________ > COSE mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
