Re: [jose] Secdir review of draft-ietf-jose-json-web-signature-31

Mike Jones <> Tue, 23 September 2014 23:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EA0A71A6F2A; Tue, 23 Sep 2014 16:43:25 -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 f2IhxXH8tXZ4; Tue, 23 Sep 2014 16:43:23 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 50F791A6F1E; Tue, 23 Sep 2014 16:43:23 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1034.13; Tue, 23 Sep 2014 23:43:22 +0000
Received: from (2a01:111:f400:7c10::179) by (2a01:111:e400:1414::15) with Microsoft SMTP Server (TLS) id 15.0.1034.13 via Frontend Transport; Tue, 23 Sep 2014 23:43:22 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1029.15 via Frontend Transport; Tue, 23 Sep 2014 23:43:21 +0000
Received: from ([]) by ([]) with mapi id 14.03.0195.002; Tue, 23 Sep 2014 23:43:12 +0000
From: Mike Jones <>
To: Tero Kivinen <>
Thread-Topic: Secdir review of draft-ietf-jose-json-web-signature-31
Thread-Index: AQHPyDgrWdMUgOdf8EqNa4N9Ytbe4ZvzQwoggARGNkCADAcqAIAFVMkQgARgVwCAAjoeEA==
Date: Tue, 23 Sep 2014 23:43:11 +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:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(13464003)(189002)(199003)(377454003)(85306004)(77982003)(47776003)(46102003)(81156004)(50466002)(106116001)(90102001)(106466001)(21056001)(31966008)(85852003)(110136001)(120916001)(20776003)(107046002)(93886004)(46406003)(77096002)(76482002)(230783001)(86612001)(80022003)(4396001)(97736003)(2656002)(85806002)(92566001)(87936001)(84676001)(44976005)(92726001)(99396002)(104016003)(33656002)(55846006)(66066001)(6806004)(95666004)(50986999)(79102003)(81542003)(68736004)(86362001)(19580395003)(19580405001)(74502003)(74662003)(23726002)(76176999)(83072002)(10300001)(69596002)(64706001)(54356999)(97756001)(81342003)(83322001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR03MB398;; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en;
X-Microsoft-Antispam: UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR03MB398;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0343AC1D30
Received-SPF: Pass ( domain of designates as permitted sender); client-ip=;;
Authentication-Results: spf=pass (sender IP is;
Cc: "" <>, "" <>, "" <>, "" <>, "" <>
Subject: Re: [jose] Secdir review of draft-ietf-jose-json-web-signature-31
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, 23 Sep 2014 23:43:26 -0000

Thanks again for your review, Tero.  The resolutions discussed in this thread have been applied to the -32 draft.

				-- Mike

-----Original Message-----
From: Tero Kivinen [] 
Sent: Monday, September 22, 2014 6:42 AM
To: Mike Jones
Subject: RE: Secdir review of draft-ietf-jose-json-web-signature-31

Mike Jones writes:
> Tero - for your point "2) Hash inside "alg" and inside the signature", 
> could you please write proposed security considerations text 
> addressing this issue?  I'd think it should describe the need for 
> implementations to ensure that signature verification is done for the 
> exact algorithm specified in the "alg" header parameter, no matter 
> what algorithm information may (or may not) have been encoded into the 
> signature value in an algorithm-specific manner.

Something like this:

  In case of algorithms where there is algorithm parameters specified
  also inside the actual signature, the implementations MUST verify
  that the parameters inside the signature and the parameters
  specified by the "alg" Header Parameter match. This includes for
  example the RSASSA-PKCS-v1_5 algorithms ("RS*") where the signature
  contains the hash algorithm and most libraries actually use the hash
  algorithm specified inside the signature when verifying the
  signature. This test is required as the steps in the section 5.2
  verify that algorithms specified by the "alg" Header Parameter are
  acceptable, and if those algorithms could be different the attacker
  could be able to claim to use strong hash algorithm while actually
  using weak one inside the signature. 

> For your point "3) There is no explicit warning about the "alg"
> "none"", I plan to add the additional step that you suggested.

In my text above I assumed you had already added step in section 5.2 to verify that "alg" is acceptable. 

> For your point "4) Thumbprint formats" if you or someone else wants to 
> define an additional thumbprint format for use in IoT contexts (or any 
> other contexts), I encourage you to write an Internet Draft that does 
> so, registering the new header parameter defined in the JSON Web 
> Signature and Encryption Header Parameters registry.

That can of course be done, but I would have hoped the initial version of the specification would also be usable in the IoT context, where the use of raw public keys will most likely arise.