Mike,
I can dispose of the CRLF question quite simply. I have not removed the
UTF8 string from the protected field so all CRLF characters (along with a
number of others) will be escaped so they will not be transformed.
It would still be
{"protected":"---UTF8 encoded string ---"}
Rather than
{"protected":"--- Base64 URL encoded ( -- UTF8 encoded string -- ) ---" }
There are a number of other questions that do come into play that you did
raise however.
The first would be space folding - It has been my experience that this is
normally the XML parser that does it rather than things in transit. There
will always be a problem with things in the middle that could possibly
change things with this approach. It is something that I need to be looked
at and think about.
If we have a line wrapping issue, this is going to be a problem with JSON
parsers today. It is not legal to have any of the CRLF characters inside of
a string in JSON according to the current ABNF in the document. I think
this may already cause parsers to go boom in some cases. If this is going
to be a real issue then we probably need to start dealing with it sooner
rather than later.
Jim
From: Mike Jones [mailto:[email protected]]
Sent: Monday, June 10, 2013 9:39 AM
To: Richard Barnes; Jim Schaad
Cc: [email protected]
Subject: RE: [jose] Possible change to protected field
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
