Hi Mike,
On 2020-07-10 22:21, Mike Jones wrote:
I must admit, I was surprised to see this RFC, because very little discussion
of it happened on the JOSE mailing list. The last mention I can see of it was
in February 2019 - the same time you were proposing to take this to
SecDispatch. I never heard of it again after that.
Well, it was mentioned that a separate mailing-list had been created for discussing the
I-D. This was done to not "spam" the JOSE list with things that were of no
interest. There were a few but useful topics discussed there which indeed are reflected
by the RFC.
So that any future related efforts have an opportunity for widespread review,
particularly if they are JOSE related, I'd request that you and others working
on them also post drafts to the JOSE mailing list, even if you're working in
the Independent Stream.
Sure. If we stick to "features", the documents referred to should give you a
pretty good idea of what to expect. https://mobilepki.org/jws-jcs is built directly on
top of JOSE, while the other schemes [currently] are not.
With respect to JOSE, it seems that right now, the biggest challenge for the IETF is dealing with
topic I presented in a SEC-DISPATCH session at IETF-104, that is, "Signed HTTP Requests".
Due to the lack of progress in this space, ETSI have recently published their take on the matter
as well. ETSI are targeting Open Banking so it may impact the entire "market".
FWIW, I have not given up this subject because "Signed and Serializable HTTP requests using JSON"
seems be a unique feature. Serialization enables counter-signatures which is a core component of a universal
payment authorization system known as "Saturn". For this particular system, counter-signatures are
also used for simplifying state-holding and referencing by embedding preceding related messages (aka
"Russian Doll"). Counter-signatures are also useful for digital contracts in block-chain systems.
There are things I would have commented on in JCS if I'd seen intermediate
drafts before it became an RFC. (For instance, I would have asked for explicit
serialization instructions for the one ASCII control character not in the range
0x00-0x1F - 0x7F (DEL).)
Serialization of JSON tokens follows ECMAScript to 100% so the string
serialization algorithm is essentially just a copy.
Thanx
Anders
Thanks,
-- Mike
-----Original Message-----
From: jose <[email protected]> On Behalf Of Anders Rundgren
Sent: Friday, July 10, 2020 11:41 AM
To: [email protected]
Subject: [jose] Beyond RFC 8785 (JSON Canonicalization Scheme)
After virtually eons of time https://www.rfc-editor.org/rfc/rfc8785 has finally
been published.
It wouldn't have happened without the input from the IETF community!
Since canonicalization in itself is fairly useless, there are several
additional work-items building on JCS (RFC 8785) in the pipe-line:
On-line demo/test using JWS: https://mobilepki.org/jws-jcs On-line demo/test using an
"unwrapped" JWS called JSON Signature Format (JSF):
https://mobilepki.org/jsf-lab
A real-world implementation by OWASP using JSF:
https://cyclonedx.org/use-cases/#authenticity
There is also an "unwrapped" JWE called JSON Encryption Format (JEF), currently
published as an HTML document: https://cyberphone.github.io/doc/security/jef.html
If anybody out there would be interested in "RFC-ing" JWS-JCS, JSF, or JEF,
please drop me a line.
The current plan is publishing the additional RFCs using the Independent
Stream, rather than as IETF standards.
Anders
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
