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]<mailto:[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]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
