Re: [jose] AppsDir reviews of draft-ietf-jose-json-web-signature-32

Mike Jones <> Wed, 15 October 2014 07:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7C5451A038F; Wed, 15 Oct 2014 00:13:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K1QRMG7QILed; Wed, 15 Oct 2014 00:13:16 -0700 (PDT)
Received: from ( [IPv6:2a01:111:f400:fc10::1:723]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1D0091A03A2; Wed, 15 Oct 2014 00:13:16 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1054.13; Wed, 15 Oct 2014 07:12:52 +0000
Received: from (2a01:111:f400:7c10::155) by (2a01:111:e400:401e::15) with Microsoft SMTP Server (TLS) id 15.0.1049.19 via Frontend Transport; Wed, 15 Oct 2014 07:12:52 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Wed, 15 Oct 2014 07:12:52 +0000
Received: from ([]) by ([]) with mapi id 14.03.0210.003; Wed, 15 Oct 2014 07:12:28 +0000
From: Mike Jones <>
To: Ray Polk <>, Claudio Allocchio <>, "" <>, Barry Leiba <>
Thread-Topic: AppsDir reviews of draft-ietf-jose-json-web-signature-32
Thread-Index: AQHP3gq8ooW0Hna0tkS7mc30NBGUc5wwzZ4Q
Date: Wed, 15 Oct 2014 07:12:27 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(189002)(43784003)(15374003)(51704005)(199003)(21056001)(86612001)(84676001)(64706001)(107046002)(66066001)(20776003)(47776003)(31966008)(230783001)(50466002)(95666004)(26826002)(104016003)(85306004)(99396003)(50986999)(120916001)(33656002)(76482002)(106116001)(54356999)(76176999)(87936001)(85852003)(2656002)(46406003)(97736003)(85806002)(23726002)(55846006)(81156004)(86362001)(106466001)(92566001)(80022003)(46102003)(77096002)(19580395003)(15975445006)(19580405001)(97756001)(92726001)(44976005)(4396001)(6806004)(68736004)(69596002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB1206;; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en;
X-Microsoft-Antispam: UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB1206;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0365C0E14B
Received-SPF: Pass ( domain of designates as permitted sender); client-ip=;;
Authentication-Results: spf=pass (sender IP is;
Cc: "" <>, "" <>, "" <>
Subject: Re: [jose] AppsDir reviews of draft-ietf-jose-json-web-signature-32
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Javascript Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Oct 2014 07:13:18 -0000

Thanks for your review Ray.  My apologies for not responding to it until now.  It had gotten sorted into a mail folder and I hadn't seen it until Kathleen brought it to my attention.  Responses are inline below...

> Date: Wed, 1 Oct 2014 20:21:42 -0700 (PDT)
> From: Ray Polk <>
> To:
> Cc:
> Subject: Re: URGENT AppsDir reviews of the JOSE document set - asigned drafts
> Hi Claudio (and Mike),
> I've finished reviewing draft-ietf-jose-json-web-signature-32 for AppsDir.  I could
> not find another AppsDir review on the jose mailing list to use as a model.  So, I
> don't know to whom I should send my review, the format it should take, or the
> severity of the issues to include (include Nits?  include minor, non-blocking
> issues?).
> For now, I'll include all of my notes.  If you can advise me of proper
> format/protocol/procedure, I'll craft an email to the jose list.
> Major:  None
> Minor:
> 4.1.1. & 4.1.2. The links to Section 4.1 and Section 5.1 of JWA are incorrect.
> They link to JWE instead of JWA.
> In 4.1.1. the link is:
> ...but it should be:
> In 4.1.2. the link is:
> ...but it should be:
> (JWA doesn't seem to have an anchor for 5.1)

These link URLs are actually created by the IETF tools - not in the draft itself.  (You'll see "Html markup produced by rfcmarkup 1.109, available from" at the bottom of the drafts.)  I'm not sure who to file a bug on this with.

> 9. saying "separated by X period ('.') characters" is ambiguous:
> JWSs have three segments separated by two period ('.') characters.
> This means:  segment..segment..segment
> JWEs have five segments separated by four period ('.') characters.
> This means:  segment....segment....segment....segment....segment
> Say instead:  ___s have X segments.  Each segment is separated from the next by
> a single period ('.') for a total of X-1 delimiting periods ('.').

Thanks - I'll plan to make this correction.

> Nit:
> 3.2 change "of these eight values," to "...values:", remove commas and the
> 'and', change "...with the six" to a complete sentence.

The "values" correction is already present in the -34 draft.  I agree that not trying to include the list in a sentence structure would make it easier to read.

> 3.3 remove the and from " produce the JWE Encrypted Key and" and the
> period from the next bullet


> 4.1.3. fix comma splicing in:  "This Header Parameter MUST be integrity
> protected, and therefore MUST occur only within the JWE Protected Header,
> when used."  For example, "When used, this Header Parameter MUST be
> integrity protected; therefore, it MUST occur only within the JWE Protected
> Header."


> Sections 4.1.4. through 4.1.10. are almost entirely redundant.  Combine them
> like so:
> The following parameters have the same meaning, syntax, and processing rules
> as those defined in JWS, except that the certificate referenced by the thumbprint
> contains the public key to which the JWE was encrypted; this can be used to
> determine the private key needed to decrypt the JWE.
> jku defined in Section 4.1.2. of [JWS]
> jwk defined in Section 4.1.3. of [JWS]
> etc.

I understand this suggestion but disagree because there's value to implementers and other readers to having each of the header parameters listed as a section header in the table of contents.  It makes it easy to see all of them in one place.  Combining them would lose this benefit.

				Thanks again,
				-- Mike