Skip to main content

IETF Last Call Review of draft-ietf-jose-hpke-encrypt-17
review-ietf-jose-hpke-encrypt-17-genart-lc-yee-2026-06-07-00

Request Review of draft-ietf-jose-hpke-encrypt
Requested revision No specific revision (document currently at 22)
Type IETF Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2026-05-27
Requested 2026-05-13
Authors Tirumaleswar Reddy.K , Hannes Tschofenig , Aritra Banerjee , Orie Steele , Michael B. Jones
I-D last updated 2026-07-10 (Latest revision 2026-07-06)
Completed reviews Artart IETF Last Call review of -17 by Paul Kyzivat (diff)
Genart IETF Last Call review of -17 by Peter E. Yee (diff)
Secdir IETF Last Call review of -18 by Watson Ladd (diff)
Assignment Reviewer Peter E. Yee
State Completed
Request IETF Last Call review on draft-ietf-jose-hpke-encrypt by General Area Review Team (Gen-ART) Assigned
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/PEM_JXKCCWRWgD-_2bLMGoIt6KE
Reviewed revision 17 (document currently at 22)
Result Ready w/nits
Completed 2026-06-07
review-ietf-jose-hpke-encrypt-17-genart-lc-yee-2026-06-07-00
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document: draft-ietf-jose-hpke-encrypt-17
Reviewer: Peter Yee
Review Date: 2026-06-07
IETF LC End Date: 2026-05-27
IESG Telechat date: Not scheduled for a telechat

Summary:

This draft is an adaptation of HPKE for use within JWE. It seems reasonably
clear and well structured. There's one minor issue I'm raising, but I'm going
to say that really the document is ready to go with some nits that could be
addressed, many of which are merely a matter of taste. While my review looks at
-17, I checked the diff and the changes found in -18 do not impact the content
of my review. Ready with nits.

Major issues: None

Minor issues:

Page 4, Key Management Mode definition: While the definition starts out as “A
method”, this isn’t really a method, despite RFC 7516 also defining the term
that way and this specification inheriting it. It’s a mode identifier that is
used as part of a method. I see it more as the value used in a switch statement
to select amongst the cases supported, with this draft adding Integrated
Encryption to the set of supported cases.

Nits/editorial comments:

Page 6, 4th bullet item: change “and” to “or”.

Page 9, section 6, 1st bullet item: change “a” to “an” unless “HPKE” really is
pronounced as a word. Hop-key?

Page 13, item 4: change “are” to “is”.

Page 13, item 12: append a comma after “algorithm”.

Page 15, section 7.2, item 1, 2nd sentence: consider changing the “and” after
“JWE AAD” to “along with”. The sentence is already too long a bound together
with many uses of “and” that have to be read carefully to determine which
adjectives apply to which nouns. You might also consider breaking the sentence
at the second “these components” for readability.

Page 16, item 7: append a comma after “Direct Encryption”.

Page 16, item 10, 1st sentence: change “are” to “is”.

Page 16, item 11: change “are” to “is”.

Page 19, section 10, 1st paragraph: append a comma after “HPKE”.

Page 19, section 10, 2nd paragraph, 1st sentence: change “assumptions” to
“assumption”.

Page 20, section 11.1.1, 2nd bullet item: append a comma after “KDF”.

Page 23, section 11.1.9, 2nd bullet item: append a comma after “KDF”.