Last Call Review of draft-ietf-anima-jws-voucher-12
review-ietf-anima-jws-voucher-12-artart-lc-fenton-2024-10-11-00

I am the designated artart reviewer for this draft.

Summary: Almost Ready

My biggest question about this draft is why it is separate from
ietf-anima-rfc3866bis. It appears to be an extension to rfc3866bis, yet 3866bis
is still being considered by the working group. 3866bis defines signature
mechanisms in Section 6, but there is only one subsection, describing the CMS
format voucher artifact. Why not just put the core of this in as Section 6.2?

The first part of Section 3 lists the different JWS serializations in RFC 7515.
But the first statement in Section 3.1 says, “JWS voucher artifacts MUST use
the ‘General JWS JSON Serialization Syntax’…”. Is the introductory information
in Section 3 necessary? It looks like it may be left over from before that MUST
requirement was placed.

In Section 3.3, “If present, the ‘typ’ parameter SHOULD contain the value
‘voucher-jws+json’”. Under what circumstances would the typ parameter be
present or absent? Under what circumstances would the typ parameter contain a
different value, especially since it seems like that would be
self-contradictory?

Likewise in Section 3.3, under what circumstances would the x5c parameter
contain something different, or should this be a MUST? Am I correct in assuming
that the x5c parameter is only present for X.509v3 certificates (perhaps it
should say that)?

Section 3.3 end of paragraph 2: “JWS Voucher parsers must be prepared” sounds
like a normative MUST.

Nits:

Some RFC callouts are by RFC number, others by an abbreviation like [BRSKI]. I
don’t know if it’s a requirement, but I prefer that this be consistent (I
prefer RFC number).

Abstract: artifact called voucher -> artifact (known as a voucher)

2. Terminology: Terms after Voucher Data are in a different style.

3.3 paragraph 3: base64-encoded values opposed to base64url-encoded values may
-> base64-encoded values, in contrast to base64url-encoded values, may

upfront -> up front

8.1 “in General JWS JSON Serialization” is not really needed since that’s the
only serialization allowed.