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

"Jim Schaad" <ietf@augustcellars.com> Sat, 16 February 2013 01:15 UTC

Return-Path: <ietf@augustcellars.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 8FDFB21E803A for <jose@ietfa.amsl.com>; Fri, 15 Feb 2013 17:15:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.526
X-Spam-Level:
X-Spam-Status: No, score=-3.526 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MIFDmZ2w1aP for <jose@ietfa.amsl.com>; Fri, 15 Feb 2013 17:15:24 -0800 (PST)
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id D893921F8570 for <jose@ietf.org>; Fri, 15 Feb 2013 17:15:24 -0800 (PST)
Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 10A7839023; Fri, 15 Feb 2013 17:15:21 -0800 (PST)
From: "Jim Schaad" <ietf@augustcellars.com>
To: <draft-miller-jose-jwe-protected-jwk@tools.ietf.org>
Date: Fri, 15 Feb 2013 17:14:51 -0800
Message-ID: <047101ce0be3$0620aed0$12620c70$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0472_01CE0B9F.F7FF4390"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac4Lzeuu/g0gyocOQPi1CIMUJXbUSg==
Content-Language: en-us
Cc: jose@ietf.org
Subject: [jose] Comments on draft-miller-jose-jwe-protected-jwk-00
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: Sat, 16 Feb 2013 01:15:26 -0000

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. 

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

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

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

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.

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

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

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?

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?

 

 

Jim