Re: [jose] gen-art telechat review of draft-ietf-jose-json-web-key-33

Mike Jones <> Tue, 30 September 2014 18:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 74D011A8707; Tue, 30 Sep 2014 11:30:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0kLfJfp2V6dG; Tue, 30 Sep 2014 11:30:09 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6F8F91A86FE; Tue, 30 Sep 2014 11:30:09 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1039.15; Tue, 30 Sep 2014 18:30:07 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1039.15 via Frontend Transport; Tue, 30 Sep 2014 18:30:07 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1029.15 via Frontend Transport; Tue, 30 Sep 2014 18:30:07 +0000
Received: from ([]) by ([]) with mapi id 14.03.0195.002; Tue, 30 Sep 2014 18:29:30 +0000
From: Mike Jones <>
To: Scott Brim <>, gen-art <>, "" <>
Thread-Topic: gen-art telechat review of draft-ietf-jose-json-web-key-33
Thread-Index: AQHP3Cmni2P6B05o4kyE6MMT8oxGa5wZ+9EA
Date: Tue, 30 Sep 2014 18:29:29 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439BAA58ABTK5EX14MBXC288r_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(189002)(13464003)(76104003)(377424004)(199003)(377454003)(43784003)(4396001)(84676001)(99396003)(10300001)(76482002)(33656002)(97736003)(106116001)(81156004)(15975445006)(120916001)(55846006)(68736004)(69596002)(95666004)(77096002)(512874002)(107046002)(44976005)(6806004)(20776003)(80022003)(46102003)(87936001)(86362001)(85306004)(19625215002)(84326002)(16236675004)(85852003)(64706001)(19580395003)(26826002)(19580405001)(31966008)(92566001)(71186001)(230783001)(104016003)(54356999)(86612001)(66066001)(106466001)(19300405004)(92726001)(15202345003)(2656002)(76176999)(21056001)(19617315012)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB279;; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en;
X-Microsoft-Antispam: UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB279;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Exchange-Antispam-Report-Test: UriScan:;
X-Forefront-PRVS: 0350D7A55D
Received-SPF: Pass ( domain of designates as permitted sender); client-ip=;;
Authentication-Results: spf=pass (sender IP is;
Cc: "" <>
Subject: Re: [jose] gen-art telechat review of draft-ietf-jose-json-web-key-33
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: Tue, 30 Sep 2014 18:30:12 -0000

Thanks for your review, Scott.  I'm adding the working group to the thread so they're aware of your comments.  Replies are inline below...

-----Original Message-----
From: Scott Brim []
Sent: Monday, September 29, 2014 2:08 PM
To: gen-art;
Subject: gen-art telechat review of draft-ietf-jose-json-web-key-33

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <>.

Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Document: draft-ietf-jose-json-web-key-33

Reviewer: Scott Brim

Review Date: 2014-09-28

IETF LC End Date: 2014-09-03

IESG Telechat date: 2014-10-02

Summary: ready with possible minor issues

Major issues:

Minor issues:

  More than once it is said that members that are not understood

  should or must be ignored. Wouldn't this depend on context? Couldn't

  there be uses of the data structure where a negative reply would be

  needed if something is not understood, so the sender can adapt?

This language is present so that extensions carrying additional information can be added in a non-breaking fashion.  You’re right that, in theory, a “must-understand” capability could be added for particular fields, as was done for JOSE header parameters in, but in practice, no working group member has come forward saying they are aware of an application that needs this for key representations.  Rather, the working group’s thoughts were that multiple keys would be present in a JWK Set, some of which might not be understood, but those that are understood would be used.  This might be the case, for instance, when an entirely new key type (not RSA, Elliptic Curve, or Symmetric) is invented and added at some point in the future.

Do you have a specific example in mind that requires a “must-understand” capability for key representations?

  In Section 4.3, you give the general principle that multiple

  unrelated key operations shouldn't be specified for a key, and give

  an example. Since this is a security issue of unknown magnitude (the

  future isn't here yet), what do you think of removing uncertainty by

  being more exhaustive in the principles and/or examples?

This is a “SHOULD NOT” rather than a “MUST NOT” because there are existing use cases in which the same RSA key is used for both signing and encryption.  I’m not an expert in the underlying cryptography, but it’s my understanding that this is quasi-OK for RSA because both RSA signatures and RSA encryption actually are based on an RSA encryption operation, and so what appears to be using a key being used for unrelated operations actually isn’t under the covers, in this particular case.  However, if you want to supply additional proposed security considerations text on this issue (or possibly even better, cite pertinent security considerations text in an existing RFC that we could reference), that would be appreciated.

Nits/editorial comments:

... Scott

                                                            Thanks again,

                                                            -- Mike