Re: [jose] draft-jones-jose-jws-signing-input-options 00

Sergey Beryozkin <sberyozkin@gmail.com> Mon, 14 September 2015 10:02 UTC

To: Mike Jones <Michael.Jones@microsoft.com>, Jim Schaad <ietf@augustcellars.com>, "draft-jones-jose-jws-signing-input-options@tools.ietf.org" <draft-jones-jose-jws-signing-input-options@tools.ietf.org>
References: <041c01d0cda1$16b7fe10$4427fa30$@augustcellars.com> <BY2PR03MB442CFD69CA29CD1AB023D2BF5700@BY2PR03MB442.namprd03.prod.outlook.com> <002f01d0d33b$e43febf0$acbfc3d0$@augustcellars.com> <BY2PR03MB4429E9046EA98DA60846EECF55D0@BY2PR03MB442.namprd03.prod.outlook.com>
From: Sergey Beryozkin <sberyozkin@gmail.com>
Message-ID: <55F69B27.2050102@gmail.com>
Date: Mon, 14 Sep 2015 11:02:15 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <BY2PR03MB4429E9046EA98DA60846EECF55D0@BY2PR03MB442.namprd03.prod.outlook.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/jose/PkhQkjZuKPCUgJ6OMtVfrKocpq8>
Cc: "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] draft-jones-jose-jws-signing-input-options 00
Precedence: list

Hi Mike, Jim, All,

Only one comment,

>  > Are % characters URL safe?  What if my content for compact is %24.02
>
>  > (or whatever the correct code for $ is).  Would I remove that
> serialization as well?
>
> That's a good question.  More to the point, would we want to consider
> allowing the period to also be escaped by representing "$.02" as
> "%24%2E02", rendering the payload URL-safe and parseable.  It would mean
> that we would end up defining that RFC 3986 percent-encoding be used for
> unencoded JWS Compact Serialization payloads, when needed.
>
> What do others think about whether we should go there or not?  To me, it
> seems like a worthwhile experiment to at least write it down and see
> what we think of it.
>
> Mike> Per RFC 3986, % is not URL-safe (although is it used for
> www-form-url-encoding of characters as %<hex><hex>).  If we allow %, it
> opens up a Pandora’s box of a bunch of choices we need to make, as well
> as possibilities.  I’ll send a message specifically about those choices
> and possibilities to the working group (but not tonight).
>
Sorry if I just missed the point, but IMHO processing the payload should 
be left up to the application which gets it from a JWS.
I.e,

"$.02"
"%24%2E02"

are two different representations for the purpose of signing/validating 
them. "b64" does not only help making JWS JSON payload easier to 
understand by humans (in logs or tcp traces) but is also an optimization 
(no need to base64-encode). Having to check every character in such a 
payload to make sure '.' is percent-encoded kind makes this optimization 
much less effective, IMHO. Besides, JWS JSON are not meant to be URI 
safe payloads, I recall reading about it.
May be it is more useful for detached payloads...

Thanks, Sergey

[jose] draft-jones-jose-jws-signing-input-options… Jim Schaad
[jose] draft-jones-jose-jws-signing-input-options… Anders Rundgren
Re: [jose] draft-jones-jose-jws-signing-input-opt… Nat Sakimura
Re: [jose] draft-jones-jose-jws-signing-input-opt… Mike Jones
Re: [jose] draft-jones-jose-jws-signing-input-opt… Jim Schaad
Re: [jose] draft-jones-jose-jws-signing-input-opt… Mike Jones
Re: [jose] draft-jones-jose-jws-signing-input-opt… Mike Jones
Re: [jose] draft-jones-jose-jws-signing-input-opt… Sergey Beryozkin
Re: [jose] draft-jones-jose-jws-signing-input-opt… Jim Schaad