Re: [jose] Pete Resnick's Abstain on draft-ietf-jose-json-web-key-33: (with 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];
[e-mail];
> [e-mail]
> Subject: Re: [jose] 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.

The other side of this is that we are assuming that existing parsers are
going to work the same way as JavaScript.  It is not clear that this is
always the case so there may be problems for some existing parsers no matter
what we say.

> 
> > 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).
> 

Given that we are pointing to the registry for the list of values, is there
really any need to say where the registry was initially filled from?  I can
see Pete's point on this.  I am agnostic about keeping or removing this.

> > 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.

The parameter "key_ops" was added in response to a request from the
WebCrypto group.  It is more fined grained control.  The JWT community did
not want to lose the "use" parameter that they already had.  Not clear to me
what the correct response is, but as Mike says the WG did discuss this and
argued for keeping it.

> > 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.
:-)

The reason that this might be done is if you are attacking - or you aren't
paying attention with what you are doing. 

> 
> > 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.

The only thing one can do with an unknown key type is to ignore it.  You
won't be able to use it to perform a signature verification or encryption
operation so selecting it to try and do something with does not make sense.
I would tend to argue that it should have been a MUST myself.

> 
> > 5.1: Strike the last sentence. It's silly.
> 
> It describes a requirement of the JWK Set data format this is not
otherwise
> described.

It duplicates text already in section 5.  I don't think it necessarily needs
to be there.

> 
> > 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.

Yeah I was never happy with MUST...unless because I was never sure what this
really meant.  I don't know that the group is going to be able to advance
beyond this language without a huge force pushing on it.

> 
> 				Thanks again,
> 				-- Mike
> 
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose