Re: [jose] Rationale for keeping the JWS "none" algorithm
Mike Jones <Michael.Jones@microsoft.com> Thu, 03 May 2018 19:02 UTC
Return-Path: <Michael.Jones@microsoft.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D95F12DA00 for <jose@ietfa.amsl.com>; Thu, 3 May 2018 12:02:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
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 H4irfuYo6lHw for <jose@ietfa.amsl.com>; Thu, 3 May 2018 12:02:22 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0093.outbound.protection.outlook.com [104.47.36.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC2A812DA06 for <jose@ietf.org>; Thu, 3 May 2018 12:02:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WCrTecI1UVGK+So6ES19jXHG1jZB/UM7sWv2aFKG4Xw=; b=awtj72aC4PPcFn9FSC6acAWzvWk9XCuZFgIPIDPizDmqceNoZ0ZBN6uR3yVlrw0UNzRSnMa3A/tVHEnZumK7AzjE5MAxKopJYgo4cXftsh9N4dp6GHpK7q69qAJ1X4ukv0bMRKyytdUG9n6QvvU0NeAyr9SssPlCw3XszQ1D6lM=
Received: from DM5PR00MB0296.namprd00.prod.outlook.com (2603:10b6:4:9e::37) by DM5PR00MB0407.namprd00.prod.outlook.com (2603:10b6:4:a0::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.776.0; Thu, 3 May 2018 19:02:20 +0000
Received: from DM5PR00MB0296.namprd00.prod.outlook.com ([fe80::25e2:81d9:c7fa:c877]) by DM5PR00MB0296.namprd00.prod.outlook.com ([fe80::25e2:81d9:c7fa:c877%3]) with mapi id 15.20.0777.000; Thu, 3 May 2018 19:02:19 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>, "jose@ietf.org" <jose@ietf.org>
Thread-Topic: [jose] Rationale for keeping the JWS "none" algorithm
Thread-Index: AQHT4qZUpa26jDG/AEGDmPjqoeS4RqQeXEkw
Date: Thu, 03 May 2018 19:02:19 +0000
Message-ID: <DM5PR00MB02960967CA1624289EC7B97CF5870@DM5PR00MB0296.namprd00.prod.outlook.com>
References: <0efecff3-e4ac-4f7c-17d5-30a74830263c@gmail.com>
In-Reply-To: <0efecff3-e4ac-4f7c-17d5-30a74830263c@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-05-03T19:02:18.4959611Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General
x-originating-ip: [2001:4898:80e8::7c9]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR00MB0407; 7:ZKPV7iVTuZtBrE+2mtGvvq0A/9Dn7170R41zyV2kMafFWXNejBY1Nmn46yFY+fW7CKBPieHU6rtCwR0AeA5sO9OyKTdWaPxamMYtaY0EjmNeSVR2iZvI4Z8mjQyFhBTNoXFj8/ivXjty7NwJOp3ETd4RIKUhWffDIMG05lgcFjX4RyIrEVpvkYX7CAXnf/pe3Wj3q50jr65vuMmijYrNcFmZcSVkzlndZxMCyGLFtjuwUX9ZoFGWQJ2CsUmiOpIB; 20:h4qYTIxFI4+v5la0NJpTbF4cZHP3F/UC6YpgJMj1NEK8RFwANm3Dh/4ILx4kvhuJFT1zbQhV6sWol5+nM7p+mxXEjsxOYU22sWfz/r1K2MFHGkzrc9GehJnZDW0OTNvmHJc+cCPc2UYcIjtzhThJk4ePf3Lgl1DuTfMuQ4cAIUY=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:DM5PR00MB0407;
x-ms-traffictypediagnostic: DM5PR00MB0407:
x-microsoft-antispam-prvs: <DM5PR00MB04073772E0CF72A1DB2AF4F6F5870@DM5PR00MB0407.namprd00.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(5005006)(8121501046)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(3002001)(3231254)(2018427008)(944501410)(52105095)(10201501046)(93006095)(93001095)(6055026)(6041310)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:DM5PR00MB0407; BCL:0; PCL:0; RULEID:; SRVR:DM5PR00MB0407;
x-forefront-prvs: 066153096A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(396003)(39380400002)(39860400002)(346002)(189003)(199004)(13464003)(46003)(6506007)(102836004)(53546011)(7736002)(76176011)(52396003)(305945005)(7696005)(97736004)(110136005)(6346003)(186003)(5250100002)(2900100001)(2501003)(486006)(22452003)(33656002)(105586002)(106356001)(6246003)(476003)(39060400002)(8990500004)(10090500001)(53936002)(316002)(9686003)(99286004)(6306002)(55016002)(3280700002)(446003)(2906002)(10290500003)(8936002)(81166006)(72206003)(3660700001)(966005)(478600001)(86612001)(68736007)(6436002)(229853002)(74316002)(6116002)(8676002)(14454004)(25786009)(11346002)(81156014)(5660300001)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR00MB0407; H:DM5PR00MB0296.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com;
x-microsoft-antispam-message-info: sCp5/7dJA49O1oQDzSfubdfhcDrOXg7fBU5x1kWthMQzKhNaDqyzix7mR2AM7ba2ChwB7iSu97HOxNtX+AiXtRSutR9I4f9gnezrye6UMIWRZ5tU4DkMrvLSO6+ThxnVNNuaDQyR9TQzEBapAjVoKvy3hUxD8ww9GaVIp1gEJ4kNJ+DK7/P8dvNxOT6UGpdt
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 4d45c306-0873-440e-8a09-08d5b1286555
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4d45c306-0873-440e-8a09-08d5b1286555
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2018 19:02:19.8285 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0407
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/fMj-pamjXLJUaUVl5OrMURlH1vs>
Subject: Re: [jose] Rationale for keeping the JWS "none" algorithm
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 03 May 2018 19:02:24 -0000
Anders is right that "alg":"none" enables the same base64url-encoded JWS container format to be used both for signed and unsigned content. That's why "none" is compelling for some use cases - especially those in which signing can be optional. -- Mike -----Original Message----- From: jose <jose-bounces@ietf.org> On Behalf Of Anders Rundgren Sent: Wednesday, May 2, 2018 11:16 PM To: jose@ietf.org Subject: [jose] Rationale for keeping the JWS "none" algorithm A reason for keeping the "none" algorithms is because JWS is an intrusive scheme where the signature container effectively becomes the primary "message". If you want messages to only OPTIONALLY be signed you get a rather quirky system unless you have a "none" algorithm. Cleartext JWS (https://tools.ietf.org/id/draft-erdtman-jose-cleartext-jws-00.html) OTOH, doesn't need a "none" algorithm since an unsigned message simply wouldn't contain a signature property. Unsigned Message: { "mydata":... } Message Signed with Cleartext JWS: { "mydata":..., "signature": { .... } } BTW, if the verifier doesn't enforce a policy including accepted Algorithms, Keys to trust, Key identification mechanisms, Anticipated extensions etc. all bets are off for any signature solution even if the signature software is "perfect" :-) Anders _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose
- [jose] Rationale for keeping the JWS "none" algor… Anders Rundgren
- Re: [jose] Rationale for keeping the JWS "none" a… Mike Jones