The -34 draft incorporates the proposed resolutions below. I hope that you can
clear your DISCUSS on that basis.
Section 3.3 now does include a reference to an example using the JSON
Serialization.
Thank you,
-- Mike
> -----Original Message-----
> From: Mike Jones [mailto:[email protected]]
> Sent: Saturday, October 11, 2014 3:19 PM
> To: Richard Barnes; The IESG
> Cc: [email protected]; jose-
> [email protected]; [email protected]
> Subject: RE: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-
> encryption-33: (with DISCUSS and COMMENT)
>
> Thanks for your review, Richard. Responses are inline below...
>
> > -----Original Message-----
> > From: jose [mailto:[email protected]] On Behalf Of Richard Barnes
> > Sent: Wednesday, October 01, 2014 8:37 PM
> > To: The IESG
> > Cc: [email protected]; jose-
> > [email protected]; [email protected]
> > Subject: [jose] Richard Barnes' Discuss on
> > draft-ietf-jose-json-web-encryption-
> > 33: (with DISCUSS and COMMENT)
> >
> > Richard Barnes has entered the following ballot position for
> > draft-ietf-jose-json-web-encryption-33: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut
> > this introductory paragraph, however.)
> >
> >
> > Please refer to
> > http://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > Overall, this document is in much more solid shape than when it began.
> > Thanks to the WG for a lot of hard work. I only have one remaining
> > concern, that should hopefully be easy to address.
> >
> > Section 7.2.
> > I've had several implementers trying to use JWE in the JSON
> > serialization ask why it was necessary to include a "recipients" array
> > in cases where there's only one recipient. It seems like this is
> > going to be a major barrier to deployment and re-use, so I would propose
> including the following text:
> > """
> > In cases where the JWE is encrypted for only one recipient, the
> > "recipients" array will contain a single object. In such cases, the
> > elements of the "recipients" array MAY be included at the top level of
> > the JWE object. If the generator of a JWE chooses to use this
> > representation then all unprotected header parameters MUST be carried
> > in the "header" field, and the "unprotected" field MUST be absent. A
> > JSON-formatted JWE that contains a "recipients" field MUST NOT contain a
> "header" or "encrypted_key" field, and vice versa.
> > """
> > This may also require some other changes where "recipients" is relied
> > on, e.g., in Section 9.
>
> My response to this parallels that to the similar DISCUSS about JWS.
>
> That said, I actually have marginally *more* concerns about this proposal than
> the JWS one, because you're making an arbitrary choice between the multi-
> recipient "unprotected" parameter and the per-recipient "header" parameter,
> and dictating that one be used in preference to another in the proposed case
> where "recipients" array is not present. This adds an additional level of
> non-
> parallelism that isn't present in the JWS case.
>
> For those following along, here are the two mostly equivalent syntaxes that
> implementations would have to support in Richard's proposal:
>
> {"protected":"<integrity-protected shared header contents>",
> "unprotected":<non-integrity-protected shared header contents>,
> "recipients":[
> {"header":<per-recipient unprotected header 1 contents>,
> "encrypted_key":"<encrypted key 1 contents>"}],
> "aad":"<additional authenticated data contents>",
> "iv":"<initialization vector contents>",
> "ciphertext":"<ciphertext contents>",
> "tag":"<authentication tag contents>"
> }
>
> and
>
> {"protected":"<integrity-protected shared header contents>",
> "header":<per-recipient unprotected header 1 contents>,
> "encrypted_key":"<encrypted key 1 contents>",
> "aad":"<additional authenticated data contents>",
> "iv":"<initialization vector contents>",
> "ciphertext":"<ciphertext contents>",
> "tag":"<authentication tag contents>"
> }
>
> Plus, there would be a third syntax if use of the "unprotected" parameter were
> not arbitrarily ruled out, as his proposal does:
>
> {"protected":"<integrity-protected shared header contents>",
> "unprotected":<non-integrity-protected shared header contents>,
> "header":<per-recipient unprotected header 1 contents>,
> "encrypted_key":"<encrypted key 1 contents>",
> "aad":"<additional authenticated data contents>",
> "iv":"<initialization vector contents>",
> "ciphertext":"<ciphertext contents>",
> "tag":"<authentication tag contents>"
> }
>
> During the Denver interim meeting in April 2013 and subsequent working group
> decisions we all agreed to a specific syntax for the JWE JSON Serialization.
> We
> explicitly agreed to have a "recipients" array, since this serialization
> enables
> multiple recipients. This syntax was incorporated in draft -11 in May 2013
> and
> has been stable since then. Given you were an inventor of this syntax,
> Richard,
> I'm surprised to see you questioning it now, this late in the process.
>
> I'll therefore ask you to withdraw this DISCUSS, since having multiple
> syntaxes to
> represent the same semantics can only hurt interoperability.
>
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Section 3.3.
> > Why doesn't this example include the JSON encoding?
>
> Same answer as to your parallel question on JWS.
>
> > Section 4.1.3.
> > "This Header Parameter MUST be integrity protected"
> > Why is this the case? There is no security reason that "zip" must be
> > integrity- protected, and this requirement isn't made for any other
> > parameter.
>
> ekr and others stated reasons for this when the compromise about allowing
> some non-integrity-protected parameters was reached. I believe that they
> boiled down to ensuring that an attacker couldn't vary the contents of the
> plaintext by changing the "zip" parameter value as part of an attack. Given
> the
> effectiveness of the CRIME attack against compression in SPDY since then, this
> advice seems all the more sound in retrospect.
>
> > Section 7.2.
> > The requirement that the "recipients" field MUST be present seems odd.
> > What's the justification for this?
>
> Simplicity. The structure of a JWE using the JSON Serialization is always the
> same that way, simplifying generators and parsers. If this weren't the case,
> they'd have to have a special case for the situation where the "recipients"
> array
> was omitted.
>
> > Appendix A seems kind of unnecessary given draft-ietf-jose-cookbook.
>
> Developers have found the examples to be useful in practice. Having more in
> the cookbook just adds value, without detracting from the value of the
> examples in the JWE spec.
>
> > _______________________________________________
> > jose mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/jose
>
> Thanks again,
> -- Mike
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
