Re: [jose] Alissa Cooper's No Objection on draft-ietf-jose-json-web-encryption-33: (with COMMENT)

Alissa Cooper <alissa@cooperw.in> Wed, 01 October 2014 18:10 UTC

Return-Path: <alissa@cooperw.in>
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 373711A1BDA for <jose@ietfa.amsl.com>; Wed, 1 Oct 2014 11:10:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 YbZMQIcXsf-B for <jose@ietfa.amsl.com>; Wed, 1 Oct 2014 11:10:16 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85A931A1B79 for <jose@ietf.org>; Wed, 1 Oct 2014 11:09:35 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by gateway2.nyi.internal (Postfix) with ESMTP id AD48D20B20 for <jose@ietf.org>; Wed, 1 Oct 2014 14:09:34 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Wed, 01 Oct 2014 14:09:34 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:content-type:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; s=mesmtp; bh=b/99PUcjUUakzttM MChmwPoh/Ys=; b=W9amtWvKPnNbLiL0CGQiU9TsL9jNKcoJ1CM7bFsTmCT9an5v FkhJl315z9KT58D47i61+4sBUW/O2qky42fnuRxKzK4rTj7dPRpys060qMVFelBI 6Bb8cgoHqR3zO1MHl2F+a1ly3b9xOyA1gaRluINa7B78MxLdxIupC70eNds=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:content-type:mime-version :subject:from:in-reply-to:date:cc:message-id:references:to; s= smtpout; bh=b/99PUcjUUakzttMMChmwPoh/Ys=; b=Ee/1W32M+uVdRe0Wnfie 9bXfbSee6MKeMMAF9LMve/fmz5Aas+CwFFg6PZj4HEvS+ud5QPhicKJzjo/AhV/d uZIe3yMu6/Jy/PNELam4EJmmmGS2jaxBBEIxn7GEp8w0c3D8nUJM5EJHSQ0JwxCt REKo4ofwtm6O37p5jwUdr8c=
X-Sasl-enc: DP0q4uaajjIcnF9uEHZhXS6/ELBTYuiezelTp7iJj15G 1412186974
Received: from [10.35.132.83] (unknown [128.107.239.234]) by mail.messagingengine.com (Postfix) with ESMTPA id C1FCA68011E; Wed, 1 Oct 2014 14:09:33 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_28DAA228-195D-4E71-A505-FDD17EE3ACF9"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BAA15F1@TK5EX14MBXC288.redmond.corp.microsoft.com>
Date: Wed, 01 Oct 2014 11:09:32 -0700
Message-Id: <5495BB28-1042-4C04-BF60-CCAE7C89DE3D@cooperw.in>
References: <20140929022320.22639.63682.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAA15F1@TK5EX14MBXC288.redmond.corp.microsoft.com>
To: Mike Jones <Michael.Jones@microsoft.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/ZksQoYzXPm7_0LMQ3hg854Up8Ho
X-Mailman-Approved-At: Wed, 01 Oct 2014 12:50:43 -0700
Cc: "draft-ietf-jose-json-web-encryption@tools.ietf.org" <draft-ietf-jose-json-web-encryption@tools.ietf.org>, "jose-chairs@tools.ietf.org" <jose-chairs@tools.ietf.org>, IESG <iesg@ietf.org>, "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] Alissa Cooper's No Objection on draft-ietf-jose-json-web-encryption-33: (with COMMENT)
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: Wed, 01 Oct 2014 18:10:21 -0000

Hi Mike,

On Sep 29, 2014, at 3:50 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

> Thanks for your review, Alissa.  I’ve added the working group to this thread so they're aware of your comments.  Replies are inline below…
>  
> -----Original Message-----
> From: Alissa Cooper [mailto:alissa@cooperw.in] 
> Sent: Sunday, September 28, 2014 7:23 PM
> To: The IESG
> Cc: jose-chairs@tools.ietf.org; draft-ietf-jose-json-web-encryption@tools.ietf.org
> Subject: Alissa Cooper's No Objection on draft-ietf-jose-json-web-encryption-33: (with COMMENT)
>  
> Alissa Cooper has entered the following ballot position for
> draft-ietf-jose-json-web-encryption-33: No Objection
>  
> When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)
>  
>  
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>  
>  
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption/
>  
>  
>  
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>  
> == Section 2 ==
> It seems a bit odd that some of these terms are re-defined by this document rather than re-using existing definitions, e.g. from RFC 4949 (plaintext, ciphertext, etc.). Was that deliberate?
>  
> Thanks for the RFC 4949 reference.  I propose that we use those definitions, where applicable.
>  
> == Section 4.1 ==
> "As indicated by the common registry, JWSs and JWEs share a common
>    Header Parameter space; when a parameter is used by both
>    specifications, its usage must be compatible between the
>    specifications."
>  
> Since both the JWS and JWE specifications are on their way to becoming RFCs, would it make more sense to say "its usage is compatible between the specifications"? Or is this for the future when new parameters may get defined?
>  
> This text is applicable both to the current documents and to future registrations in the IANA JSON Web Signature and Encryption Header Parameters Registry.  The registration instructions include this text, reinforcing this requirement:
>    The same Header Parameter name can be
>    registered multiple times, provided that the parameter usage is
>    compatible between the specifications.  Different registrations of
>    the same Header Parameter name will typically use different Header
>    Parameter Usage Location(s) values.
>  
>                                                             -- Mike
>  

Ah, ok. In the 4.1 text I didn’t get the implied “both specifications that defined a parameter with the same name.”
Thanks,
Alissa