[jose] Appsdir review for draft-ietf-jose-json-web-algorithms-33

Carsten Bormann <cabo@tzi.org> Thu, 02 October 2014 07:22 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id ADD481A0115; Thu, 2 Oct 2014 00:22:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id NmZOJngdhVIE; Thu, 2 Oct 2014 00:22:00 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C6F71A005A; Thu, 2 Oct 2014 00:22:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de []) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s927Luns007314; Thu, 2 Oct 2014 09:21:56 +0200 (CEST)
Received: from [] (ip-2-202-98-49.web.vodafone.de []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3D05468A; Thu, 2 Oct 2014 09:21:55 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Carsten Bormann <cabo@tzi.org>
Date: Thu, 02 Oct 2014 09:22:00 +0200
X-Mao-Original-Outgoing-Id: 433927320.462797-7c0401a104923a2324fc09e849936de8
Content-Transfer-Encoding: quoted-printable
Message-Id: <805301AA-4E04-410D-A451-7A2175792CB0@tzi.org>
To: apps-discuss@ietf.org, draft-ietf-jose-json-web-algorithms.all@tools.ietf.org
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/9N5CgSNUFzQeVouUxt9Js6xUlec
Cc: iesg@ietf.org, jose@ietf.org
Subject: [jose] Appsdir review for draft-ietf-jose-json-web-algorithms-33
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 02 Oct 2014 07:22:01 -0000

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document:  draft-ietf-jose-json-web-algorithms-33
Title: JSON Web Algorithms (JWA)
Reviewer: Carsten Bormann
Review Date: 2014-10-02
IESG Telechat date: 2014-10-02

Summary: This draft is ready for publication as a standards track RFC,
with a few nits corrected.

However, some additional editorial improvements might improve the
security outcome when it is referenced by application developers.

Major issues: None.

Minor issues:

Add a reference that defines PKCS #7 padding.
Does "the PKCS #7 padding is removed" entail checking all of its bytes?

Is the intention that the sentence containing "point compression is not
supported" also applies to any future registered value of "crv"?
A similar comment applies to other specifications in 6.2.1.x, e.g.,
the reference to SEC1 representation to x and y.
»Additional "crv" values MAY be
used, provided they are understood by implementations using that
Elliptic Curve key.«
How are conflicts between such implementation defined values and
future registered values handled?

The MAY accept partially overrides the MUST include?
Is the latter thus really a SHOULD?

It is interesting that a mere registration (vetted only by a DE) can
change the IETF consensus base specifications by making an algorithm

I am unable to find a "security considerations" section in NIST SP 800-38A.
800-38D at least has a "practical considerations" section, is that meant?
(Etc., I haven't checked all the references.)
In general, I believe a security considerations section is most useful
where it provides more directed guidance instead of saying the
equivalent of "here is a textbook".

8.7 is not clear: is it NOT RECOMMENDED to reuse an entire set of key
material (including IV), or to reuse any part of it?

Nits/editorial comments:

The constant repetition of »It is represented as the base64url encoding of
the value's unsigned big endian representation as an octet sequence.
The octet sequence MUST utilize the minimum number of octets to
represent the value.« almost ensures that an implementer will stop
reading the details (well, I did, and I did not write a program to
verify the same phrase is used everywhere; if any parameter were using a
different encoding, that sure would be missed).  Why not define
another abstraction like base64url and use this? This is not a positive integer?  6.2.3.x mentions this otherwise.

»Example description« is not a useful example for an "Algorithm Description".
(Same comment for 7.x.1.)

s/because it/because it is/

(Given the date, this is probably referencing V2.0 of this spec.)

The reference to ANSI X3.4:1986 should probably be replaced by a
reference to RFC 20.  There is little reason to reference a somewhat
hard to obtain external document ($60!) when we have an RFC about the
same subject.

(Tables in Appendix A need some formatting.)