Re: [jose] Comments on draft-miller-jose-jwe-protected-jwk-00

"Matt Miller (mamille2)" <> Tue, 19 February 2013 15:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 70AE121F8D08 for <>; Tue, 19 Feb 2013 07:32:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.516
X-Spam-Status: No, score=-10.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Gng-OhRZkJM6 for <>; Tue, 19 Feb 2013 07:32:07 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E197821F8CF4 for <>; Tue, 19 Feb 2013 07:32:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3556; q=dns/txt; s=iport; t=1361287927; x=1362497527; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jRc8AIcOiAQA3d6ybdQOZc/qJbjswyYKeaDS7yNllmQ=; b=O1gcUQwMW4+KUCBu7PmE0gfgij99R7r07xTjioXJ37YLGi5USaET/OSm VBDo7v/Wkd7SWSIbXlC1QPxWicqBiDUqw9JACJXMv1Bpb80TnPac3TISr mW1gAONZ+DPhBuC/aoAYabpvGBZHuVc/54n1fb6ckthGNLiLDBEjhkmmK U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAImZI1GtJV2Y/2dsb2JhbABFwD+BChZzgh8BAQEDATo/BQsCAQgOFA4GEDIlAQEEDgUIiAQGsDuQH41IgRMCMQcYgkdhA6cDgweBaj0
X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; d="scan'208";a="175750980"
Received: from ([]) by with ESMTP; 19 Feb 2013 15:32:06 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r1JFW6fv024794 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Feb 2013 15:32:06 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 09:32:05 -0600
From: "Matt Miller (mamille2)" <>
To: Jim Schaad <>
Thread-Topic: [jose] Comments on draft-miller-jose-jwe-protected-jwk-00
Thread-Index: Ac4Lzeuu/g0gyocOQPi1CIMUJXbUSgDGqOgA
Date: Tue, 19 Feb 2013 15:32:04 +0000
Message-ID: <>
References: <047101ce0be3$0620aed0$12620c70$>
In-Reply-To: <047101ce0be3$0620aed0$12620c70$>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<>" <>, "<>" <>
Subject: Re: [jose] Comments on draft-miller-jose-jwe-protected-jwk-00
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 Feb 2013 15:32:08 -0000

Thanks very much for the comments, Jim.

On Feb 15, 2013, at 6:14 PM, Jim Schaad <> wrote:

> Matt,
> Here are some comments to be considered.
> 1.        There is the possibility of confusion in the first sentence of the
> introduction about the transport of symmetric keys.  One place where one
> transports symmetric keys but not in this method is in JWE itself.  I think
> that it would make more sense to talk about transporting private key
> information and define that as including both the private portion of an
> asymmetric key as well as a binary value that can be used either as a
> symmetric key or a MAC key.  This draft would be used when that is the
> primary aim of what is happening, but the necessary security properties
> might not be provided by the methods of transport used. 

Will change for next revision.  Also, should I change "symmetric key" to "shared secret" in said definition?

> 2.       Make the paragraph on defining a password based algorithm separate
> and lengthen it a bit to justify why it is being done.

Will add in next revision.

> 3.       JSON is not a well-known TLA - it needs to be expanded on first use
> (including in the title).

I guess I didn't think it necessary since I've seen a number of drafts recently omit it; the next revision will include JSON expanded.

> 4.       I don't understand the end of the sentence in section 3.2, para 2.
> What input limits are we talking about here?

Here, "inputs limits" means "plaintext length limit".  Will rephrase in next revision.

> 5.       I would suggest adding an optional "hint" parameter to PBKDF2 which
> can contain a hint for the user about what the password is.
> 6.       Suggested/mandated seed and iteration lengths should be in section
> 6.1.1 and 6.1.2 respectively and not in the security considerations (if you
> want you can duplicate).  These should be where people are going to see them
> and remember them and not in a section that they might or might not read.

I went back and forth on that myself.  I'll move to 6.1.x in next revision.

> 7.       You should have text in the section to state the registry that you
> are asking IANA to register things into.

Will add in next revision.

> 8.       What steps should I as a programmer take to enforce the protocol
> requirements in section 8.1?

Good point; this isn't realistically enforceable as written.  I'll try to come up with some alternative text.

> 9.       Section 8.2 - That is nice, why is it a security consideration?
> What actions should I be taking as a programmer to deal with this?

This seemed similar to a concern in XMPP-E2E about offline messages, and so seemed appropriate to add here also.  I will try to come up with some suggested actions one might take. Alternatively, I can remove it if there's consensus this is not a worthwhile concern.

> 10.   Section 8.3 - I can understand why there is a recommendation of being
> bigger than the derived key length, but you should have some justification
> pointer for being smaller than the PRF block size.  What is the effect of
> this being ideal vs RECOMMENDED?

There is text in RFC 2898 that I can incorporate here.  I can also change to the more normative RECOMMENDED.

Thanks again,

- m&m

Matt Miller < >
Cisco Systems, Inc.