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

Sergey Beryozkin <sberyozkin@gmail.com> Thu, 29 December 2016 13:33 UTC

Return-Path: <sberyozkin@gmail.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6D71293F8 for <jose@ietfa.amsl.com>; Thu, 29 Dec 2016 05:33:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAKl1Km7se0k for <jose@ietfa.amsl.com>; Thu, 29 Dec 2016 05:33:45 -0800 (PST)
Received: from mail-wj0-x22f.google.com (mail-wj0-x22f.google.com [IPv6:2a00:1450:400c:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FE80124281 for <jose@ietf.org>; Thu, 29 Dec 2016 05:33:44 -0800 (PST)
Received: by mail-wj0-x22f.google.com with SMTP id c11so153326451wjx.3 for <jose@ietf.org>; Thu, 29 Dec 2016 05:33:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=qGF8ZBqcTqIOp1pHfNrhuJ9Mo1Om1dnNHWq2BvoyWBY=; b=VxWm9g6YVDQZqJkEbjTkjwzF4gGWPlEenAgGiWeGyApmi7QUmv+3j+4VsYX3WFwwIR pFENuG/HRTUPuu2zBTG6ghijREZ0oS5A+bP8pKWNrjutcBfGSgnRL1SguFQHditcBRy9 fo4GGzgfj0jUHJReVCP3iiXM8PdBk9u8EVUBwfKeZy5wO7EyvVsTVlyxJjsCh9mZIPbY 9Tz1KyeHh72ODzJ8RqXo9jR/sLvA3Voy9+KfY6rvX7CaVmh2obZUL8rD7IY0+gpR1M3m AOLjw+sSTrCrj8iiMX70aR/Hw6hLlY96e0A0KX7g2uSVJP6/hieiU7Jv108sKp3UlOhH nKsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=qGF8ZBqcTqIOp1pHfNrhuJ9Mo1Om1dnNHWq2BvoyWBY=; b=c1oKHeUcroSNEwV7qks0uE8e+KCeXTI7WvcWBjgyVXYSYqlQamTzhCRvj6eS9T0w8m AsPE4Z2gISoP9FTbRZOuK/3SbDcBPOVadpku1KyrErkRuuK7q9XZIVB41l+LjiEKI325 nqIlJB442h8vdpHbzpUXntaGKdHrMph1sc6V6IGocfyr/477y9svYu2joyX+vF/7WWRA n7Fy3GmK4eAv20q8t3PChq8KJMHcrx86wsO8hhe5BtzgB4SgXcVdnbMGBW4MiDi15SCb qHkmRbL7LaaXvEeQMGyuoSYKt2lQvvv3cYjtjR+FeWZSkP/cb9QHLgMSqNCy+Ib/zcx7 kVJw==
X-Gm-Message-State: AIkVDXLpIfQL07Vz+IW9PVGGIx5I4hI9vS4a+fuysqJWqxglxuadxvNByyDlv3FUsTSovA==
X-Received: by 10.194.124.100 with SMTP id mh4mr41414369wjb.154.1483018422876; Thu, 29 Dec 2016 05:33:42 -0800 (PST)
Received: from [192.168.2.7] ([79.97.121.181]) by smtp.googlemail.com with ESMTPSA id t194sm46160746wmd.1.2016.12.29.05.33.42 for <jose@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Dec 2016 05:33:42 -0800 (PST)
To: jose@ietf.org
References: <CAMm+Lwiq-pJb3n=_y_o6fbszhvrbeRXTYKCVN6GTv+uOfxSQsw@mail.gmail.com>
From: Sergey Beryozkin <sberyozkin@gmail.com>
Message-ID: <fba72d5e-8e55-ee9d-a17d-ca2cc3b92112@gmail.com>
Date: Thu, 29 Dec 2016 13:33:41 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <CAMm+Lwiq-pJb3n=_y_o6fbszhvrbeRXTYKCVN6GTv+uOfxSQsw@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/lxWm2qTQpVPD9ps9qBfWGF79-8k>
Subject: Re: [jose] Using Jose as an encrypted document container.
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Dec 2016 13:33:46 -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.
>
> 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
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>