Re: [jose] Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06

Robert Sparks <rjsparks@nostrum.com> Sun, 13 December 2015 21:11 UTC

Return-Path: <rjsparks@nostrum.com>
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 581571A6FC2; Sun, 13 Dec 2015 13:11:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 Kub824tc8gRD; Sun, 13 Dec 2015 13:11:38 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3D8E1A6FBA; Sun, 13 Dec 2015 13:11:37 -0800 (PST)
Received: from unnumerable.local (pool-173-57-210-37.dllstx.fios.verizon.net [173.57.210.37]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tBDLBZqm069473 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Sun, 13 Dec 2015 15:11:35 -0600 (CST) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-210-37.dllstx.fios.verizon.net [173.57.210.37] claimed to be unnumerable.local
To: Mike Jones <Michael.Jones@microsoft.com>, General Area Review Team <gen-art@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "jose@ietf.org" <jose@ietf.org>, "draft-ietf-jose-jws-signing-input-options@ietf.org" <draft-ietf-jose-jws-signing-input-options@ietf.org>
References: <5661E491.9050007@nostrum.com> <BY2PR03MB442B4D7B1E70A9957D43590F5EC0@BY2PR03MB442.namprd03.prod.outlook.com>
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <566DDF01.1020806@nostrum.com>
Date: Sun, 13 Dec 2015 15:11:29 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <BY2PR03MB442B4D7B1E70A9957D43590F5EC0@BY2PR03MB442.namprd03.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/jose/jhXVkfcJGoVr7q6R-L8-9uirefo>
Subject: Re: [jose] Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06
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: <https://mailarchive.ietf.org/arch/browse/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: Sun, 13 Dec 2015 21:11:39 -0000

Cutting away a bit to focus on the question:

On 12/12/15 8:32 PM, Mike Jones wrote:
> Hi Robert.  Thanks for the useful review.  Replies are inline below...
>
>> -----Original Message-----
<snip/>
>>
>>
>> I would have been much more comfortable with a consensus to require 'crit'.
>> (Count me in the rough if this proceeds with crit being optional).
>>
>> I assume there is a strong reason to allow for option 1. Please add the
>> motivation for it to the draft, and consider adding a SHOULD use 'crit'
>> requirement if option 1 remains.
> It's a reasonable request to have the draft say why "crit" isn't required.  My working draft adds the following new paragraph at the end of the security considerations section to do this.  Unless I hear objections, I'll plan on publishing an updated draft with the paragraph shortly.
>
> "Note that methods 2 and 3 are sufficient to cause JWSs using this extension to be rejected by implementations not supporting this extension but they are not sufficient to enable JWSs using this extension to be successfully used by applications.
The conclusion you draw here is not at all obvious.
_WHY_ is crit not sufficient? I think that's the thing that's missing as 
motivation.

>   Thus, method 1 - requiring support for this extension - is the preferred approach and the only means for this extension to be practically useful to applications. Method 2 - requiring the use of <spanx style="verb">crit</spanx> - while theoretically useful to ensure that confusion between encoded and unencoded payloads cannot occur, is not particularly useful in practice, since method 1 is still required for the extension to be usable. When method 1 is employed, method 2 doesn't add any value and since it increases the size of the JWS, its use is not required by this specification."
>
>> Nits/editorial comments:
>>
>> In the security considerations, the last sentence of the first paragraph needs
>> to be simplified. I suggest replacing it with:
>>
>> "It then becomes the responsibility of the application to ensure that payloads
>> only contain characters that will not cause parsing problems for the
>> serialization used, as described in Section 5. The application also incurs the
>> responsibility to ensure that the payload will not be modified during
>> retransmission.
> I have simplified this in the manner that you suggested.
>
> 				Thanks again,
> 				-- Mike