Re: [jose] Pete Resnick's Abstain on draft-ietf-jose-json-web-key-33: (with COMMENT)

[Mike Jones <[e-mail]>]

The proposed resolutions have been incorporated in the -33 draft.  I hope that on that basis, you can change your ballot position from Abstain to No Objection.

I did delete the "silly" sentence from Section 5.1, after all.

				Thanks again,
				-- Mike

> -----Original Message-----
> From: Mike Jones [mailto:[e-mail]]
> Sent: Monday, October 06, 2014 12:54 AM
> To: Pete Resnick; The IESG
> Cc: [e-mail]; [e-mail];
> [e-mail]
> Subject: RE: Pete Resnick's Abstain on draft-ietf-jose-json-web-key-33: (with
> COMMENT)
> 
> Thanks for your review, Pete.  I've added the working group to the thread so
> they're aware of your comments.
> 
> > -----Original Message-----
> > From: Pete Resnick [mailto:[e-mail]]
> > Sent: Wednesday, October 01, 2014 9:54 PM
> > To: The IESG
> > Cc: [e-mail];
> > [e-mail]
> > Subject: Pete Resnick's Abstain on draft-ietf-jose-json-web-key-33:
> > (with
> > COMMENT)
> >
> > Pete Resnick has entered the following ballot position for
> > draft-ietf-jose-json-web-key-33: Abstain
> >
> > 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-key/
> >
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Given my concerns with the other documents in this series, I'm not yet
> > willing to ballot No Objection on this document. So I will Abstain, at least for
> the moment.
> > We'll see how the rest of the discussion goes.
> >
> > Comments directly on this document:
> >
> > 4/5:
> >
> >    The member names within a JWK MUST be unique; recipients MUST either
> >    reject JWKs with duplicate member names or use a JSON parser that
> >    returns only the lexically last duplicate member name, as specified
> >    in Section 15.12 (The JSON Object) of ECMAScript 5.1 [ECMAScript].
> >
> > That first MUST is bogus. You are allowing them not to be unique in
> > the rest of the sentence. And it's not clear what you mean by "recipients"
> > here. Sounds like you mean "parsers" or "interpreters". If it were me,
> > I'd stick to the "MUST be unique" and be done with it, but either way
> > this paragraph needs fixing.
> 
> The first MUST is a requirement on producers; the second is a requirement on
> consumers.  I propose to reword this text to make this more explicit.
> 
> This language has been extensively discussed in the working group and again as
> a result of Stephen Kent's secdir review.  For instance, see the thread "JWK
> member names, was: [jose] SECDIR review of draft-ietf-jose-json-web-key-31"
> in the JOSE mailing list archives, beginning on 9/12/14.  There was a whole JSON
> working group that created a new standards-track JSON spec (RFC 7159) that
> that decided *not* to prohibit parsers from accepting inputs with duplicate
> names.  JOSE doesn't have sufficient influence to change the JSON parsers that
> are actually deployed and available to developers.  As Richard Barnes pointed
> out during the telechat, the point of JOSE is to enable crypto with tools that
> people actually have and use.  If we rule out the use of existing parsers, we will
> have failed to meet that basic goal.
> 
> > 4.1: The second paragraph is redundant given the first paragraph; I'd delete it.
> 
> Actually, it's not.  The second paragraph says where the initial values are defined
> (Section 6.1 of JWA).
> 
> > And why do you need "use" at all given that you've got "key_ops"?
> 
> They are for different use cases.  Use is for public-key-only use cases and mirrors
> what other specs do in this regard.  key_ops was later added for WebCrypto,
> and is for use cases where any of public, private, or symmetric keys may be
> present.  The "use" member predates "key_ops" by several years and was
> already in widespread use before we added key_ops late in the game.  We
> talked about removing "use" but the working group was very much in favor of
> retaining it.
> 
> > 4.5:
> >
> >    The structure of the "kid" value is
> >    unspecified.
> >
> > You should at least mention that this is a string. "The 'kid' value is
> > a text string, but it's structure is otherwise unspecified." Or something like
> that.
> 
> It actually already does say "The "kid" value is a case-sensitive string".
> 
> > 4.6 (and 4.7-4.9):
> >
> >    If other members
> >    are present, the contents of those members MUST be semantically
> >    consistent with the related fields in the first certificate.
> >
> > This is a pretty silly use of MUST. If the answer to the question,
> > "Why might someone do otherwise?" is "Because they're an idiot", you
> > probably don't need the MUST.
> 
> Jim Schaad and others were in favor of adding this language when the "x5u",
> etc. parameters were added ... so that idiots aren't free to be idiots. :-)
> 
> > 5:
> >
> >    Implementations SHOULD ignore JWKs within a JWK Set that use "kty"
> >    (key type) values that are not understood by them, are missing
> >    required members, or for which values are out of the supported
> >    ranges.
> >
> > I don't understand that SHOULD. This is completely dependent on what
> > the implementation is doing. Unknown key types might be ignorable, but
> > they might be vitally important. Why is this not a MAY?
> 
> This language also came from Jim Schaad.  The point is that when RSA and
> Elliptic Curve keys are eventually replaced by new key types, implementations
> should be prepared to have new key types appear in the set of advertised keys
> without breaking because they don't yet understand them.
> 
> > 5.1: Strike the last sentence. It's silly.
> 
> It describes a requirement of the JWK Set data format this is not otherwise
> described.
> 
> > 7: The first two sentences of the first paragraph and the first
> > sentence of the second paragraph should be moved under Security
> > Considerations; that's what this is. I'd delete the rest, as the
> > encryption of any JSON object is handled by JWE.
> 
> The sentences you would like to move are introductory material motivating the
> descriptions of encrypted JWKs and JWK Sets and the recommendations to use
> them under these circumstances.
> 
> > You might mention the content type somewhere, but the way it is in the
> > document now is way overdone, with the whole "MUST...unless construction.
> > Simply make it:
> >
> >    The content type of "jwk+json" can be used for "cty" header of the JWE.
> >
> > if you must have something.
> 
> This specific language, using the "must ... unless" construction was a result of a
> specific working group discussion on this topic, so I'm reluctant to tinker with it.
> For instance, your "can" language loses the "must ... unless" sense that some
> working group members insisted upon.
> 
> 				Thanks again,
> 				-- Mike