JSON Web Signature (JWS) Unencoded Payload Option
draft-ietf-jose-jws-signing-input-options-09
Yes
(Kathleen Moriarty)
No Objection
(Alia Atlas)
(Alvaro Retana)
(Barry Leiba)
(Brian Haberman)
(Deborah Brungard)
(Martin Stiemerling)
(Spencer Dawkins)
(Terry Manderson)
Note: This ballot was opened for revision 06 and is now closed.
Kathleen Moriarty Former IESG member
Yes
Yes
(for -06)
Unknown
Stephen Farrell Former IESG member
(was Discuss)
Yes
Yes
(2015-12-22 for -08)
Unknown
Thanks for the discussion of "crit" which I think has resolved so I'm clearing now. I didn't check the comments below. No need to respond about them unless you really want to. - abstract: the description of the update to 7519 is odd. It seems to be saying "Here we define a thing. This specification updates 7519 to say you must not use this thing." but prohibiting is an odd verb to use there. (Since it wasn't previously there to be allowed or not.) - section 6: "It is intended that application profiles specify up front whether" "intended" is very wishy washy and "up front" makes no sense at all.
Alia Atlas Former IESG member
No Objection
No Objection
(for -07)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -08)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(for -07)
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
(2015-12-16 for -07)
Unknown
-7, last paragraph: " 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." One might wonder why method 2 and 3 are included. I assume it is to allow existing apps to migrate to method 1 over time? If so, some guidance on app migration might be useful. Editorial: -6, last paragraph: It’s confusing to see "(JWT) [JWT]" . I suggest either removing (JWT), or changing the anchor for the citation to use [RFC7519]
Benoît Claise Former IESG member
No Objection
No Objection
(2015-12-16 for -07)
Unknown
As mentioned by Stefan in his OPS DIR review: There are coexistence issues between implementations which understand the notion of the "b64" parameter (i.e. implementing this RFC) and those who do not (i.e. all existing JWS implementations). The issues are discussed in Security Considerations (second para up until the end). The issues with it are: * the conclusions are not as satisfactory as they could be. Interoperability is either - left as an out-of-band and undescribed mechanism ("make sure that only supporting implementations talk to each other") - by explicitly marking support for b64 as critical (IMO the only good solution) - modifying the payload so that it contains unparseable characters (which may or may not be possible for the sender depending on the payload characteristics) * this is placed in Security Considerations while it has actual operational impact on every transmitted message: in essence it states: "Sometimes, sender and recipient may misunderstand each other without noticing". Example given in the draft where the actual message is "NDA1" while the recipient thinks it was told "405", without a way to notice. Even if the misunderstanding is not related to security, it can/will have significant implications for the application. I believe this can not be left as-is. Luckily, there seems to be an easy way out: "Whenever the 'b64' header exists and is set to false, the 'crit' header MUST also be present and contain 'b64'." This, maybe in conjunction with "When the content is intended to be base64 encoded, the 'b64' header SHOULD NOT be present." This would make sure that implementations who know nothing of b64 are left alone (there is no unknown extension, there is no criticality in any such extension, and the sender did not intend to make use of the feature => all good). While at the same time for unencoded payloads making deterministically clear that unencoded transmission is happening, and is required to be understood. This would at the same time make a complex piece of Sec Con go away.
Brian Haberman Former IESG member
No Objection
No Objection
(for -08)
Unknown
Deborah Brungard Former IESG member
No Objection
No Objection
(for -07)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2015-12-17 for -08)
Unknown
I am a no-objection on this, but I do agree with Stephen's Discuss position, raised in the Gen-ART review by Robert.
Joel Jaeggli Former IESG member
No Objection
No Objection
(2015-12-16 for -08)
Unknown
stefan winter performed the opsdir review
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -07)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -08)
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(for -07)
Unknown