IETF Logo Mail Archive

Re: [jose] Clean interop with "oth"

Mike Jones <Michael.Jones@microsoft.com> Tue, 11 November 2014 05:08 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 54F7A1AD291 for <jose@ietfa.amsl.com>; Mon, 10 Nov 2014 21:08:58 -0800 (PST)
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 gxqOyq7A9Qaa for <jose@ietfa.amsl.com>; Mon, 10 Nov 2014 21:08:53 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0118.outbound.protection.outlook.com [207.46.100.118]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C80781AD385 for <jose@ietf.org>; Mon, 10 Nov 2014 21:08:52 -0800 (PST)
Received: from BY1PR0301MB1205.namprd03.prod.outlook.com (25.161.203.154) by BY1PR0301MB1269.namprd03.prod.outlook.com (25.161.205.143) with Microsoft SMTP Server (TLS) id 15.1.11.14; Tue, 11 Nov 2014 05:08:51 +0000
Received: from CO2PR03CA0014.namprd03.prod.outlook.com (10.141.194.141) by BY1PR0301MB1205.namprd03.prod.outlook.com (25.161.203.154) with Microsoft SMTP Server (TLS) id 15.1.11.14; Tue, 11 Nov 2014 05:08:49 +0000
Received: from BN1BFFO11FD024.protection.gbl (2a01:111:f400:7c10::1:124) by CO2PR03CA0014.outlook.office365.com (2a01:111:e400:1414::13) with Microsoft SMTP Server (TLS) id 15.1.16.15 via Frontend Transport; Tue, 11 Nov 2014 05:08:49 +0000
Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD024.mail.protection.outlook.com (10.58.144.87) with Microsoft SMTP Server (TLS) id 15.1.6.13 via Frontend Transport; Tue, 11 Nov 2014 05:08:48 +0000
Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.229]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0210.003; Tue, 11 Nov 2014 05:08:18 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Richard Barnes <rlb@ipv.sx>, "jose@ietf.org" <jose@ietf.org>
Thread-Topic: [jose] Clean interop with "oth"
Thread-Index: AQHP/WyVb2NJxGNr2k6zq0BNVsNdp5xa3urQ
Date: Tue, 11 Nov 2014 05:08:18 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739439BB7A9E3@TK5EX14MBXC286.redmond.corp.microsoft.com>
References: <CAL02cgToqHMvpeXdvnRTf7PEpvsbZf+kP7zM5i=r5rzJP86wCA@mail.gmail.com>
In-Reply-To: <CAL02cgToqHMvpeXdvnRTf7PEpvsbZf+kP7zM5i=r5rzJP86wCA@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.36]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439BB7A9E3TK5EX14MBXC286r_"
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)(6009001)(438002)(377454003)(199003)(189002)(62966003)(50986999)(77096003)(76176999)(512874002)(54356999)(81156004)(106466001)(95666004)(77156002)(107886001)(107046002)(92726001)(86362001)(46102003)(92566001)(86612001)(71186001)(66066001)(21056001)(64706001)(106116001)(55846006)(20776003)(16236675004)(120916001)(99396003)(97736003)(4396001)(31966008)(15202345003)(84676001)(19300405004)(84326002)(87936001)(33656002)(69596002)(68736004)(104016003)(2656002)(26826002)(6806004)(85806002)(19580405001)(19580395003)(19625215002)(15975445006)(2501002)(44976005); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB1205; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-Microsoft-Antispam: UriScan:;UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB1205;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Exchange-Antispam-Report-CFA: BCL:0; PCL:0; RULEID:(7)(6); SRVR:BY1PR0301MB1205;
X-Forefront-PRVS: 0392679D18
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-Exchange-Antispam-Report-CFA: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB1205;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB1269;
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/pPCn4BHNuGG7qfJ9tHXXlm-jlyQ
Subject: Re: [jose] Clean interop with "oth"
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: Tue, 11 Nov 2014 05:08:59 -0000

Clarification question:  Would the private key operate correctly, if possibly inefficiently, in the multi-prime case if all the private key parameters other than “d” were ignored?  I ask, because if this is the case, your wording could be modified to the less severe text:

If the consumer of a JWK does not support multi-prime RSA moduli and it encounters a private key that includes the "oth" parameter, then it MUST either reject the key or ignore all the private key parameters other than “d”.

                                                            -- Mike

From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Monday, November 10, 2014 7:02 PM
To: jose@ietf.org
Subject: [jose] Clean interop with "oth"

It seems clear that there are no implementations today that support the "oth" element, i.e., that support RSA with a modulus with multiple factors.  At least some of them simply ignore the "oth" element, which unfortunately leads to incorrect operation.  I would propose something of the following form in JWA:

"""
If the consumer of a JWK does not support multi-prime RSA moduli and it encounters a private key that includes the "oth" parameter, then it MUST reject the key.
"""

v2.30.2 | Report a Bug | By Email | System Status