Ballot for draft-ietf-anima-jws-voucher
Discuss
Yes
No Objection
No Record
Summary: Has a DISCUSS. Needs one more YES or NO OBJECTION position to pass.
Thank you for the work on this document. I have looked for media type reviews in the media-types mailing list, and could not find the registration request posted. As specified by RFC6838, it is strongly encouraged to post the media type registration to the media-types mailing list for review (see https://mailarchive.ietf.org/arch/msg/media-types/1hOBaaTVCfl-M3uHmu2a7Q5Ogzk/ for an example of a registration review request). If I missed it, my apologies. If not, please post to the media-types mailing list, and I will remove the discuss with no objections raised after a week or so. Please make sure to copy-paste the full text from section 6.1.1 (not just a pointer to it) in your mail to media-types.
# Orie Steele, ART AD, comments for draft-ietf-anima-jws-voucher-14 CC @OR13 * line numbers: - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-anima-jws-voucher-14.txt&submitcheck=True * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Comments Thanks to Jim Fenton for the ART ART review, and to the authors for addressing his previous comments. I would like to see his remaining nits on -14 addressed as well. ### typ ending in +json ``` 217 * The typ parameter is optional and used when more than one kind of 218 object could be present in an application data structure as 219 described in Section 4.1.9 of [RFC7515]. If present, the typ 220 parameter MUST contain the value voucher-jws+json. ``` AFAIK, this is the first case of a proposed standard where typ is used to indicate a JWS JSON type, usually I see typ values ending in +jwt and only in compact serialization. Thanks for asking for a review here: https://mailarchive.ietf.org/arch/msg/media-types/JIZhf_uffyMyQZAAUsy0V9mQIrA/ ### What happens when the trust anchor is in the x5c? ``` 234 To validate voucher signatures, all certificates of the certificate 235 chain are required up to the trust anchor. Note, to establish trust 236 the trust anchor SHOULD be provided out-of-band up front. ``` Why not state the trust anchor MUST NOT be present in x5c? What happens when this SHOULD is ignored. ### privacy considerations of jws headers ``` 268 The use of a JWS header brings no new privacy considerations. ``` I'm not sure I agree with this framing. The header could contain additional parameters beyond alg, typ and x5c. The decoded x5c might include additional attributes that impact privacy. ## Nits ### Decoded JWS Protected Header ``` 238 The following figure gives an example of a JWS Protected Header: ``` The protected header that is secured is base64url encoded, so when displaying JSON, you are displaying a decoded + pretty printed protected header. It is also potentially worth noting that the JSON you are showing as lots of new lines and spaces, which I would not expect in a minimal protected header.
The Abstract and the first paragraph of the Introduction both 'bury the lead' by discussing other drafts first. I would rearrange these to list the current draft first, and then the other work drafts. I also agree w/ Eric's comment about the (kind of weird) Yang terminology. Especially since this draft has no Yang. Section 8.2: Parboiled? Really? Intermediate step would probably be clearer to many (especially if the readers aren't native English speakers).
# Gunter Van de Velde, RTG AD, comments for draft-ietf-anima-jws-voucher-13 # Many thanks for this document # line numbers are derived with the idnits tool https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-anima-jws-voucher-13.txt # I do not have significant crypto knowledge, hence my review is rather high level from generalist and readability perspective. I found the draft well written. #DETAILED COMMENTS #================= 123 Voucher: A short form for voucher artifact and refers to the signed 124 statement from Manufacturer Authorized Signing Authority (MASA) 125 service that indicates to a Pledge the cryptographic identity of 126 the domain it should trust, per [I-D.ietf-anima-rfc8366bis]. GV> I saw the term 'artifact' few times used before this section. Is this a term that is well known in the context of anima/security? Maybe suggest a definition or description what is intended. I did a search on the web and found the following short summary: "In the context of JWS, an artifact typically refers to the payload or data that is being signed and transmitted. This artifact is encoded as part of the JWS structure and, along with the signature, ensures the integrity and authenticity of the data."
Thank you for writing this document - even though I'm not an Anima / JWT person I still found the document easy to read. Also, much thanks to Yingzhen Qu and Eliot Lear for the OpsDir and IOTDir reviews.
Thanks for the work done in this document, may I also add that the text is easy to read and understand? Thanks also to Matthias Kovatsch for the exhaustive shepherd's write-up (noting that the WGLC did not generate any comment...). Thanks also to Eliot Lear, the IoT directorate reviewer, see https://datatracker.ietf.org/doc/review-ietf-anima-jws-voucher-12-iotdir-lc-lear-2024-09-16/ One minor quick comment though: is there any reason why the abstract uses YANG-defined and the introduction YANG-based (both terms are weird though and bring little value especially in the abstract) ?