Hi,
JWS JSON can be streamed on the write side, we support it (though I
haven't looked yet at streaming JWE JSON). I recall asking about a
possible streaming support on the read side too but for JWS/JWE JSON the
order of the elements is not fixed so streaming on the read side would
be difficult to achieve.
Base64 encoding can be disabled for JWS JSON.
Cheers, Sergey
On 28/12/16 21:33, Phillip Hallam-Baker wrote:
I am currently looking at using Jose as the basis for a CMS-like
document container. This is to support the use of proxy-re-encryption to
enable true end-to-end Web security. By which I mean that the content on
the site is encrypted.
To meet these needs I need to modify Jose to support the following
additional requirements that the RFCs currently don't.
1) Single pass processing for encoding and decoding operations.
1a) Bounded state
1b) Support streaming, i.e. length not known in advance
2) Reduce complexity and number of options.
3) Efficient encoding of bodies, i.e. no Base64 overhead.
On the single pass processing, the main change I have had to make is to
add in an unprotected header to announce the digest function to be used
for the signature calculation:
"unprotected": { "dig": "S512"}
This is straightforward but requires that a document that is signed with
multiple keys be signed using a single digest. So it might well be
better to have two entries for signatures, one at the start listing the
set of signing keys and then a second one at the end with the actual values.
To reduce complexity, I am using UDF identifiers as the sole key
identifier mechanism. Using a single identifier for keys at every stage
in a system really simplifies everything. Using fingerprints of the
public key guarantees each key has one identifier.
I am also removing as many options as possible. Having a 'simplified'
way to do something only makes the code more complex because now there
are two choices to encode rather than one.
The big problem I am having is with avoiding Base64 encoding of the
message body. There are two approaches I am considering.
1) Use JSON-B
The simplest way to avoid the Base64 overhead of JSON is to extend the
JSON encoding to add code points for length-data encoding of binary data
and strings. This is all that JSON-B is. Regular JSON in UTF8 only ever
uses bytes with values > 127 inside strings. So all those code points
are available as extension codes.
Since JSON-B is a strict superset of JSON, it is only necessary to
implement one decoder that will accept either as input. This greatly
simplifies negotiation of encodings. It is only necessary to advertise
the encodings that are accepted, a sender does not need to tag content
to specify what was sent.
The document is encoded as an array entry:
[ { JSON-Header } , [ <length> <DataChunk> ] + , {JSON-Trailer} ]
Pro: Simple, easy to implement if you have the tools
Con: Everyone needs to implement the new encoder/decoder
2) Use JSON-Log format approach
The second approach is to split the document container into three parts
and use RFC7464 record separators to delimit the boundaries, thus:
<RS> JSON-Header <LF>
[<length> <DataChunk> ] +
<RS> JSON-Trailer<LF>
In this scheme the header and trailer blocks are mandatory and there
must be at least one entry in the body.
Pro: Can use unmodified JSON encoder/decoder
Con: Have to wrap the result in something that isn't at all like JSON.
One issue that might tip the choice is that if you have comments in a
chat log, or the like, you might have a sequence of comments encrypted
to a common group key. This would enable true end-to-end encrypted chat
and other asynchronous messaging formats.
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
