Re: [jose] JWS Unencoded Payload Option and the % character

Mike Jones <Michael.Jones@microsoft.com> Tue, 29 September 2015 05:20 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 437B71A1A4C for <jose@ietfa.amsl.com>; Mon, 28 Sep 2015 22:20:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.876
X-Spam-Level:
X-Spam-Status: No, score=-2.876 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, HTTP_ESCAPED_HOST=1.125, 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 XCxJNAxTyKlT for <jose@ietfa.amsl.com>; Mon, 28 Sep 2015 22:20:35 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0142.outbound.protection.outlook.com [207.46.100.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D57401A1A45 for <jose@ietf.org>; Mon, 28 Sep 2015 22:20:34 -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=s0ef7XiZfscE0wxzAgqk4N2uKNJa+hGr2DnUtAEE5AE=; b=StoQ4EyaLXe18l+g28GGO0T4W9kJZ8zYrKBJHL3nHOMkBXsHoA9oDGdt+VuntJQ6NuiiQKA8Kis9rxaqwSYksnOPg9vTILwuTgIGbtZ4KwGmFBX72vnKMrZ1U29vM5g6Vnblz7EDA+FHLtvK4Cce7Lxb3iyR4J4uAb+9YOe6yqA=
Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.280.20; Tue, 29 Sep 2015 05:20:32 +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.0280.017; Tue, 29 Sep 2015 05:20:32 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Jim Schaad <ietf@augustcellars.com>, 'Nat Sakimura' <sakimura@gmail.com>, 'John Bradley' <ve7jtb@ve7jtb.com>
Thread-Topic: [jose] JWS Unencoded Payload Option and the % character
Thread-Index: AdD6H04b8m9ACawFRC6C6gO928KtywALD5cAAAD4G4AACNB7AAAApMNw
Date: Tue, 29 Sep 2015 05:20:32 +0000
Message-ID: <BY2PR03MB442EF1C7BA1C3169E6267D6F54E0@BY2PR03MB442.namprd03.prod.outlook.com>
References: <BY2PR03MB442FB266B5B2BEE5DD46C3DF54F0@BY2PR03MB442.namprd03.prod.outlook.com> <341D0C88-312B-4B41-9964-129FE62C802B@ve7jtb.com> <CABzCy2DfpB+PO_aUYt3DPkVNOiVOOWDsby7ag5ULT7T9qn-2Pw@mail.gmail.com> <001501d0fa72$afad72a0$0f0857e0$@augustcellars.com>
In-Reply-To: <001501d0fa72$afad72a0$0f0857e0$@augustcellars.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: [50.47.89.201]
x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:f/AvlQbQYoBkxffJN8s9Z2phuAhObzWrI+dTBJUihUkyl4AzJ1q/Y0Fw7lbGkl9EJ9PmWmPaypvZlelrr0Ny0qyT3fVcU2jEhmKGHg/ViAR6x2Ge7dPEJqt2g1Gzq8w5Rp2tFrwFrMt+r+TUsHheLw==; 24:aIIeLjzVctmK4vtZCBCvnojp9hQ/lqn4+0z+YXLGQUVUB1dtSjFqnHp+p6JOfI3/RLrj/s85FoG6750wTi53hPSBioDqEZ/BmmtGVtRhbU8=; 20:M3SRdJgSmOIe3uOirBvQlrHvgVuNR+5tySBjPZPCXaQM/7nFXxH7s3XD3PJ20faNI2SU0LoWnYV8JkSxY4CuUw==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB444;
x-microsoft-antispam-prvs: <BY2PR03MB444D5866E85FE448F96E2D7F54E0@BY2PR03MB444.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)(8121501046)(520078)(5005006)(3002001)(61426024)(61427024); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444;
x-forefront-prvs: 0714841678
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51444003)(199003)(24454002)(377424004)(377454003)(189002)(92566002)(11100500001)(10290500002)(8990500004)(10090500001)(19617315012)(19580405001)(10400500002)(16236675004)(5005710100001)(5001960100002)(54356999)(40100003)(105586002)(19580395003)(81156007)(93886004)(122556002)(5001830100001)(76576001)(2950100001)(5003600100002)(4001540100001)(106356001)(5001860100001)(189998001)(2900100001)(5007970100001)(5001770100001)(46102003)(77156002)(102836002)(5004730100002)(19300405004)(62966003)(50986999)(19625215002)(68736005)(66066001)(64706001)(19609705001)(77096005)(15975445007)(97736004)(76176999)(74316001)(5890100001)(86612001)(5002640100001)(101416001)(575784001)(33656002)(86362001)(99286002)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX: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_BY2PR03MB442EF1C7BA1C3169E6267D6F54E0BY2PR03MB442namprd_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2015 05:20:32.0487 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444
Archived-At: <http://mailarchive.ietf.org/arch/msg/jose/EpUqV0XJAD9ZggPZJBljXeqy3uE>
Cc: "jose@ietf.org" <jose@ietf.org>, 'Vladimir Dzhuvinov' <vladimir@connect2id.com>
Subject: Re: [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, 29 Sep 2015 05:20:43 -0000

I don’t think that’s the case.  Short of cryptographic collisions occurring, every distinct JWS Payload string will have a distinct signature, both in the “b64”:true and “b64”:false cases.

It is true that if the application chooses to interpret % to mean form-urlencoding at the application level, then it is true that multiple application-level payloads with the same value but different encodings could have different corresponding JWS Payloads, and therefore different signatures.  For instance, the distinct JWS Payload values “A” and “%41” would have different signatures but would be decoded by some applications to the same application-level payload.

But that’s the opposite of what you’re describing, Jim.  This is a case of the same application-level payload having multiple different encodings, and therefore multiple possible JWS Payloads, and therefore multiple possible corresponding signatures – not multiple payloads with the same signature.

                                                            -- Mike

From: Jim Schaad [mailto:ietf@augustcellars.com]
Sent: Monday, September 28, 2015 9:53 PM
To: 'Nat Sakimura'; 'John Bradley'
Cc: Mike Jones; jose@ietf.org; 'Vladimir Dzhuvinov'
Subject: RE: [jose] JWS Unencoded Payload Option and the % character



From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Nat Sakimura
Sent: Monday, September 28, 2015 5:40 PM
To: John Bradley <ve7jtb@ve7jtb.com<mailto:ve7jtb@ve7jtb.com>>
Cc: Michael Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>>; jose@ietf.org<mailto:jose@ietf.org>; Vladimir Dzhuvinov <vladimir@connect2id.com<mailto:vladimir@connect2id.com>>
Subject: Re: [jose] JWS Unencoded Payload Option and the % character

Being able to express UTF-8 characters in %encoding is not particularly appealing since you cannot read the % encoded strings and it will be longer than base64url encoded strings, e.g. my name in

%encoding: %E5%B4%8E%E6%9D%91%E5%A4%8F%E5%BD%A6
b64url encoding: 5bSO5p2R5aSP5b2m

So, I suppose the use case for % encoding is in the case of predominantly US-ASCII characters payload with relatively small number of non-url safe characters. Like James, I feel a bit that it is a corner case, but since the semantics of "b64":false is that JW* layer takes the payload as-is and does not process it, why not let % be allowed and let the applications that use JW* decide what to do with it.

OR -- would it cause some security concerns?

[JLS] Minor security concern. If the application is not specified in the protected attributes, you now have two different strings which generate the same signature value depending on how you handle the % encoding.  I would prefer to say, don’t do this if you want to send via a URL.

Jim


Nat

2015-09-29 9:12 GMT+09:00 John Bradley <ve7jtb@ve7jtb.com<mailto:ve7jtb@ve7jtb.com>>:
Thinking about this a bit, I don’t think we should impose any special semantics on % in JW* processing.


It should be a part of the body that is opaque other than the constraints around character set.   If the result is sent via URL then it would be encoded and decoded at the applications risk when using b64 : false.

I think that is the simplest thing.   If they need to worry about encoding it then they should not be using b64: false.

If the application wants to receive a bunch of unicode characters that way then they can.  (They would have been better off b64 encoding them than URL but, different strokes.

John B.

On Sep 28, 2015, at 3:56 PM, Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>> wrote:

Thanks for your thoughtful comments, Vladimir.  The objective is to enable using unencoded payloads.

Thinking about it in terms of that goal, that actually eliminates choices 3, 4, and 5, because all require supporting a new payload encoding (x-www-form-urlencoded encoding), which defeats the purpose.

That leaves 1 (prohibit %) and 2 (allow % with no JWS-level processing performed).  Because 2 gives applications the flexibility to use % for application-level encoding if they choose, I’m now thinking that 2 is probably the more general choice than 1.  The only caveat is that applications would have to be aware that when passed in URLs, % would have to be represented as %25, since it is not URL-safe.

What do people think of the choice between 1 and 2?

                                                                -- Mike

From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Vladimir Dzhuvinov
Sent: Friday, September 25, 2015 8:29 AM
To: jose@ietf.org<mailto:jose@ietf.org>
Subject: Re: [jose] JWS Unencoded Payload Option and the % character

I read the entire discussion. I'm unsure how to rate the five choices. If I knew what the underlying objective is, it would be easier to make a technical judgment.

So what are we trying to achieve here?

Allow web apps to pass around such JWS messages more easily? Then URL-safety would matter. But how likely is this use case?

Or save apps additional processing?

Or keep the JWS payload as unmodified as possible?

Could this be left to the actual app to determine, and hence the most suitable encoding?

Vladimir
On 23.09.2015 05:41, Manger, James wrote:

Comments inline



From: Mike Jones [mailto:Michael.Jones@microsoft.com]

Sent: Wednesday, 23 September 2015 11:52 AM

To: Manger, James; jose@ietf.org<mailto:jose@ietf.org>

Subject: RE: JWS Unencoded Payload Option and the % character



Writing as an individual, your possible option 5 has the following downsides, at least as I see it:



(a) It doesn't represent the payload in unencoded form, which was one of the primary motivations for this option.



The payload can be unencoded in the JSON Serialization and when detached - those are the motivations; not an unencoded form in a non-detached Compact Serialization.



(b) It's not self-consistent, since the "b64":false treatment of detached payloads requires them to be unencoded whereas the treatment of attached payloads requires the opposite.



It is consistent in always treating the 2nd part of a JWS as a base64url-encoded payload. The consistency of handling detached payloads depends on the API you offer. If your API expects "detachedSigningInput" it will depend on "b64" (ie be inconsistent). However, if your API expects "detachedRawPayload" it does not depend on "b64" (ie will be consistent). The latter makes more sense to me: RawPayload is something the call cares about; SigningInput is an internal detail.



(c) It breaks the invariant that the JWS Signing Input is simply the contents of the JWS prior to the second period - which is one of the simple things about JWSs using the compact serialization.



That is not a particularly useful invariant. It is not as though a signature verification sub-system can treat a "JWS prior to the 2nd period" as a blob. It still needs to split on the period, base64url-decode the 1st part, JSON-parse it, then look at the algorithm & key id, before doing any verification.



And I don't see any particular upside.  It's just a standard JWS with an unnecessarily different JWS Signing Input computation but the same payload representation and an extra field in the encoded header representation.  Better to just use a normal JWS, given the choice between that and 5.



Indeed, "b64":false is unnecessary if you are using non-detached Compact Serializations. The upside is for large payloads that are detached or use the JSON Serialization.



--

James Manger





From: Manger, James [mailto:James.H.Manger@team.telstra.com]

Sent: Tuesday, September 22, 2015 6:05 PM

To: Mike Jones; jose@ietf.org<mailto:jose@ietf.org><mailto:jose@ietf.org><mailto:jose@ietf.org>

Subject: RE: JWS Unencoded Payload Option and the % character



Or a 5th option:



5. "b64":false affects the Signing Input, but not the Compact Serialization (which remains a URL-safe string for any Payload). The 2nd dot-separated component of the Compact Serialization is always BASE64URL(JWS Payload); a '%' in the Payload causes no issues, neither does a '.' nor any other octet.



The only corner case option 5 prevents is when you have: (1) a large payload; (2) that doesn't contain octet 0x2E '.'; (3) probably doesn't contain any of the other 190 octet values not in the URL-safe set; (4) you want to use the Compact Serialization; (5) you don't want to use a detached payload; and (6) you cannot tolerate the additional 33% space overhead from base64url-encoding the Payload. I don't think this is a corner case anyone is interested in.



--

James Manger



From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones

Sent: Wednesday, 23 September 2015 8:23 AM

To: jose@ietf.org<mailto:jose@ietf.org><mailto:jose@ietf.org><mailto:jose@ietf.org>

Subject: [jose] JWS Unencoded Payload Option and the % character



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<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-jose-jws-signing-input-options-02%23section-5.2&data=01%7c01%7cMichael.Jones%40microsoft.com%7cd92fa2633b06424901d008d2c88a2b60%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=5kmTYBBQb9yzGWZ2%2fYMWhaAblCmHmWw2DpodZC%2fTW%2fE%3d><https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-jose-jws-signing-input-options-02%23section-5.2&data=01%7c01%7cMichael.Jones%40microsoft.com%7c6fbe6ca0c59048e2d97808d2c3b2f875%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tKBYn8mzSjJkpYNPR5JhiSqDrg8n9<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-jose-jws-signing-input-options-02%23section-5.2&data=01%7c01%7cMichael.Jones%40microsoft.com%7c6fbe6ca0c59048e2d97808d2c3b2f875%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tKBYn8mzSjJkpYNPR5JhiSqDrg8n9MVFrV28pv%2fQGW8%3d>

 M<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-jose-jws-signing-input-options-02%23section-5.2&data=01%7c01%7cMichael.Jones%40microsoft.com%7c6fbe6ca0c59048e2d97808d2c3b2f875%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tKBYn8mzSjJkpYNPR5JhiSqDrg8n9MVFrV28pv%2fQGW8%3d>

VFrV28pv%2fQGW8%3d><https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-jose-jws-signing-input-options-02%23section-5.2&data=01%7c01%7cMichael.Jones%40microsoft.com%7c6fbe6ca0c59048e2d97808d2c3b2f875%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tKBYn8mzSjJkpYNPR5JhiSqDrg8n9MVFrV28pv%2fQGW8%3d>.  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-<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2fjose%2fcurrent%2fmsg05257.html&data=01%7c01%7cMichael.Jones%40microsoft.com%7cd92fa2633b06424901d008d2c88a2b60%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=wTuR2jJFemLU%2fdbhz6XJojahNbpT8NowFlDZO7gJabs%3d>

 a<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2fjose%2fcurrent%2fmsg05257.html&data=01%7c01%7cMichael.Jones%40microsoft.com%7cd92fa2633b06424901d008d2c88a2b60%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=wTuR2jJFemLU%2fdbhz6XJojahNbpT8NowFlDZO7gJabs%3d>

rchive/web/jose/current/msg05257.html<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2fjose%2fcurrent%2fmsg05257.html&data=01%7c01%7cMichael.Jones%40microsoft.com%7cd92fa2633b06424901d008d2c88a2b60%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=wTuR2jJFemLU%2fdbhz6XJojahNbpT8NowFlDZO7gJabs%3d><https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2fjose%2fcurrent%2fmsg05257.html&data=01%7c01%7cMichael.Jones%40microsoft.com%7c6fbe6ca0c59048e2d97808d2c3b2f875%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2o5YW1FQaTiawjuFSlY%2fizoWdF7jjTCq3QOgTW%2fuQ4Y%3d><https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2fjose%2fcurrent%2fmsg05257.html&data=01%7c01%7cMichael.Jones%40microsoft.com%7c6fbe6ca0c59048e2d97808d2c3b2f875%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2o5YW1FQaTiawjuFSlY%2fizoWdF7jjTCq3QOgTW%2fuQ4Y%3d>.



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<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-jose-jws-signing-input-options-02%23section-5.3&data=01%7c01%7cMichael.Jones%40microsoft.com%7cd92fa2633b06424901d008d2c88a2b60%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=G%2flXM7nsiRzPH52gxribIvRCcqTpkrUH7ic0yyLaTVM%3d><https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-jose-jws-signing-input-options-02%23section-5.3&data=01%7c01%7cMichael.Jones%40microsoft.com%7c6fbe6ca0c59048e2d97808d2c3b2f875%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=wb%2fq6RyH2Oy1Km8PCIJmcDyz5gsQqBISJMKDvIy%2bIJg%3d><https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ie%20tf.org%2fhtml%2fdraft-ietf-jose-jws-signing-input-options-02%23section-5.3&data=01%7c01%7cMichael.Jones%40microsoft.com%7c6fbe6ca0c59048e2d97808d2c3b2f875%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=wb%2fq6RyH2Oy1Km8PCIJmcDyz5gsQqBISJMKDvIy%2bIJg%3d>, 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<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2fjose%2fcurrent%2fmsg05259.html&data=01%7c01%7cMichael.Jones%40microsoft.com%7cd92fa2633b06424901d008d2c88a2b60%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=PvOFU5OJLutVU6g6AlPOQwdC3KCMLy%2bZZLqZ8hV4JzI%3d><https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2fjose%2fcurrent%2fmsg05259.html&data=01%7c01%7cMichael.Jones%40microsoft.com%7c6fbe6ca0c59048e2d97808d2c3b2f875%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=NR%2fLeoyOPWOoJO9%2bZsgrutgVAGBxLYZttVWQ8CPdG14%3d>.



How would working group members like to see us use (or not use) '%'?



                                                                -- Mike






_______________________________________________

jose mailing list

jose@ietf.org<mailto:jose@ietf.org>

https://www.ietf.org/mailman/listinfo/jose<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fjose&data=01%7c01%7cMichael.Jones%40microsoft.com%7cd92fa2633b06424901d008d2c88a2b60%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=XzeUNNpUk1z4%2bk3xgfF7nBR6uet97Bu4vS3D6VQpB0A%3d>


--

Vladimir Dzhuvinov :: vladimir@connect2id.com<mailto:vladimir@connect2id.com>
_______________________________________________
jose mailing list
jose@ietf.org<mailto:jose@ietf.org>
https://www.ietf.org/mailman/listinfo/jose<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fjose&data=01%7c01%7cMichael.Jones%40microsoft.com%7cd92fa2633b06424901d008d2c88a2b60%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=XzeUNNpUk1z4%2bk3xgfF7nBR6uet97Bu4vS3D6VQpB0A%3d>


_______________________________________________
jose mailing list
jose@ietf.org<mailto:jose@ietf.org>
https://www.ietf.org/mailman/listinfo/jose<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fjose&data=01%7c01%7cMichael.Jones%40microsoft.com%7cd92fa2633b06424901d008d2c88a2b60%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=XzeUNNpUk1z4%2bk3xgfF7nBR6uet97Bu4vS3D6VQpB0A%3d>



--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fnat.sakimura.org%2f&data=01%7c01%7cMichael.Jones%40microsoft.com%7cd92fa2633b06424901d008d2c88a2b60%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=0iilLdVJsPklaGXW8iHa3FIzXIzkbGvK70C6MR455V0%3d>
@_nat_en