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

"Jim Schaad" <> Mon, 06 October 2014 20:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9A1301A89A4; Mon, 6 Oct 2014 13:26:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cEEb3WG8YAcA; Mon, 6 Oct 2014 13:26:03 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3890A1A89A3; Mon, 6 Oct 2014 13:26:03 -0700 (PDT)
Received: from Philemon ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id BF32738F3C; Mon, 6 Oct 2014 13:26:01 -0700 (PDT)
From: Jim Schaad <>
To: 'Mike Jones' <>, 'Pete Resnick' <>, 'The IESG' <>
References: <> <>
In-Reply-To: <>
Date: Mon, 06 Oct 2014 13:23:25 -0700
Message-ID: <00c501cfe1a3$64fd3b70$2ef7b250$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJ6Hs7f0r6lU+lGW5PdshCxaY27mgI+oQo3mr0DPuA=
Content-Language: en-us
Subject: Re: [jose] Pete Resnick's Abstain on draft-ietf-jose-json-web-key-33: (with COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Javascript Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 06 Oct 2014 20:26:06 -0000

> -----Original Message-----
> From: jose [] On Behalf Of Mike Jones
> Sent: Monday, October 06, 2014 12:54 AM
> To: Pete Resnick; The IESG
> Cc:;;
> Subject: Re: [jose] Pete Resnick's Abstain on
> (with COMMENT)
> Thanks for your review, Pete.  I've added the working group to the thread
> they're aware of your comments.
> > -----Original Message-----
> > From: Pete Resnick []
> > Sent: Wednesday, October 01, 2014 9:54 PM
> > To: The IESG
> > Cc:;
> >
> > Subject: Pete Resnick's Abstain on draft-ietf-jose-json-web-key-33:
> > (with
> >
> > 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
> >
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> >
> >
> >
> >
> > ----------------------------------------------------------------------
> > ----------------------------------------------------------------------
> >
> > 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
> > 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
> 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
> member names, was: [jose] SECDIR review of
> in the JOSE mailing list archives, beginning on 9/12/14.  There was a
> JSON working group that created a new standards-track JSON spec (RFC 7159)
> that that decided *not* to prohibit parsers from accepting inputs with
> names.  JOSE doesn't have sufficient influence to change the JSON parsers
> are actually deployed and available to developers.  As Richard Barnes
> out during the telechat, the point of JOSE is to enable crypto with tools
> 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
> it.
> Actually, it's not.  The second paragraph says where the initial values
> 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
> 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
> We talked about removing "use" but the working group was very much in
> 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
> 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,
> should be prepared to have new key types appear in the set of advertised
> 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
> 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
> 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
> > Simply make it:
> >
> >    The content type of "jwk+json" can be used for "cty" header of the
> >
> > 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
> 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