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
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
