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]
