I think you've misunderstood the proposal. It's not that the field will be
unencoded, it's that it will be encoded as a UTF-8 string instead of a
base64 string.
OLD: (json) --> UTF-8 --> base64
NEW: (json) --> UTF-8
OLD: { protected: "eyJhbGciOiJSUzI1NiJ9Cg==" }
NEW: { protected: "{\"alg\":\"RS256\"}" }
Now, there might still be a problem with that, because JSON strings aren't
canonical. In the example above, the quote characters could also have been
presented as "\u0022". So if some JSON re-processor were to change the
encoding ot the string, it would break the signature. However, that's also
a problem for the base64-encoded version ("a" vs. "\u0061").
On Mon, Jun 10, 2013 at 12:38 PM, Mike Jones <[email protected]>wrote:
> The problem with this suggested change is that it requires unencoded
> JSON objects to be transmitted with no transformations whatsoever, whereas
> the problems with this assumption are well known. For starters, on
> UNIX-based systems, newlines are typically represented by a bare LF
> character, whereas on DOS-based systems, newlines are typically represented
> by a CRLF pair. In transmission, many systems, including mail agents tend
> to convert newlines to the system’s normal format. This would break these
> JOSE objects.****
>
> ** **
>
> Some agents wrap lines after a certain length. Particularly when being
> transmitted in HTML or XML, many systems replace two or more consecutive
> spaces with a single space. Others replace two or more spaces with a
> single space and N-1 non-breaking space characters. I could go on…****
>
> ** **
>
> I appreciate the attempt to make things appear to be more uniform and
> readable, but the CRLF/LF problems alone are enough to make this a
> non-starter.****
>
> ** **
>
> Best
> wishes,****
>
> -- Mike***
> *
>
> ** **
>
> *From:* [email protected] [mailto:[email protected]] *On Behalf
> Of *Richard Barnes
> *Sent:* Monday, June 10, 2013 9:29 AM
> *To:* Jim Schaad
> *Cc:* [email protected]
> *Subject:* Re: [jose] Possible change to protected field****
>
> ** **
>
> This sounds like a fine idea to me. It saves space and makes the JSON
> format more human-readable. It actually makes kind of a nice analogy to
> ASN.1, namely use of OCTET STRING to encapsulate more DER content.****
>
> ** **
>
> The compact serialization can continue to base64url-encode that field, so
> it would not be a breaking change for that serialization.****
>
> ** **
>
> --Richard****
>
> ** **
>
> On Mon, Jun 10, 2013 at 1:46 AM, Jim Schaad <[email protected]>
> wrote:****
>
> <no hat>****
>
> ****
>
> I am trying to figure out if I am missing something. This is not yet a
> formal proposal to actual change the document.****
>
> ****
>
> I was thinking about proposing that we make a change to the content of the
> protected field in the JWS JSON serialization format. If we encoded this
> as a UTF8 string rather than the base64url encoded UTF8 string, then the
> content would be smaller. The computation of the signature would be
> unchanged in that it would still be computed over the base64url encoded
> string. I believe that the conversion from the UTF8 string to the
> base64url encoded UTF8 string is a deterministic encoding and thus would
> not generate any problems from that point.****
>
> ****
>
> At this point I and trying to figure out if I missed anything that would
> preclude this from working. I am not worried about how hard or easy it
> would be to do, just if it is even possible.****
>
> ****
>
> Jim****
>
> ****
>
>
> _______________________________________________
> jose mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/jose****
>
> ** **
>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
