Re: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-key-33: (with DISCUSS and COMMENT)

Mike Jones <> Tue, 14 October 2014 12:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 03BF71A87D9; Tue, 14 Oct 2014 05:55:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4czxCXGAMCR5; Tue, 14 Oct 2014 05:55:02 -0700 (PDT)
Received: from ( [IPv6:2a01:111:f400:fc10::760]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 967791A87E2; Tue, 14 Oct 2014 05:55:01 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1049.19; Tue, 14 Oct 2014 12:54:38 +0000
Received: from (2a01:111:f400:7c09::130) by (2a01:111:e400:401e::19) with Microsoft SMTP Server (TLS) id 15.0.1049.19 via Frontend Transport; Tue, 14 Oct 2014 12:54:38 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Tue, 14 Oct 2014 12:54:37 +0000
Received: from ([]) by ([]) with mapi id 14.03.0210.003; Tue, 14 Oct 2014 12:54:00 +0000
From: Mike Jones <>
To: Richard Barnes <>, The IESG <>
Thread-Topic: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-key-33: (with DISCUSS and COMMENT)
Thread-Index: Ac/nreeDVNt1BcbBSC2fXBDrG5BuZQ==
Date: Tue, 14 Oct 2014 12:53:59 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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)(6009001)(438002)(52044002)(43784003)(377454003)(51704005)(189002)(199003)(13464003)(31966008)(21056001)(23726002)(230783001)(85306004)(26826002)(97756001)(80022003)(77096002)(46102003)(87936001)(50466002)(2656002)(85852003)(81156004)(106466001)(15202345003)(85806002)(55846006)(86612001)(50986999)(92566001)(92726001)(86362001)(54356999)(68736004)(69596002)(15975445006)(19580405001)(19580395003)(44976005)(6806004)(84676001)(107046002)(120916001)(99396003)(20776003)(76482002)(47776003)(104016003)(33656002)(66066001)(97736003)(4396001)(46406003)(64706001)(95666004); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB1207;; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en;
X-Microsoft-Antispam: UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB1207;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 03648EFF89
Received-SPF: Pass ( domain of designates as permitted sender); client-ip=;;
Authentication-Results: spf=pass (sender IP is;
Cc: "" <>, "" <>, "" <>
Subject: Re: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-key-33: (with DISCUSS and 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: Tue, 14 Oct 2014 12:55:07 -0000

Thanks for your review.  The -34 draft contains the following resolutions.  I hope that you can clear your DISCUSSes on that basis.

				-- Mike

> -----Original Message-----
> From: jose [] On Behalf Of Richard Barnes
> Sent: Wednesday, October 01, 2014 7:34 PM
> To: The IESG
> Cc:;;
> Subject: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-key-33: (with
> Richard Barnes has entered the following ballot position for
> draft-ietf-jose-json-web-key-33: Discuss
> 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:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Section 4.3.
> "The "use" and "key_ops" JWK members SHOULD NOT be used together."
> Did the WG discuss how these could combine?  What was the outcome of that
> discussion?  This could be an important point for interoperability.  For example,
> WebCrypto enforces them both, so it will break if it gets a key with "use" and
> "key_ops" set to inconsistent values.
> pss-operations

I believe that the working group discussion is accurately reflected in this text from the spec:
   The "use" and "key_ops" JWK members SHOULD NOT be used together.
   Applications should specify which of these members they use, if
   either is to be used by the application.

To keep things simple, applications should choose one or the other, based on their needs.  Note that this is a "SHOULD NOT" - not a "MUST NOT", so if WebCrypto believes they have a good reason to allow either or both, they're not violating the spec.  But specifying which combinations are legal and which aren't in the JWK spec seems very high on the complexity to usefulness ratio.  I hope that you will choose to withdraw this DISCUSS on that basis.

> Section 8.
> "[TBD]"
> This needs to be populated before approval.  I don't know what's customary
> here, but "" is an obvious candidate.

Per the spec, is already the recommended name.  Yes, we would create this list before final approval, just as was created before RFC 6749 was approved.  I hope that you'll choose to withdraw this DISCUSS on that basis.

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Section 1.1.
> The pointer for BASE64URL should be to JWS.  One level of indirection, please :)


> Section 4.
> It might be worth being explicit (here or elsewhere):
> "A JWK MUST NOT contain algorithm-specific members for key type other the
> one specified in its "kty" attribute."

I agree with the sentiment, but this actually contradicts the statement that member names that are not understood MUST be ignored.

> Section 4.1.
> "cryptographic algorithm family used with the key"
> "... such as "RSA" or "EC"."


> Section 4.7.
> "base64 encoded ([RFC4648] Section 4 -- not base64url encoded) DER"
> It seems unpleasant for implementations to have to support two flavors of
> base64, especially since this doesn't use PEM directly.  Did the WG discuss just
> using BASE64URL?

Not much, although each certificate value is actually a PEM-encoded value, including allowing newlines, etc.  People agreed with that goal when we did discuss it.

> Section 9.1.
> It might help here to note that technologies like PKIX and JWT can allow relying
> parties to verify the provenance of a key and binding of attributes to it.

Can you propose specific language for this?  What I have in mind is delivering a JWK or JWK Set on a TLS channel using a URL that is cryptographically bound to the use of the key - possibly using the URL as the issuer of a JWT signed with the key, but you may have something else in mind.

> _______________________________________________
> jose mailing list

				Thanks again,
				-- Mike