Re: [jose] Using Jose as an encrypted document container.

[Phillip Hallam-Baker <[e-mail]>]

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 <[e-mail]>
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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/jose
>>
>>
>
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
>