[secdir] SecDir review of draft-ietf-jose-cookbook-06

Yaron Sheffer <yaronf.ietf@gmail.com> Sat, 22 November 2014 19:40 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 31B891A011F; Sat, 22 Nov 2014 11:40:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 5CQWoKFlhlM0; Sat, 22 Nov 2014 11:40:17 -0800 (PST)
Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28A3C1A00E8; Sat, 22 Nov 2014 11:40:17 -0800 (PST)
Received: by mail-wi0-f170.google.com with SMTP id bs8so5620772wib.3 for <multiple recipients>; Sat, 22 Nov 2014 11:40:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=R9BKncl9lpH1dCKZgcGrlX2ABpLV3ZLAsLlKo91YGjU=; b=FBrsqJqnhY8rOT1tl00vwB8mI6ovX+Mv99LvJwwHhxFVwCKnzJW3XxRUAVRJHdWzl+ Kt7m9bM7zT4dUr3Uuoy1mZ8TIuvy6wUzhCUctHU1FjNKtRyORBQUzk34zVVPx19Y/WRm qUFjxCkF3dqKaFmPYUQ6SdBd0acmBqbG24T4y+4umLOFCii6evrMkClt/jb6DSE49IBE 5jiW37j2j2LOB6SMz7B7f3uAogEY/9C+Uvh8NaYNcCwBZV4E+XV6RYCCYtmfd9UrsoXU AxuU0GxonFFoWYP1dbYkvT4Uz8XCH/J3PqmzOWCnX4vu2Ylg0WgDE8tGujNmh44YTDwn 2UPw==
X-Received: by with SMTP id pg5mr7889617wic.70.1416685215958; Sat, 22 Nov 2014 11:40:15 -0800 (PST)
Received: from [] ([]) by mx.google.com with ESMTPSA id j2sm13370361wjs.28.2014. for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 22 Nov 2014 11:40:15 -0800 (PST)
Message-ID: <5470E68D.3040204@gmail.com>
Date: Sat, 22 Nov 2014 21:39:57 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: IETF Security Directorate <secdir@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-jose-cookbook.all@tools.ietf.org
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/fwAjyz93HAITT_mmsT8W4mbm6xc
Subject: [secdir] SecDir review of draft-ietf-jose-cookbook-06
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: Sat, 22 Nov 2014 19:40:19 -0000

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 contains a large set of examples of JOSE objects: JWK, JWS 
and JWE. The document is purely informational, though in "real life", I 
would expect developers to use it as an authoritative source.


The document is ready to be published, with some issues.

By the way, I really appreciate the large effort that surely went into 
creating this document.


• Unless I missed it, the document does not mention a machine readable 
repository of these examples, which I am sure the author has created 
while writing the draft. Making such a repository publicly available 
would result in a much more useful resource than the current document, 
which essentially requires testers to scrape the document when creating 
their test cases.

• (Not a comment to the current document:) I wonder why there is nothing 
explicit to distinguish a public key from a private key, and they are 
only distinguished by the presence or absence of several parameters, 
something that will not be natural to most developers. PEM is doing it 
very well: "-----BEGIN RSA PRIVATE KEY-----".

• 3.4: the text is contradictory re: zero-padding of the value "d". Is 
it using the minimum number of octets, or exactly 256 octets (for a 
2048-bit key)?

• Why invent a new term "octet key", for a simple "symmetric key"?

• 4.2: the first sentence discusses PS256, the actual example is PS384.

• 4.7: "only the JSON serialization" - please clarify which of the three 
serializations is meant. Ditto top of 4.8.

• 5.1.1: since this is a "cookbook", we should be using the public key, 
not the private key. A private key would only be used in rare cases. 
Similarly 5.2.1.

• 5.3.1: the "plaintext content" is a list of keys, which is either 
confusing to the reader, or an actual error in the document.

• 5.3.5: In the General Serialization version, I don't understand why 
only the encrypted key is per-recipient. I would expect the PBES2 
parameters too (e.g., the salt)  to be per-recipient. Presumably each of 
them is using a different password, and there's no reason to use a 
common salt. Similarly in 5.4.5.

• 5.7: same as above, it makes sense for the per-recipient key to have 
an ID, rather than the content encryption key (typically an ephemeral 
key). And then that ID should be in the per-recipient data in 5.7.5. And 
similarly for 5.8. The later Sec. 5.13 shows a syntax for multiple 
recipients that's inconsistent with the single-recipient case, which 
would make sense if we got rid of the array.

• 5.11: this example seems strange to me - why would anybody NOT want to 
integrity-protect the key ID and algorithm? I would prefer a more 
realistic example, or failing that, a recommendation to developers to 
avoid this practice. Similarly 5.12, which is an even worse idea.