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

On 2015-09-23 00:23, Mike Jones wrote:
> 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:

Mike,

This is a question of purely theoretic value since nobody (in their right mind)
would consider using the non-detached payload option when it only takes 10-
150 lines of additional code making a JSON serializer "crypto-capable" allowing
you to to use "Signed JSON" as well as do other pretty cool crypto-stuff like
the "requestHash" construct in

    http://webpki.org/papers/payments/webpay-4-corner-flow.html#p8

which simply put is undoable using current JOSE standards.

For detached signatures the document is fine "as is".

Anders

>
> 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 mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>