Re: [jose] JWK glitches in deployment
Mike Jones <Michael.Jones@microsoft.com> Sat, 13 September 2014 00:05 UTC
Return-Path: <Michael.Jones@microsoft.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832521A00F8 for <jose@ietfa.amsl.com>; Fri, 12 Sep 2014 17:05:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjIMY9ZbVAfO for <jose@ietfa.amsl.com>; Fri, 12 Sep 2014 17:05:46 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0114.outbound.protection.outlook.com [207.46.100.114]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E4811A010F for <jose@ietf.org>; Fri, 12 Sep 2014 17:05:46 -0700 (PDT)
Received: from BN3PR0301CA0012.namprd03.prod.outlook.com (25.160.180.150) by DM2PR0301MB0848.namprd03.prod.outlook.com (25.160.215.146) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Sat, 13 Sep 2014 00:05:47 +0000
Received: from BL2FFO11FD036.protection.gbl (2a01:111:f400:7c09::188) by BN3PR0301CA0012.outlook.office365.com (2a01:111:e400:4000::22) with Microsoft SMTP Server (TLS) id 15.0.1029.13 via Frontend Transport; Sat, 13 Sep 2014 00:05:44 +0000
Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD036.mail.protection.outlook.com (10.173.161.132) with Microsoft SMTP Server (TLS) id 15.0.1019.14 via Frontend Transport; Sat, 13 Sep 2014 00:05:43 +0000
Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.60]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.03.0195.002; Sat, 13 Sep 2014 00:05:06 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Chuck Mortimore <cmortimore@salesforce.com>, "Manger, James" <James.H.Manger@team.telstra.com>
Thread-Topic: [jose] JWK glitches in deployment
Thread-Index: Ac/A+eKYNRa6AT3ORduHKtSlXvbGfAAVNPiAA2XPkdA=
Date: Sat, 13 Sep 2014 00:05:05 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739439AEC345E@TK5EX14MBXC292.redmond.corp.microsoft.com>
References: <255B9BB34FB7D647A506DC292726F6E127C6DE46FD@WSMSG3153V.srv.dir.telstra.com> <CA+wnMn_PO5i-A4AK2CYG-XHOgUti5R6yMPMiTH4yoH7M=iXdEA@mail.gmail.com>
In-Reply-To: <CA+wnMn_PO5i-A4AK2CYG-XHOgUti5R6yMPMiTH4yoH7M=iXdEA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.75]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AEC345ETK5EX14MBXC292r_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(57704003)(377454003)(43544003)(24454002)(199003)(189002)(31966008)(74662001)(74502001)(81156004)(106466001)(19300405004)(107046002)(81342001)(15202345003)(90102001)(4396001)(80022001)(20776003)(64706001)(71186001)(104016003)(66066001)(19617315012)(54356999)(97736003)(50986999)(87936001)(92726001)(83072002)(86362001)(92566001)(85852003)(86612001)(95666004)(76176999)(99396002)(512874002)(16236675004)(77096002)(15975445006)(85306004)(84676001)(85806002)(84326002)(19580405001)(19580395003)(6806004)(44976005)(83322001)(69596002)(21056001)(68736004)(26826002)(19625215002)(33656002)(2656002)(81542001)(77982001)(55846006)(76482001)(79102001)(46102001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0848; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 03333C607F
Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com;
Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com;
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/7V6CLizBwIR7npxMyDRXKBhJe0k
Cc: "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] JWK glitches in deployment
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Sep 2014 00:05:49 -0000
I propose that we add this note to the text describing the RSA modulus representation to help implementers, as Chuck suggested below: Note that implementers have found that some cryptographic libraries prefix an extra zero-valued octet to the modulus representations they return, for instance, returning 257 octets for a 2048 bit key, rather than 256. Implementations using such libraries will need to take care to omit the extra octet from the base64url encoded representation. -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Chuck Mortimore Sent: Tuesday, August 26, 2014 9:57 AM To: Manger, James Cc: jose@ietf.org Subject: Re: [jose] JWK glitches in deployment We probably could have benefited from language in the spec calling out the leading zero byte as an area of concern. That said our ecosystem detected it pretty quickly and after some collaborate with Microsoft, we have a fix due out this week, so the growing pains are sorting themselves out rather quickly. -cmort On Mon, Aug 25, 2014 at 11:49 PM, Manger, James <James.H.Manger@team.telstra.com<mailto:James.H.Manger@team.telstra.com>> wrote: In March, Google’s JWK file https://www.googleapis.com/oauth2/v2/certs (used for OpenID Connect) had 3 bugs: base64 instead of base64url; 1024-bit instead of >=2048-bit; leading zero byte on moduli. Today Google’s JWK file has 1 different bug: the base64url encoding has a trailing “=”. Salesforce’s JWK file https://login.salesforce.com/id/keys has 1 bug: a leading zero byte on the RSA moduli. Are these just teething problems, or do we need a stronger warning in the spec. These bugs also change the JWK’s thumbprint (another reminder not to base security on thumbprints being unique for a given key). -- James Manger
- [jose] JWK glitches in deployment Manger, James
- Re: [jose] JWK glitches in deployment Chuck Mortimore
- Re: [jose] JWK glitches in deployment Mike Jones
- Re: [jose] JWK glitches in deployment Mike Jones