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

Mike Jones <> Mon, 06 October 2014 07:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EAF0F1A1B45; Mon, 6 Oct 2014 00:54:33 -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, 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 s5Xlend8oOHo; Mon, 6 Oct 2014 00:54:31 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8C2221A1B62; Mon, 6 Oct 2014 00:54:31 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1044.10; Mon, 6 Oct 2014 07:54:30 +0000
Received: from (2a01:111:f400:7c0c::116) by (2a01:111:e400:2c5d::45) with Microsoft SMTP Server (TLS) id 15.0.1044.10 via Frontend Transport; Mon, 6 Oct 2014 07:54:29 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Mon, 6 Oct 2014 07:54:29 +0000
Received: from ([]) by ([]) with mapi id 14.03.0210.003; Mon, 6 Oct 2014 07:54:21 +0000
From: Mike Jones <>
To: Richard Barnes <>, The IESG <>
Thread-Topic: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-signature-33: (with DISCUSS and COMMENT)
Thread-Index: AQHP3fhplIq+W4ZoEEasWTGBJnPDQpwiYnaw
Date: Mon, 06 Oct 2014 07:54:20 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
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)(189002)(51704005)(52044002)(377454003)(43784003)(13464003)(199003)(77096002)(97756001)(81156004)(76482002)(47776003)(87936001)(66066001)(31966008)(21056001)(50466002)(97736003)(95666004)(86612001)(4396001)(85306004)(106116001)(106466001)(80022003)(85852003)(44976005)(85806002)(46406003)(68736004)(19580395003)(107046002)(92726001)(84676001)(69596002)(6806004)(10300001)(76176999)(230783001)(19580405001)(23726002)(2656002)(20776003)(33656002)(99396003)(55846006)(86362001)(92566001)(120916001)(64706001)(15202345003)(50986999)(561944003)(15975445006)(46102003)(54356999)(104016003)(26826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1202;; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en;
X-Microsoft-Antispam: UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1202;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 03569407CC
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-signature-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: Mon, 06 Oct 2014 07:54:34 -0000

Thanks for your review, Richard.  I'm repeating my previous responses from my Thursday reply, but this time using ">" quoting rather than colors, for better readability by people not using HTML-enabled mail readers...

> -----Original Message-----
> From: jose [] On Behalf Of Richard Barnes
> Sent: Wednesday, October 01, 2014 9:22 PM
> To: The IESG
> Cc:;; draft-ietf-jose-json-web-
> Subject: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-signature-33:
> (with DISCUSS and COMMENT)
> Richard Barnes has entered the following ballot position for
> draft-ietf-jose-json-web-signature-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:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Overall, this document is in much more solid shape than when it began.
> Thanks to the WG for a lot of hard work.  I only have two remaining concerns,
> which should hopefully be easy to address.
> Section 7.2.
> I've had several implementors trying to use JWS in the JSON serialization ask why
> it was necessary to include a "signatures" array in cases where there's only one
> signer.  It seems like this is going to be a major barrier to deployment and re-
> use, so I would propose including the following text:
> """
> In cases where the JWS has been signed by only a single signer, the "signatures"
> array will contain a single object.  In such cases, the elements of the single
> "signatures" object MAY be included at the top level of the JWS object.  A JSON-
> formatted JWS that contains a "signatures" field MUST NOT contain a
> "protected", "header", or "signature" field, and vice versa.
> """
> This may also require some other changes where "signatures" is relied on, e.g.,
> in Section 9 of the JWE spec.

This was previously proposed (I believe during the Denver interim meeting) and rejected by the working group because it complicates both producers and parsers by introducing an unnecessary special case.  Currently, by design, whether there are single or multiple signatures, the same syntax is used.  Your proposal would use a different syntax in the single signature case than in the multiple signature case.  This is likely to result in implementation bugs and inconsistencies.

> Section 6.
> """
> These Header Parameters MUST be integrity protected if the information that
> they convey is to be utilized in a trust decision.
> """
> This smells really fishy to me.  What's your attack scenario?  I'm pretty certain
> that there's no way any of these fields can be altered in such a way that (1) the
> signature will validate, and (2) the recipient will accept a key it shouldn't.  By way
> of contrast, CMS doesn't sign the certificate fields, and the Certificate payload in
> TLS is only signed as a side effect of the protocol's verification that the remote
> end has been the same through the whole handshake (which doesn't apply here).

The attack scenario is trivial to describe.  If an attacker can change information used in a trust decision, the trust decision has no validity.  Unless the information is integrity-protected, the attacker could change the non-integrity-protected portions of the JWS in an undetectable way.

For what it's worth, Sean had us add language in a number of places that basically said that information is only as trustworthy as its source and the means by which it is obtained.  If I remember correctly, this was one of those places.

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Section 2.
> In the definition of "Unsecured JWS", it would be good to note that this requires
> "alg" == "none".


> Section 3.3.
> Why doesn't this section have a JSON-encoded form as well?

Because it's meant to be a simple introductory example to help people get their head around the concept - not a complete tutorial.  Other examples of JSON-encoded objects are found elsewhere in the document and lots of them are found in draft-ietf-jose-cookbook.

> Appendix A.5.
> I would prefer if this example could be removed.  JWT is the only use case for
> Unsecured JWS right now, and there's already an example in that document.

Mike> Given that it's important that implementers using them understand Unsecured JWSs, there is motivation to retain the example.  I'd be interested in what others in the working group think, given that there was substantial support for retaining this functionality when its removal was proposed.

> Thanks for Appendix C.  FWIW, it has been implemented:

You're welcome.

> _______________________________________________
> jose mailing list

				Thanks again!
				-- Mike