Return-Path: 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 ; 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 ; 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 ; 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 ; 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 In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BAA15F1@TK5EX14MBXC288.redmond.corp.microsoft.com> Date: Wed, 1 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 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" , "jose-chairs@tools.ietf.org" , IESG , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 18:10:21 -0000 --Apple-Mail=_28DAA228-195D-4E71-A505-FDD17EE3ACF9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Mike, On Sep 29, 2014, at 3:50 PM, Mike Jones = wrote: > Thanks for your review, Alissa. I=92ve added the working group to = this thread so they're aware of your comments. Replies are inline = below=85 > =20 > -----Original Message----- > From: Alissa Cooper [mailto:alissa@cooperw.in]=20 > 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) > =20 > Alissa Cooper has entered the following ballot position for > draft-ietf-jose-json-web-encryption-33: No Objection > =20 > 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.) > =20 > =20 > Please refer to = http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > =20 > =20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption/ > =20 > =20 > =20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > =20 > =3D=3D Section 2 =3D=3D > 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? > =20 > Thanks for the RFC 4949 reference. I propose that we use those = definitions, where applicable. > =20 > =3D=3D Section 4.1 =3D=3D > "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." > =20 > 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? > =20 > 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. > =20 > -- Mike > =20 Ah, ok. In the 4.1 text I didn=92t get the implied =93both = specifications that defined a parameter with the same name.=94 Thanks, Alissa --Apple-Mail=_28DAA228-195D-4E71-A505-FDD17EE3ACF9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi Mike,

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

Thanks for your review, Alissa.  I=92ve added = the working group to this thread so they're aware of your = comments.  Replies are inline below=85
 
-----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
Subj= ect: 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.)
 
 
for more information about IESG = DISCUSS and COMMENT positions.
 
 
The = document, along with other ballot positions, can be found = here:
 
 
 
-------------------------------------------------------------= ---------
COMMENT:
-------------------------------------------------------------= ---------
 
=3D=3D = Section 2 =3D=3D
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.
 
=3D=3D Section 4.1 =3D=3D
"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.
 
           &= nbsp;           &nb= sp;            = ;            &= nbsp;           -- = Mike
 

Ah, = ok. In the 4.1 text I didn=92t get the implied =93both specifications = that defined a parameter with the same = name.=94
Thanks,
Alissa

= --Apple-Mail=_28DAA228-195D-4E71-A505-FDD17EE3ACF9--