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.
(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.
(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.
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.
-- Mike
From: Manger, James [mailto:[email protected]]
Sent: Tuesday, September 22, 2015 6:05 PM
To: Mike Jones; [email protected]
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:[email protected]] On Behalf Of Mike Jones
Sent: Wednesday, 23 September 2015 8:23 AM
To: [email protected]<mailto:[email protected]>
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%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-archive/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%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%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%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
[email protected]
https://www.ietf.org/mailman/listinfo/jose
