Mike -
No, this still doesn't explain why crit is not sufficient.
You are making a bare assertion that using crit doesn't achieve a). I
think it does. Please explain (in the draft) why it doesn't.
You are making me guess, but I think you are only trying to avoid having
to include the few extra bits in the message. If you've _done_ the work
of ensuring all the applications understand using b64 through some
out-of-band magic, then including crit will just work. Are you pushing
back on anything _but_ the packet-bloat in this case?
If you _haven't_ done this out-of-band work, and you send to a receiver
that understands the extension, then a) is achieved. If you send to a
receiver that doesn't understand, things _should_ fail - arguably this
also achieving a), though I suspect you are wincing at perhaps not
having a clear path to recovery in this case?
I really think this boils down to you not wanting to pay the extra few
bits in the packet to say "crit".
if that's not the case, please explain (and again, this needs to be in
the draft, not just an email thread).
RjS
On 12/13/15 10:04 PM, Mike Jones wrote:
Hi Robert,
You asked "_WHY_ is crit not sufficient? I think that's the thing that's missing as
motivation."
There are two goals we're discussing, which are related:
(a) Having an application that uses "b64":false work.
(b) Having an application that receives a JWT with "b64":false not misinterpret
the payload content.
Including "crit":["b64"] would be sufficient to achieve (b), as it would cause the JWS to
be rejected by implementations not supporting "b64". But it does not achieve (a), since the JWS
would be rejected.
In contrast, using an implementation that understands "b64" achieves both (a) and (b)
without needing to include "crit". That's why it's not required.
Does that make sense now?
Best wishes,
-- Mike
-----Original Message-----
From: Robert Sparks [mailto:rjsparks(_at_)nostrum(_dot_)com]
Sent: Sunday, December 13, 2015 1:11 PM
To: Mike Jones <Michael(_dot_)Jones(_at_)microsoft(_dot_)com>; General Area Review
Team <gen-art(_at_)ietf(_dot_)org>; ietf(_at_)ietf(_dot_)org;
jose(_at_)ietf(_dot_)org; draft-ietf-jose-jws-signing-input-options(_at_)ietf(_dot_)org
Subject: Re: Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06
Cutting away a bit to focus on the question:
On 12/12/15 8:32 PM, Mike Jones wrote:
Hi Robert. Thanks for the useful review. Replies are inline below...
-----Original Message-----
<snip/>
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.
It's a reasonable request to have the draft say why "crit" isn't required. My
working draft adds the following new paragraph at the end of the security considerations
section to do this. Unless I hear objections, I'll plan on publishing an updated draft
with the paragraph shortly.
"Note that methods 2 and 3 are sufficient to cause JWSs using this extension to
be rejected by implementations not supporting this extension but they are not
sufficient to enable JWSs using this extension to be successfully used by
applications.
The conclusion you draw here is not at all obvious.
_WHY_ is crit not sufficient? I think that's the thing that's missing as
motivation.
Thus, method 1 - requiring support for this extension - is the preferred approach and the only means
for this extension to be practically useful to applications. Method 2 - requiring the use of <spanx
style="verb">crit</spanx> - while theoretically useful to ensure that confusion between
encoded and unencoded payloads cannot occur, is not particularly useful in practice, since method 1 is
still required for the extension to be usable. When method 1 is employed, method 2 doesn't add any value
and since it increases the size of the JWS, its use is not required by this specification."
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.
I have simplified this in the manner that you suggested.
Thanks again,
-- Mike