Re: [jose] Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06

["Manger, James" <[e-mail]>]

Mike,

draft-ietf-jose-jws-signing-input-options-08 says:

   if used in environments in which all participants implement this extension, then "crit" need not be included

The clash here is whether such "environments" are reality, and if they are the audience of this IETF spec.
This sentence implies environment-specific JWS code, which rather goes against the point of a generic spec.

--
James Manger

-----Original Message-----
From: Mike Jones [mailto:[e-mail]] 
Sent: Thursday, 17 December 2015 2:52 PM
To: Manger, James <[e-mail]>; Robert Sparks <[e-mail]>; General Area Review Team <[e-mail]>; [e-mail]; Ben Campbell <[e-mail]>; Benoit Claise <[e-mail]>
Subject: RE: [jose] Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06

James, as I see it, your proposal optimizes the Header Parameter requirements for the case in which the JWS isn't useful, rather than case in which it is.  This seems backwards, from an engineering point of view.

The new "crit" language in -08 already ensures clean failure in all the cases in which failure should occur.  There's then no need to include an extra parameter intended to cause a failure in cases in which the failure cannot occur.

				-- Mike

-----Original Message-----
From: Manger, James [mailto:[e-mail]] 
Sent: Thursday, December 17, 2015 3:08 AM
To: Mike Jones <[e-mail]>; Robert Sparks <[e-mail]>; General Area Review Team <[e-mail]>; [e-mail]; Ben Campbell <[e-mail]>; Benoit Claise <[e-mail]>
Subject: RE: [jose] Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06

Mike proposes the following:

   "Using "crit" with "b64"

   If a JWS using "b64" with a value of "false" might be processed by implementations not implementing this extension, then the "crit" Header Parameter MUST be included with "b64" in its set of values to cause such implementations to reject the JWS.  Conversely, if used in environments in which all participants implement this extension, then "crit" need not be included, since its inclusion would have no effect, other than increasing the JWS size and processing costs."


"crit":"xxx" is not needed once everyone understands xxx, for any value of xxx. This is the nature of "crit". draft-ietf-jose-jws-signing-input-options is precisely the case where "crit" should be used (new messages that can be misunderstood by old implementations). If it isn't used here, I doubt it will ever get used.

The fact Mike is pushing back so much on using "crit" despite being an author of the JWS spec defining "crit" is a sign that "crit" itself is a poor design for supporting extensibility. There were alternative versioning mechanisms discussed before JWS was published, but "crit" was picked.

Alternative suggested wording:

   The "crit" Header Parameter MUST be included with "b64" in its set of values to ensure the JWS is rejected (instead of being misinterpreted) by implementations that do not understand this specification.

If people need hope that the 13-char overhead ("crit":"b64",) will not last forever, perhaps add the following:

   A future specification might be able to relax this requirement if there is another mechanism to prevent misinterpretation, such as another "crit" value that also implies "b64" understanding, or the elimination of all old implementations.


Please don't add:

   "Implementations receiving JWSs using "b64" with a value of "false" will not be able to successful use those JWSs unless they support this extension, since they will be unable to obtain the payload value.  ... including "crit" is insufficient to enable the receiving implementation to use the JWS; that requires supporting this extension."

The last part is too obvious. The first part is either too obvious (if "successful" means from the senders point of view) or wrong (as the recipient thinks they have been successful when they have actually misinterpreted the message).

Please remove method 3: sending a payload with non-base64url chars. This makes too many assumptions about how a base64url-decoder will handle unexpected chars. Some will reject anything outside A-Za-z0-9-_, others will ignore whitespace, others will happily decode +/ and -_, others will ignore =, perhaps others ignore any unexpected chars.

--
James Manger