From nobody Tue Oct 18 11:50:50 2016 Return-Path: X-Original-To: jose-reg-review@ietfa.amsl.com Delivered-To: jose-reg-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D091296FD for ; Tue, 18 Oct 2016 11:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.33 X-Spam-Level: X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=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 IcXHmS9JhhKT for ; Tue, 18 Oct 2016 11:50:45 -0700 (PDT) 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 98D911296CE for ; Tue, 18 Oct 2016 11:50:45 -0700 (PDT) Received: from unnumerable.local ([47.186.56.40]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u9IIocqD098466 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Tue, 18 Oct 2016 13:50:38 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.56.40] claimed to be unnumerable.local To: jose-reg-review@ietf.org From: Robert Sparks Message-ID: <74d2dbc3-7de7-bb4f-5e9f-5152f76dfd10@nostrum.com> Date: Tue, 18 Oct 2016 13:50:38 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------6939945DD98EAD205E267841" Archived-At: Cc: "chris_wendt@cable.comcast.com" , Russ Housley , Alissa Cooper , Jon Peterson Subject: [Jose-reg-review] Review requested: draft-ietf-stir-passport X-BeenThere: jose-reg-review@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "The JSON Web Algorithm standard \(RFC 7518\) establishes this email list for designated experts to discuss proposed changes, additions, and removals to the set of algorithms in the JSON Object Signing and Encryption \(JOSE\) registry, http://www.iana.org/assignments/jose." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 18:50:49 -0000 This is a multi-part message in MIME format. --------------6939945DD98EAD205E267841 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Please review the registration request in section 11.3 ( key elements copied below for convenience) at Robert Sparks - STIR WG co-chair ------------ 11.3. JSON Web Signature and Encryption Header Parameter Registry 11.3.1. Registry Contents Additions Requested Header Parameter Name: "ppt" o Header Parameter Description: PASSporT extension identifier o Header Parameter Usage Location(s): JWS o Change Controller: IESG o Specification Document(s): Section 8.1 of [RFCThis] -------------- 8.1. "ppt" (PASSporT) header parameter Any using protocol can extend the payload of PASSporT with additional JWT claims. JWT claims are managed by an existing IANA registry as defined in [RFC7519] Section 10.1. Implementations of PASSporT MUST support the baseline claims defined in Section 5.2, and MAY support extended claims. If it is necessary for an extension to PASSporT to require that a relying party support a particular extended claim or set of claims in the PASSporT object, it can do so by specifying a "ppt" element for the PASSporT JOSE header. All values of "ppt" need to be defined in a specification which associates the new value of the "ppt" element with the required claims and behaviors. Relying parties MUST fail to validate PASSporT objects containing an unsupported "ppt". Using protocols MUST explicitly define the how each claim is carried in the using protocol and the rules for how the header and payload objects are constructed beyond the lexicographical and serialization rules defined in this document. Using protocols that carry the compact form of PASSporT, defined in Section 7, instead of the full form MUST use only mandatory extensions signaled with "ppt" - if a using protocol were to add additional optional claims to a PASSporT object it carried in compact form, relying parties would have no way to reconstruct the token. Moreover, using protocols that support the compact form of PASSporT MUST have some field to signal "ppt" to relying parties, as the compact form of PASSporT omits the JOSE header. --------------6939945DD98EAD205E267841 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Please review the registration request in section 11.3 ( key elements copied below for convenience) at

<https://datatracker.ietf.org/doc/draft-ietf-stir-passport/>

Robert Sparks - STIR WG co-chair

------------

11.3.  JSON Web Signature and Encryption Header Parameter Registry

11.3.1.  Registry Contents Additions Requested

   Header Parameter Name: "ppt"

   o  Header Parameter Description: PASSporT extension identifier

   o  Header Parameter Usage Location(s): JWS

   o  Change Controller: IESG

   o  Specification Document(s): Section 8.1 of [RFCThis]

--------------

8.1.  "ppt" (PASSporT) header parameter

   Any using protocol can extend the payload of PASSporT with additional
   JWT claims.  JWT claims are managed by an existing IANA registry as
   defined in [RFC7519] Section 10.1.  Implementations of PASSporT MUST
   support the baseline claims defined in Section 5.2, and MAY support
   extended claims.  If it is necessary for an extension to PASSporT to
   require that a relying party support a particular extended claim or
   set of claims in the PASSporT object, it can do so by specifying a
   "ppt" element for the PASSporT JOSE header.  All values of "ppt" need
   to be defined in a specification which associates the new value of
   the "ppt" element with the required claims and behaviors.  Relying
   parties MUST fail to validate PASSporT objects containing an
   unsupported "ppt".

   Using protocols MUST explicitly define the how each claim is carried
   in the using protocol and the rules for how the header and payload
   objects are constructed beyond the lexicographical and serialization
   rules defined in this document.

   Using protocols that carry the compact form of PASSporT, defined in
   Section 7, instead of the full form MUST use only mandatory
   extensions signaled with "ppt" - if a using protocol were to add
   additional optional claims to a PASSporT object it carried in compact
   form, relying parties would have no way to reconstruct the token.
   Moreover, using protocols that support the compact form of PASSporT
   MUST have some field to signal "ppt" to relying parties, as the
   compact form of PASSporT omits the JOSE header.

--------------6939945DD98EAD205E267841-- From nobody Tue Oct 18 13:04:45 2016 Return-Path: X-Original-To: jose-reg-review@ietfa.amsl.com Delivered-To: jose-reg-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF99C129851 for ; Tue, 18 Oct 2016 13:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 HMEX8pX_c9Et for ; Tue, 18 Oct 2016 13:04:40 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CAF6129842 for ; Tue, 18 Oct 2016 13:04:39 -0700 (PDT) Received: from hebrews (173.8.216.38) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 18 Oct 2016 13:20:49 -0700 From: Jim Schaad To: 'Robert Sparks' , References: <74d2dbc3-7de7-bb4f-5e9f-5152f76dfd10@nostrum.com> In-Reply-To: <74d2dbc3-7de7-bb4f-5e9f-5152f76dfd10@nostrum.com> Date: Tue, 18 Oct 2016 13:04:30 -0700 Message-ID: <055201d2297a$d856c5c0$89045140$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0553_01D22940.2BF92640" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQI61KekfCopLPVnn2FhBJuAsIStnp/dS/GQ X-Originating-IP: [173.8.216.38] Archived-At: Cc: chris_wendt@cable.comcast.com, 'Russ Housley' , 'Alissa Cooper' , 'Jon Peterson' Subject: Re: [Jose-reg-review] Review requested: draft-ietf-stir-passport X-BeenThere: jose-reg-review@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "The JSON Web Algorithm standard \(RFC 7518\) establishes this email list for designated experts to discuss proposed changes, additions, and removals to the set of algorithms in the JSON Object Signing and Encryption \(JOSE\) registry, http://www.iana.org/assignments/jose." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 20:04:43 -0000 ------=_NextPart_000_0553_01D22940.2BF92640 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The changes with -09 deal with all of the issues I had on this. = Registration approval should be forthcoming. I need to figure out the = exact procedures for letting IANA know. =20 Jim =20 =20 From: Jose-reg-review [mailto:jose-reg-review-bounces@ietf.org] On = Behalf Of Robert Sparks Sent: Tuesday, October 18, 2016 11:51 AM To: jose-reg-review@ietf.org Cc: chris_wendt@cable.comcast.com; Russ Housley ; = Alissa Cooper ; Jon Peterson Subject: [Jose-reg-review] Review requested: draft-ietf-stir-passport =20 Please review the registration request in section 11.3 ( key elements = copied below for convenience) at = Robert Sparks - STIR WG co-chair ------------ 11.3. JSON Web Signature and Encryption Header Parameter Registry =20 11.3.1. Registry Contents Additions Requested =20 Header Parameter Name: "ppt" =20 o Header Parameter Description: PASSporT extension identifier =20 o Header Parameter Usage Location(s): JWS =20 o Change Controller: IESG =20 o Specification Document(s): Section 8.1 of [RFCThis] =20 -------------- =20 8.1. "ppt" (PASSporT) header parameter =20 Any using protocol can extend the payload of PASSporT with additional JWT claims. JWT claims are managed by an existing IANA registry as defined in [RFC7519] Section 10.1. Implementations of PASSporT MUST support the baseline claims defined in Section 5.2, and MAY support extended claims. If it is necessary for an extension to PASSporT to require that a relying party support a particular extended claim or set of claims in the PASSporT object, it can do so by specifying a "ppt" element for the PASSporT JOSE header. All values of "ppt" need to be defined in a specification which associates the new value of the "ppt" element with the required claims and behaviors. Relying parties MUST fail to validate PASSporT objects containing an unsupported "ppt". =20 Using protocols MUST explicitly define the how each claim is carried in the using protocol and the rules for how the header and payload objects are constructed beyond the lexicographical and serialization rules defined in this document. =20 Using protocols that carry the compact form of PASSporT, defined in Section 7, instead of the full form MUST use only mandatory extensions signaled with "ppt" - if a using protocol were to add additional optional claims to a PASSporT object it carried in compact form, relying parties would have no way to reconstruct the token. Moreover, using protocols that support the compact form of PASSporT MUST have some field to signal "ppt" to relying parties, as the compact form of PASSporT omits the JOSE header. =20 ------=_NextPart_000_0553_01D22940.2BF92640 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

The changes with -09 deal with all of the issues I had on = this.=C2=A0 Registration approval should be forthcoming.=C2=A0 I need to = figure out the exact procedures for letting IANA = know.

 

Jim

 

 

From: Jose-reg-review [mailto:jose-reg-review-bounces@ietf.org] On = Behalf Of Robert Sparks
Sent: Tuesday, October 18, 2016 = 11:51 AM
To: jose-reg-review@ietf.org
Cc: = chris_wendt@cable.comcast.com; Russ Housley = <housley@vigilsec.com>; Alissa Cooper <alissa@cooperw.in>; = Jon Peterson <jon.peterson@gmail.com>
Subject: = [Jose-reg-review] Review requested: = draft-ietf-stir-passport

 

Please review the registration = request in section 11.3 ( key elements copied below for convenience) = at

<h= ttps://datatracker.ietf.org/doc/draft-ietf-stir-passport/>

Robert Sparks - STIR WG = co-chair

------------

11.3.=C2=A0 JSON Web Signature and Encryption Header =
Parameter =
Registry
 
11.3.1.=C2=A0 Registry Contents Additions =
Requested
 
=C2=A0=C2=
=A0 Header Parameter Name: =
"ppt"
 
=C2=A0=C2=
=A0 o=C2=A0 Header Parameter Description: PASSporT extension =
identifier
 
=C2=A0=C2=A0 =
o=C2=A0 Header Parameter Usage Location(s): =
JWS
 
=C2=A0=C2=A0 =
o=C2=A0 Change Controller: =
IESG
 
=C2=A0=C2=A0 =
o=C2=A0 Specification Document(s): Section 8.1 of =
[RFCThis]
 
--------------=
 
8.1.=C2=A0 "ppt" (PASSporT) header =
parameter
 
=C2=A0=C2=
=A0 Any using protocol can extend the payload of PASSporT with =
additional
=C2=A0=C2=A0 JWT claims.=C2=A0 JWT =
claims are managed by an existing IANA registry =
as
=C2=A0=C2=A0 defined in [RFC7519] Section =
10.1.=C2=A0 Implementations of PASSporT =
MUST
=C2=A0=C2=A0 support the baseline claims =
defined in Section 5.2, and MAY =
support
=C2=A0=C2=A0 extended claims.=C2=A0 If it =
is necessary for an extension to PASSporT =
to
=C2=A0=C2=A0 require that a relying party =
support a particular extended claim or
=C2=A0=C2=A0 =
set of claims in the PASSporT object, it can do so by specifying =
a
=C2=A0=C2=A0 "ppt" element for the =
PASSporT JOSE header.=C2=A0 All values of "ppt" =
need
=C2=A0=C2=A0 to be defined in a specification =
which associates the new value of
=C2=A0=C2=A0 the =
"ppt" element with the required claims and behaviors.=C2=A0 =
Relying
=C2=A0=C2=A0 parties MUST fail to validate =
PASSporT objects containing an
=C2=A0=C2=A0 =
unsupported =
"ppt".
 
=C2=A0=C2=
=A0 Using protocols MUST explicitly define the how each claim is =
carried
=C2=A0=C2=A0 in the using protocol and the =
rules for how the header and payload
=C2=A0=C2=A0 =
objects are constructed beyond the lexicographical and =
serialization
=C2=A0=C2=A0 rules defined in this =
document.
 
=C2=A0=C2=A0 =
Using protocols that carry the compact form of PASSporT, defined =
in
=C2=A0=C2=A0 Section 7, instead of the full form =
MUST use only mandatory
=C2=A0=C2=A0 extensions =
signaled with "ppt" - if a using protocol were to =
add
=C2=A0=C2=A0 additional optional claims to a =
PASSporT object it carried in compact
=C2=A0=C2=A0 =
form, relying parties would have no way to reconstruct the =
token.
=C2=A0=C2=A0 Moreover, using protocols that =
support the compact form of PASSporT
=C2=A0=C2=A0 =
MUST have some field to signal "ppt" to relying parties, as =
the
=C2=A0=C2=A0 compact form of PASSporT omits the =
JOSE =
header.
 
------=_NextPart_000_0553_01D22940.2BF92640--