Last Call Review of draft-ietf-jose-jws-signing-input-options-06

Request Review of draft-ietf-jose-jws-signing-input-options
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2015-12-09
Requested 2015-11-25
Authors Michael Jones
Draft last updated 2015-12-04
Completed reviews Genart Last Call review of -06 by Robert Sparks (diff)
Genart Last Call review of -06 by Robert Sparks (diff)
Secdir Last Call review of -06 by Benjamin Kaduk (diff)
Opsdir Last Call review of -06 by Stefan Winter (diff)
Assignment Reviewer Robert Sparks 
State Completed
Review review-ietf-jose-jws-signing-input-options-06-genart-lc-sparks-2015-12-04
Reviewed rev. 06 (document currently at 09)
Review result Almost Ready
Review completed: 2015-12-04


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


Document: draft-ietf-jose-jws-signing-input-options-06
Reviewer: Robert Sparks
Review Date: 4Dec2015
IETF LC End Date: 9Dec2015
IESG Telechat date: 17Dec2015

Summary: Almost ready for publication as Proposed Standard, but with a 

minor issue that should be addressed before publication.

Minor issues:

This document explicitly provides a way for interoperability to fail, 

but does not motivate _why_ leaving this failure mode in the protocol is 

a good tradeoff.

Specifically, as the security considerations section points out, it is 

possible for an existing implementation to receive a JWS that has 

b64=false, which it will ignore as an unknown parameter, and (however 

unlikely) successfully decode the payload, and hence believe it has a 

valid JWS that is not what was sent.

The idea that this failure can be avoided by making sure the endpoints 

all play nice through some unspecified agreement is dangerous. 

Specifically, I don't think you can rule out the case that the JWS 

escapes the controlled set of actors you are positing in option 1 from 

the list in the security considerations..

I would have been much more comfortable with a consensus to require 

'crit'. (Count me in the rough if this proceeds with crit being optional).

I assume there is a strong reason to allow for option 1. Please add the 

motivation for it to the draft, and consider adding a SHOULD use 'crit' 

requirement if option 1 remains.

Nits/editorial comments:

In the security considerations, the last sentence of the first paragraph 

needs to be simplified. I suggest replacing it with:

"It then becomes the responsibility of the application to ensure that 

payloads only contain characters that will not cause parsing problems 

for the serialization used, as described in Section 5. The application 

also incurs the responsibility to ensure that the payload will not be 

modified during retransmission.