Re: [jose] Pete Resnick's Discuss on draft-ietf-jose-json-web-encryption-33: (with DISCUSS and COMMENT)

["Jim Schaad" <[e-mail]>]

> -----Original Message-----
> From: jose [mailto:[e-mail]] On Behalf Of Mike Jones
> Sent: Monday, October 06, 2014 12:54 AM
> To: Pete Resnick; The IESG
> Cc: [e-mail]; jose-
> [e-mail]; [e-mail]
> Subject: Re: [jose] Pete Resnick's Discuss on
draft-ietf-jose-json-web-encryption-
> 33: (with DISCUSS and COMMENT)
> 
> Thanks for your review, Pete.  I've added the working group so they're
aware of
> your comments.
> 
> > -----Original Message-----
> > From: Pete Resnick [mailto:[e-mail]]
> > Sent: Thursday, October 02, 2014 7:24 AM
> > To: The IESG
> > Cc: [e-mail]; draft-ietf-jose-json-web-
> > [e-mail]
> > Subject: Pete Resnick's Discuss on
> > draft-ietf-jose-json-web-encryption-33: (with DISCUSS and COMMENT)
> >
> > Pete Resnick 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/
> >
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > There are a bunch of comments here that also apply to JWS. It's a real
> > shame you did not factor out what's common between these documents and
> > not repeat everything in a slightly different way. I'm sure that there
> > will be a change in one document that won't get changed in the other.
> > Such is life.
> 
> Where text was previously actually the same, we editorially left in in JWS
and
> referenced it from JWE some time ago.  If there are examples remaining of
> duplicated text that you believe should be removed from JWE, please let us
> know what they are.
> 
> > 1: Lose the last paragraph. It's not a core goal. Certainly not in the
charter.
> 
> Producing a compact URL-safe serialization has always been a core goal.
I'm
> writing this in an airplane without network access (yes, such places still
exist :-)
> ) and don't have the actual charter text in front me but I know that Karen
> O'Donoghue sent proposed charter text to the IESG a while back that
included
> the language "using a compact URL-safe representation" because I have a
local
> copy of the e-mail.

Current text is just " The second will be a smaller serialization that can
be
used in URLs."  It is not clear that the paragraph adds value.  I am
indifferent as to it staying or going.

> > 4.1.2: So I want to understand the "MUST reject" as used here. What
> > happens if the implementation doesn't reject? Is the decrypt simply
> > going to fail (in which case the MUST reject is not helpful), or is
there some
> attack vector here?
> 
> This was discussed on the telechat and several people were in favor
leaving this
> language as-is, citing precedents from other RFCs.  I believe you said
that you
> would identify any particular uses that you thought would be problematic.

It would be more accurate to say that the decryption would never be able to
start than it would fail.  This is one of those cases of - I don't support
this - should I not "reject" it?

> > 5.2: If these things are steps, start with the verb. See 2 below as an
> > example, but look at the other steps as well.
> 
> Fair enough.  I agree that these should either start with a verb or a
condition,
> followed by a verb.  I'll plan to revise accordingly.
> 
> >    1 - Say what to parse out and refer to section 7. Again, don't
> > privilege compact.
> 
> Same answer as for the parallel comment on the JWS spec.
> 
> >    4 could be significantly shortened if you didn't separate the
> > serializations. Just make it the union. If some of the members are
> > absent (for whatever reason), that's fine.
> 
> I disagree with combining them, as the explanation would be far less clear
to
> developers.
> 
> >    9-12 seem like they could be combined/refactored in some useful way.
> 
> Same answer as to your comment on 5.1.
> 
> >    (I'll also note here that the "recipient" construct is still weird
> > to me. It's just a "key owner" or something like that, right?)
> 
> This was the terminology that was chosen by the working group.  I'm
offline at
> the moment so can't check immediately, but I believe that it was also
> terminology used by CMS.  I *know* that it was terminology used by ekr and
> Joe Hildebrand in their submission to the working group, parts of which
> (including language in the steps) are part of this specification.
> 
> > 9: It took me a bit to figure out why this section is here. This is
> > only a problem for the Compact Serialization. The second bullet makes
> > this
> > clear: For the JSON Serialization, the answer is, "They're different
> > if they're different." I suggest rewriting this section to make it
> > clear that you're trying to help folks who need to distinguish between
> compact serializations.
> 
> It's also needed for the JSON Serializations, hence bullet 2.  Bullets 3
and 4 also
> apply to both serializations.  Only bullet 1 is specific to the compact
> serializations.

Presumably it could be simplified as bullet one only refers to compact
serialization.  And the other bullets only refer to JSON serialization.  The
parsing on period characters should be determinate for compact
serialization.  

Perhaps if it was divided this way it would be clearer.

> 
> > Appendix A: Leaving the JSON Serialization until the end and putting a
> > compact serialization in every example stinks. Let's not make it
> > harder for implementers to figure out how to use the JSON Serialization.
> 
> Other than the last example, the examples are there to describe properties
of
> algorithms, not of serializations, so both serializations aren't needed to
> illustrate those points.  The simpler compact serialization does just fine
for that
> purpose.  That being said, draft-ietf-jose-cookbook is chock full of
examples of
> both serializations.  It should be coming to the IESG pretty soon as well.
> 
> 				Thanks again,
> 				-- Mike
> 
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose