Yes, you can make it fail if you're using library not supporting the extension
by using "crit". The spec already says that and the new paragraph goes into it
further. But using library not supporting functionality needed by the
application seems like a pretty poor choice - all-up. This is something that
would be caught during debugging - well before production deployment.
If the application needs support for "b64":false to work correctly and doesn't
have it, the application will be broken and is incorrect, no matter what, just
like it would if it didn't have an implementation of RFC 7515 at all. Yes,
particular applications can send "crit":["b64"] if they want to guarantee a
particular kind of failure if the recipient is incorrectly implemented but has
a working implementation of RFC 7515, but that seems like a real corner case -
nonetheless, one that is already covered in the specification, should
applications want to achieve that.
I'm not aware of any cases that aren't already covered - especially once the
new paragraph is added.
-- Mike
-----Original Message-----
From: Jim Schaad [mailto:ietf(_at_)augustcellars(_dot_)com]
Sent: Saturday, December 12, 2015 9:08 PM
To: Mike Jones <Michael(_dot_)Jones(_at_)microsoft(_dot_)com>; 'Robert Sparks'
<rjsparks(_at_)nostrum(_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: [jose] Gen-Art LC review:
draft-ietf-jose-jws-signing-input-options-06
Mike,
I think that the text is somewhat tone deaf to the issue that Robert raises,
and which I have said many times.
The question is not how to I make sure it will work, but how do I make sure
that it will fail when it is not supposed to work. Use of 'crit' does that
quite well. It is not clear that your favored method 1 would do this.
Jim
-----Original Message-----
From: jose [mailto:jose-bounces(_at_)ietf(_dot_)org] On Behalf Of Mike Jones
Sent: Saturday, December 12, 2015 6:33 PM
To: Robert Sparks <rjsparks(_at_)nostrum(_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: [jose] Gen-Art LC review:
draft-ietf-jose-jws-signing-input-options-
06
Hi Robert. Thanks for the useful review. Replies are inline below...
-----Original Message-----
From: Robert Sparks [mailto:rjsparks(_at_)nostrum(_dot_)com]
Sent: Friday, December 4, 2015 11:08 AM
To: 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: Gen-Art LC review:
draft-ietf-jose-jws-signing-input-options-06
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
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
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.
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. 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
_______________________________________________
jose mailing list
jose(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/jose