Well 'can be' is one thing. There has to be one single way to do a thing to have a standard.
I want streaming on the read and write sides which means some sort of sequence being enforced. That could mean using the log format or extending JSON. Right now, I an tending towards extending the encoding. On Thu, Dec 29, 2016 at 8:33 AM, Sergey Beryozkin <[email protected]> wrote: > 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 >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
