Re: [jose] [apps-discuss] Appsdir review for draft-ietf-jose-json-web-algorithms-33

Carsten Bormann <cabo@tzi.org> Tue, 14 October 2014 16:35 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A441A8A9B; Tue, 14 Oct 2014 09:35:47 -0700 (PDT)
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_DE=0.35, SPF_HELO_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 ORu6bKNjYCFg; Tue, 14 Oct 2014 09:35:46 -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 185C51A8986; Tue, 14 Oct 2014 09:35:45 -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 [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9EGZgoX023579; Tue, 14 Oct 2014 18:35:42 +0200 (CEST)
Received: from [10.0.1.3] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 12EFCF46; Tue, 14 Oct 2014 18:35:41 +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>
In-Reply-To: <805301AA-4E04-410D-A451-7A2175792CB0@tzi.org>
Date: Tue, 14 Oct 2014 18:35:40 +0200
X-Mao-Original-Outgoing-Id: 434997340.7554-038588822f6bf661768115a91d96d379
Content-Transfer-Encoding: quoted-printable
Message-Id: <7CEA60C1-BC9D-43BE-84B4-128D08F111F5@tzi.org>
References: <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/66AoY2Ux8Ng37EYZ3J7IxIu9Z3c
Cc: iesg@ietf.org, jose@ietf.org
Subject: Re: [jose] [apps-discuss] 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: Tue, 14 Oct 2014 16:35:47 -0000

Here is a quick re-check of my review against -34.
I’m not sure any of the necessary fixes made it into -34.

Grüße, Carsten

On 02 Oct 2014, at 09:22, Carsten Bormann <cabo@tzi.org> wrote:

> I have been selected as the Applications Area Directorate reviewer for
> this draft (for background on appsdir, please see
> ​http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
> ).
> 
> 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:
> 
> 5.2:
> Add a reference that defines PKCS #7 padding.

No change.
(Note that there is a reference behind “PKCS #7 padding”, it just happens to define CBC and not PKCS #7).

> 5.2.2.2
> Does "the PKCS #7 padding is removed" entail checking all of its bytes?

No change.

> 6.2.1
> 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.

No change.

> 6.2.1.1
> »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?

No change.

And so on.

> 6.3.2:
> The MAY accept partially overrides the MUST include?
> Is the latter thus really a SHOULD?
> 
> 7.1:
> It is interesting that a mere registration (vetted only by a DE) can
> change the IETF consensus base specifications by making an algorithm
> "Required".
> 
> 8.
> 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:
> 
> 6.3.2.x:
> 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?
> 
> 6.2.3.1: This is not a positive integer?  6.2.3.x mentions this otherwise.
> 
> 7.1.1
> »Example description« is not a useful example for an "Algorithm Description".
> (Same comment for 7.x.1.)
> 
> 8.3:
> s/because it/because it is/
> 
> [sec1]
> (Given the date, this is probably referencing V2.0 of this spec.)
> 
> [usascii]
> 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.)
> 
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
> 
>