Re: [jose] Ted Lemon's No Objection on draft-ietf-jose-json-web-signature-33: (with COMMENT)

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 840521A1B74; Mon, 6 Oct 2014 00:55:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p0rqJTYw7Cit; Mon, 6 Oct 2014 00:55:00 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4AC5B1A1B71; Mon, 6 Oct 2014 00:54:53 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1044.10; Mon, 6 Oct 2014 07:54:51 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1044.10 via Frontend Transport; Mon, 6 Oct 2014 07:54:51 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Mon, 6 Oct 2014 07:54:51 +0000
Received: from ([]) by ([]) with mapi id 14.03.0210.003; Mon, 6 Oct 2014 07:54:16 +0000
From: Mike Jones <>
To: Ted Lemon <>, The IESG <>
Thread-Topic: Ted Lemon's No Objection on draft-ietf-jose-json-web-signature-33: (with COMMENT)
Thread-Index: AQHP3kXWA+6Ca7ySWkCHxwvIKzsCX5wiT82g
Date: Mon, 06 Oct 2014 07:54:16 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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)(51914003)(199003)(13464003)(189002)(51704005)(52604005)(377454003)(52044002)(86612001)(4396001)(23676002)(6806004)(44976005)(92566001)(84676001)(92726001)(33656002)(26826002)(15975445006)(68736004)(69596002)(19580395003)(19580405001)(76482002)(85306004)(15202345003)(230783001)(95666004)(50466002)(99396003)(106116001)(81156004)(120916001)(106466001)(107046002)(10300001)(66066001)(21056001)(64706001)(47776003)(20776003)(55846006)(97736003)(104016003)(77096002)(85806002)(85852003)(50986999)(80022003)(46102003)(86362001)(2656002)(87936001)(31966008)(76176999)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB1213;; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-Microsoft-Antispam: UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB1213;
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] Ted Lemon's No Objection on draft-ietf-jose-json-web-signature-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 07:55:03 -0000

Thanks for the review, Ted.  I've added the working group to the thread so they're aware of your comments.

> -----Original Message-----
> From: Ted Lemon []
> Sent: Thursday, October 02, 2014 6:36 AM
> To: The IESG
> Cc:; draft-ietf-jose-json-web-
> Subject: Ted Lemon's No Objection on draft-ietf-jose-json-web-signature-33:
> (with COMMENT)
> Ted Lemon has entered the following ballot position for
> draft-ietf-jose-json-web-signature-33: No Objection
> 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:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> The following sample text is encoded assuming a CR+LF line terminator:
> {"typ":"JWT",
>   "alg":"HS256"}
> I think it would be better to just encode it as a single line, as was done in the
> JWE spec, so as to avoid confusing people who use operating
> systems that use the single-character line ending ("newline").   I
> suspect this applies to other examples as well.   If you have to go
> multiline, you could also address this by just saying "line separators in examples
> are CR+LF ([13, 10])".

Quoting your response to your own message so the working group will also see it:
"This is actually covered in the Appendix, so I don't think it's necessary to make the change I suggest here.   Sorry for the confusion."

> This looks like an attack surface:
>    The Header Parameter names within the JOSE
>    Header MUST be unique; recipients MUST either reject JWSs with
>    duplicate Header Parameter 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].
> Is this really safe?

Quoting Kathleen's response on the thread so the working group will see it:
"I pointed to a thread on this in the ballot text, so thanks for weighing in.  This has been a hot discussion in the WG and is unresolved as to how it should be handled.  This discussion seems to be happening on Pete's Abstain, so let's see if we can keep it there for now and this as a placeholder.  It comes down to implementation issues and a decision as to how we should best handle it.  Thanks."

> I believe you mean "base64 padding characters" here:
>   2.   The encoded representation of the JWS Protected Header MUST be
>         successfully base64url decoded following the restriction that no
>         padding characters have been used.
> I mention this because I don't think you require that no whitespace characters
> be present in the encoded JWS protected header, and someone
> might read this text that way.   This concern exists in several other
> paragraphs in this document, and also in the JWE document.   I don't know
> if it's worth dealing with, but it seems like it might make peoples'
> lives easier if you stated explicitly that you are talking about /base64/ padding.

Thanks for pointing this out.  I believe that it's referring both to base64 padding characters and whitespace.  I'll plan to reword this to make the intent clear.

> Why not just make this a requirement of JWE:
>    o  Require that the "alg" Header Parameter be carried in the
>       protected header.  (This is always the case when using the JWS
>       Compact Serialization and is the approach taken by CMS [RFC6211].)
> Relying on the application to get this right seems chancy.

This point was raised in Tero Kivinen's secdir review as well.  Richard Barnes led a thorough discussion of the topic.  The result was the inclusion of the Security Considerations text in Section 10.7 (Algorithm Protection).

> This document has a really great security considerations section.
> Thanks for being so thorough and clear.

Thanks.  A lot of smart and knowledgeable people have contributed to it.  Thanks for your contributions as well.

				-- Mike