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 > >
- [jose] Appsdir review for draft-ietf-jose-json-we… Carsten Bormann
- Re: [jose] [apps-discuss] Appsdir review for draf… Carsten Bormann
- Re: [jose] [apps-discuss] Appsdir review for draf… Carsten Bormann
- Re: [jose] [apps-discuss] Appsdir review for draf… Kathleen Moriarty
- Re: [jose] [apps-discuss] Appsdir review for draf… Mike Jones
- Re: [jose] [apps-discuss] Appsdir review for draf… Carsten Bormann
- Re: [jose] [apps-discuss] Appsdir review for draf… Mike Jones
- Re: [jose] [apps-discuss] Appsdir review for draf… Mike Jones
- Re: [jose] [apps-discuss] Appsdir review for draf… Kathleen Moriarty
- Re: [jose] [apps-discuss] Appsdir review for draf… Kathleen Moriarty
- Re: [jose] [apps-discuss] Appsdir review for draf… Carsten Bormann
- Re: [jose] [apps-discuss] Appsdir review for draf… Mike Jones