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:[email protected]]
> Sent: Monday, October 06, 2014 12:54 AM
> To: Pete Resnick; The IESG
> Cc: [email protected]; [email protected];
> [email protected]
> 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:[email protected]]
> > Sent: Wednesday, October 01, 2014 9:54 PM
> > To: The IESG
> > Cc: [email protected];
> > [email protected]
> > 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
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
