[jose] JWS Unencoded Payload Option and the % character
Mike Jones <Michael.Jones@microsoft.com> Tue, 22 September 2015 22:23 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 88CE21B2F03 for <jose@ietfa.amsl.com>; Tue, 22 Sep 2015 15:23:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.001
X-Spam-Level:
X-Spam-Status: No, score=-4.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, 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 OKPn8S5qNC3K for <jose@ietfa.amsl.com>; Tue, 22 Sep 2015 15:23:16 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0121.outbound.protection.outlook.com [65.55.169.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6EBD1B2F06 for <jose@ietf.org>; Tue, 22 Sep 2015 15:23:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1NjbKwv0GvVoApqjT7EWBGKdXvBsBZ44PmYWcOm56ek=; b=GCAYjpATblyo/Zx4CcaXj1YxjHZ8VzRetIPnivoWf/u4GRQ+5bsEcUg8m8+niP9HYeLNKPnXKVSaDMqMATxOJOl/TVx3nTV/6qSIbBXFiHKV3RRcGq3G9qr7QPJvo7+33ws4Pbri1RjogC3SNT789+UkNvZiAFzkFrlUEDMg7Bw=
Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.268.17; Tue, 22 Sep 2015 22:23:11 +0000
Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0268.017; Tue, 22 Sep 2015 22:23:11 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: "jose@ietf.org" <jose@ietf.org>
Thread-Topic: JWS Unencoded Payload Option and the % character
Thread-Index: AdD1hT2A8m9ACawFRC6C6gO928Ktyw==
Date: Tue, 22 Sep 2015 22:23:11 +0000
Message-ID: <BY2PR03MB4426BED954F4CAC80447B4EF5450@BY2PR03MB442.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com;
x-originating-ip: [2001:4898:80e8:7::3ce]
x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:cZ9KONV3bSIHxp/wEsXz++Q/A/TcR1w4kEuEQAXhlAQ3FGRb0i8wxWrUsCl0cuWhJvtMcq1enxodSyO3CnTvfTkH1z1Mj6F4UbI0m43z8O8N4f0qgd0vHaR7GGTuQKc7lBiIV1ZZtXqOkWUxK/qK6w==; 24:y/RVIB7F/EjBQbcm7iCl2DrzwNWuAEcKGNeZxZJZpZIUp8nD6mx8Vm+FgkuRZrKFk0FljGRKkdSbtgZ745JUjSBMrKaXOuipNe6gxj1d84U=; 20:wolvoICY8G7kmc4VqkDBb6+QCDWuxb/1mxTR5XRfD5scY1X5+oCs63IWOgJt0X8x2zQLj/6LdhvkrLcb27d+zQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442;
x-microsoft-antispam-prvs: <BY2PR03MB442D07DC79CD0F87B43B2B3F5450@BY2PR03MB442.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(108003899814671);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(5005006)(8121501046)(520078)(3002001)(61426024)(61427024); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442;
x-forefront-prvs: 0707248B64
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(199003)(5003600100002)(8990500004)(10400500002)(5005710100001)(10290500002)(10090500001)(33656002)(87936001)(19300405004)(16236675004)(19625215002)(86612001)(105586002)(5002640100001)(11100500001)(106356001)(46102003)(19580395003)(19609705001)(19617315012)(5004730100002)(76576001)(2501003)(15975445007)(77156002)(5007970100001)(102836002)(2351001)(110136002)(62966003)(54356999)(450100001)(50986999)(99286002)(68736005)(77096005)(92566002)(5001920100001)(2900100001)(5001860100001)(81156007)(5001960100002)(107886002)(229853001)(189998001)(86362001)(40100003)(101416001)(97736004)(64706001)(74316001)(5001830100001)(122556002)(4001540100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4426BED954F4CAC80447B4EF5450BY2PR03MB442namprd_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2015 22:23:11.4920 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442
Archived-At: <http://mailarchive.ietf.org/arch/msg/jose/PneDdpzbilptlthOAQd7NgA95WU>
Subject: [jose] JWS Unencoded Payload Option and the % character
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: <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: Tue, 22 Sep 2015 22:23:20 -0000
There's one outstanding issue with the JWS Unencoded Payload Option specification that I'd like to see working group discussion on: What should the processing rules be for a '%' character in the JWS Payload for a non-detached payload using "b64":false with the JWS Compact Serialization? I see the possibilities as being: 1. Use of '%' is prohibited, because it is not URL-safe. This is the behavior current specified in https://tools.ietf.org/html/draft-ietf-jose-jws-signing-input-options-02#section-5.2. This is the simplest option. It means that inline unencoded payloads are limited to using letters, numbers, dash, underscore, and tilde. 2. Use of '%' is allowed and has no defined semantics at the JWS level; it's just another allowed character. This maintains the invariant that the JWS Signing input consists of the characters before the second '.' in the JWS representation. Note that because '%' is not URL-safe, any URLs containing JWS containing '%' characters would have to form-url-encode them - resulting in them being represented in the URL as "%25". Applications *could* use '%' at the application level to escape octets using the '%' <hex> <hex> convention but this escaping would not be understood by JWS. For example, the JWS Payload could be "%24%2E02", be represented in the JWS as "%24%2E02", be represented in URLs as "%2524%252E02", and the JWS Signing Input would contain "%24%2E02". I believe that this is the position that was being advocated by Sergey Beryozkin in http://www.ietf.org/mail-archive/web/jose/current/msg05257.html. 3. Use of '%' is allowed and is used for '%' <hex> <hex> encoding of payload octets, with the JWS Signing Input keeping the '%' <hex> <hex> characters as-is. This maintains the invariant that the JWS Signing input consists of the characters before the second '.' in the JWS representation. It requires form-url-decoding of any payload value containing '%' when returning the JWS Payload. For example, the JWS Payload could be "$.02", be represented in the JWS as "%24%2E02", be represented in URLs as "%2524%252E02", and the JWS Signing Input would contain "%24%2E02". 4. Use of '%' is allowed and is used for '%' <hex> <hex> encoding of payload octets, with the JWS Signing Input containing the encoded octets. This loses the invariant that the JWS Signing input consists of the characters before the second '.' in the JWS representation. It requires form-url-decoding of any payload value containing '%' both when doing signing and when returning the JWS Payload. For example, the JWS Payload could be "$.02", be represented in the JWS as "%24%2E02", be represented in URLs as "%2524%252E02", and the JWS Signing Input would contain "$.02". This is the most consistent with the JWS JSON Serialization processing rules in https://tools.ietf.org/html/draft-ietf-jose-jws-signing-input-options-02#section-5.3, in which the JWS Payload and JWS Signing Input values are determined after performing any escape processing. I believe that this is the position that was being advocated by Jim Schaad in http://www.ietf.org/mail-archive/web/jose/current/msg05259.html. How would working group members like to see us use (or not use) '%'? -- Mike
- [jose] JWS Unencoded Payload Option and the % cha… Mike Jones
- Re: [jose] JWS Unencoded Payload Option and the %… Manger, James
- Re: [jose] JWS Unencoded Payload Option and the %… Mike Jones
- Re: [jose] JWS Unencoded Payload Option and the %… Manger, James
- Re: [jose] JWS Unencoded Payload Option and the %… Anders Rundgren
- Re: [jose] JWS Unencoded Payload Option and the %… Vladimir Dzhuvinov
- Re: [jose] JWS Unencoded Payload Option and the %… Mike Jones
- Re: [jose] JWS Unencoded Payload Option and the %… John Bradley
- Re: [jose] JWS Unencoded Payload Option and the %… Nat Sakimura
- Re: [jose] JWS Unencoded Payload Option and the %… Jim Schaad
- Re: [jose] JWS Unencoded Payload Option and the %… Mike Jones
- Re: [jose] JWS Unencoded Payload Option and the %… John Bradley
- Re: [jose] JWS Unencoded Payload Option and the %… Mike Jones