On 2020-07-10 22:43, Carsten Bormann wrote:
On 2020-07-10, at 22:21, Mike Jones
<[email protected]> wrote:
There are things I would have commented on in JCS
Much of what discussion we had happened on the JSON mailing list.
There is a map (JSON object) key ordering mechanism in there for which I only
have the word “sick”, and this was commented on the JSON mailing list [1] (in
slightly more elaborate wording). That “feature” is still in there. No
comment.
Hi Carsten,
The chosen solution may not be "perfect" but it has no proven [1] downsides either unless
JSON would be fundamentally revised or the Unicode consortium would suddenly pull the plug on
UTF-16. The chance/risk for that to happen seems minimal. Therefore JCS simply followed its
JavaScript origins. An additional problem is that there is no consensus what the "right"
solution is; some people advocate for UTF-8, while other camps insist that sorting must be based on
Unicode.
However, if you stick to best practices for JSON keys, like spelled out in JWK
Thumbprint (RFC 7638), it doesn't even matter if you sort on UTF-8, UTF-16, or
Unicode!
Could we for fairness sake, take a peek at the existing JOSE standards from a "perfection" point of view? All
"blob" contents are coded in base64url with "x5c" as sole exception. Although I know why, the (not
mentioned) rationale is actually pretty weak. Calling it "sick" is though taking things way too far since it obviously
has no consequences except for JOSE implementers. The "none" algorithm is another non-obvious JOSE ingredient.
A JCS implementation recently published on the JSON list required less than 200
lines of GO code. XML canonicalization including schema support (for dealing
with default values) could easily reach 10000 lines.
Anyway, the immediate issue the former JSON members may need to focus on is "Signed
HTTP Requests". I'm there as well :-) Maybe we meet again at some future IETF!
Best
Anders
1] https://mailarchive.ietf.org/arch/msg/json/6VJlTUpKUCXU6gKN0eg3i-GADtw/
The disturbing part is that people are now running ahead and are trying to do
run-arounds around the JOSE format based on the old XMLDSig thinking. I
certainly suspected that was the point of JCS, but it plaid no role in the IESG
conflict review for this independent submission — I have seen very inconsistent
levels of attention in IESG to considerations about how a spec will actually be
used over time.
Grüße, Carsten
[1]: <https://mailarchive.ietf.org/arch/msg/json/IePAqXNJ3On_mSRbJGn6zYt-HRs>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
