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

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 28 Dec 2016 16:33:50 -0500

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.

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 29 Dec 2016 13:33:41 +0000

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.
>
> 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:
>
> 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.
>
> 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 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>
> In this scheme the header and trailer blocks are mandatory and there
> must be at least one entry in the body.
>
> 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-masked]
> https://www.ietf.org/mailman/listinfo/jose
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 29 Dec 2016 14:26:43 -0500

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-masked]>
wrote:

> 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.
>