[jose] order of step for encryption. JWE section 5
<Axel.Nennker@telekom.de> Sun, 05 August 2012 06:54 UTC
Return-Path: <Axel.Nennker@telekom.de>
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 213BC21F86D6 for <jose@ietfa.amsl.com>; Sat, 4 Aug 2012 23:54:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level:
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWrNrFjmG3xi for <jose@ietfa.amsl.com>; Sat, 4 Aug 2012 23:54:38 -0700 (PDT)
Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF6F21F8610 for <jose@ietf.org>; Sat, 4 Aug 2012 23:54:38 -0700 (PDT)
Received: from he101250.emea1.cds.t-internal.com ([10.125.92.153]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 05 Aug 2012 08:54:36 +0200
Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.25]) by HE101250.emea1.cds.t-internal.com ([fe80::e439:4046:12e2:e37%15]) with mapi; Sun, 5 Aug 2012 08:54:36 +0200
From: Axel.Nennker@telekom.de
To: jose@ietf.org
Date: Sun, 05 Aug 2012 08:54:31 +0200
Thread-Topic: order of step for encryption. JWE section 5
Thread-Index: Ac1y1wQPutAF2XyLQPOP3bTnOMCRMw==
Message-ID: <CE8995AB5D178F44A2154F5C9A97CAF402517DB698C5@HE111541.emea1.cds.t-internal.com>
Accept-Language: de-DE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: de-DE
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [jose] order of step for encryption. JWE section 5
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Sun, 05 Aug 2012 06:54:39 -0000
Hi, I have two issues with section 5 of http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-05.html 1) I would prefer it if the order of the steps 1 and 2 were reversed in section 5. Currently we have: Message Encryption The message encryption process is as follows. The order of the steps is not significant in cases where there are no dependencies between the inputs and outputs of the steps. 1. When key agreement is employed, use the key agreement algorithm to compute the value of the agreed upon key. When key agreement without key wrapping is employed, let the Content Master Key (CMK) be the agreed upon key. When key agreement with key wrapping is employed, the agreed upon key will be used to wrap the CMK. 2. When key wrapping, key encryption, or key agreement with key wrapping are employed, generate a random Content Master Key (CMK). See RFC 4086 [RFC4086] for considerations on generating random values. The CMK MUST have a length equal to that of the larger of the required encryption and integrity keys. Step 1 refers to the CMK that might be randomly created in step 2. I think it is better to have the CMK generation . 2) I find the text of the current step 1 confusing. 2a) The first sentence is nearly a tautology 2b) All sentences begin with When but the sentences two and three are alternative choices and the first is not. 2c) Does "When key agreement without key wrapping is employed, let the Content Master Key (CMK) be the agreed upon key." make sense? What is the key agreement good for then? Should this read: "When key agreement without key wrapping is employed, let the agreed upon key be the CMK" ? There SHOULD be some randomness e.g. through the epk. Could we structure these steps more? I) determine the CEK, generate random values like IVs and epks II) build the jweHeaderSegment (e.g. put the IV there) III) build the jweKeySegment (e.g. key wrapping) IV) build the jweCryptoSegment V) build the jweIntegritySegment VI) base64url encode and concatenate the segments
- [jose] order of step for encryption. JWE section 5 Axel.Nennker
- Re: [jose] order of step for encryption. JWE sect… Mike Jones
- Re: [jose] order of step for encryption. JWE sect… Axel.Nennker
- Re: [jose] order of step for encryption. JWE sect… Jim Schaad
- Re: [jose] order of step for encryption. JWE sect… Mike Jones
- Re: [jose] order of step for encryption. JWE sect… Mike Jones