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
