[secdir] Review of draft-ietf-jose-use-cases (Ready with nits)
Simon Josefsson <simon@josefsson.org> Tue, 17 December 2013 15:58 UTC
Return-Path: <simon@josefsson.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA131AE156; Tue, 17 Dec 2013 07:58:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level:
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no
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 nXVttYgRft3a; Tue, 17 Dec 2013 07:58:27 -0800 (PST)
Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDA11AE14F; Tue, 17 Dec 2013 07:58:26 -0800 (PST)
Received: from latte.josefsson.org (46.182.205.36.c.fiberdirekt.net [46.182.205.36]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id rBHFwNsb023552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 17 Dec 2013 16:58:24 +0100
Date: Tue, 17 Dec 2013 16:58:17 +0100
From: Simon Josefsson <simon@josefsson.org>
To: draft-ietf-jose-use-cases.all@tools.ietf.org, secdir@ietf.org, iesg@ietf.org
Message-ID: <20131217165817.3acaba4a@latte.josefsson.org>
X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se
X-Virus-Status: Clean
Subject: [secdir] Review of draft-ietf-jose-use-cases (Ready with nits)
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Dec 2013 15:58:29 -0000
Hi. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes some places where signed/encrypted JSON objects may be used, and gathers a list of requirements compiled from those use-cases. It is an Informational document, and doesn't mandate any implementation requirements, but presumably may help to evaluate whether the other JOSE deliverables meet expectations. The document is well-writen, and quite entertaining to read as a survey of various modern protocol use-cases. I only found minor issues. MINOR ISSUES: * The document is split into two parts, one that describes use-cases, and one that lists the requirements. The text of the use-cases mention several requirements that the solution needs to have, however it is hard to map those to the requirements listed in the second part. It is also hard to map the requirements back to the use-cases. There is a risk that something mentioned in the use-case section is not reflected in the requirements, and vice versa. However since this is an informational document, and that it is intended to be read and parsed by humans rather than something that will be implemented, I don't think this is a serious problem. For another approach, compare RFC 4226 which mix together a use case description with requirements. NITS: * Section 1 could mention PGP as well, it is a well known and widely used security protocol. Section 2: The ordering is wrong. OLD: In this document, we will refer to these as the "signed object format", the "encrypted object format", and the "key format", respectively. NEW: In this document, we will refer to these as the "encrypted object format", the "signed object format", and the "key format", respectively. Section 5.3: Typo OLD: In the OpenID Connect context, and in some other applicaitions of NEW: In the OpenID Connect context, and in some other applications of Section 5.7: Cut'n'paste error OLD: the counter value. A custom Key Derivation Function (KDF) function is used when is based on the AES-CBC is used to derive the required MAC key. The MAC key is then used to compute the MAC NEW: the counter value. A custom Key Derivation Function (KDF) function based on AES-CBC is used to derive the required MAC key. The MAC key is then used to compute the MAC /Simon
- [secdir] Review of draft-ietf-jose-use-cases (Rea… Simon Josefsson