doc: Add RFC documents

1 files changed, 1403 insertions, 0 deletions

diff --git a/doc/rfc/rfc8225.txt b/doc/rfc/rfc8225.txt
new file mode 100644
index 0000000..ec0ffd3
--- /dev/null
+++ b/doc/rfc/rfc8225.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          C. Wendt
+Request for Comments: 8225                                       Comcast
+Category: Standards Track                                    J. Peterson
+ISSN: 2070-1721                                             Neustar Inc.
+                                                           February 2018
+
+
+                   PASSporT: Personal Assertion Token
+
+Abstract
+
+   This document defines a method for creating and validating a token
+   that cryptographically verifies an originating identity or, more
+   generally, a URI or telephone number representing the originator of
+   personal communications.  The Personal Assertion Token, PASSporT, is
+   cryptographically signed to protect the integrity of the identity of
+   the originator and to verify the assertion of the identity
+   information at the destination.  The cryptographic signature is
+   defined with the intention that it can confidently verify the
+   originating persona even when the signature is sent to the
+   destination party over an insecure channel.  PASSporT is particularly
+   useful for many personal-communications applications over IP networks
+   and other multi-hop interconnection scenarios where the originating
+   and destination parties may not have a direct trusted relationship.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8225.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wendt & Peterson             Standards Track                    [Page 1]
+
+RFC 8225                        PASSporT                   February 2018
+
+
+Copyright Notice
+
+   Copyright (c) 2018 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wendt & Peterson             Standards Track                    [Page 2]
+
+RFC 8225                        PASSporT                   February 2018
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+   2. Terminology .....................................................4
+   3. PASSporT Overview ...............................................5
+   4. PASSporT Header .................................................6
+      4.1. "typ" (Type) Header Parameter ..............................6
+      4.2. "alg" (Algorithm) Header Parameter .........................6
+      4.3. "x5u" (X.509 URL) Header Parameter .........................6
+      4.4. Example PASSporT Header ....................................7
+   5. PASSporT Payload ................................................7
+      5.1. JWT-Defined Claims .........................................7
+           5.1.1. "iat" (Issued At) Claim .............................7
+      5.2. PASSporT-Specific Claims ...................................8
+           5.2.1. Originating and Destination Identity Claims .........8
+           5.2.2. "mky" (Media Key) Claim ............................10
+   6. PASSporT Signature .............................................11
+   7. Compact Form of PASSporT .......................................12
+      7.1. Example Compact Form of PASSporT ..........................13
+   8. Extending PASSporT .............................................13
+      8.1. "ppt" (PASSporT) Header Parameter .........................13
+      8.2. Example Extended PASSporT Header ..........................14
+      8.3. Extended PASSporT Claims ..................................14
+   9. Deterministic JSON Serialization ...............................15
+      9.1. Example PASSporT Deterministic JSON Form ..................16
+   10. Security Considerations .......................................17
+      10.1. Avoidance of Replay and Cut-and-Paste Attacks ............17
+      10.2. Solution Considerations ..................................18
+   11. IANA Considerations ...........................................18
+      11.1. Media Type Registration ..................................18
+      11.2. Registrations in "JSON Web Token Claims" .................19
+      11.3. Registration in "JSON Web Signature and
+            Encryption Header Parameters" ............................20
+      11.4. PASSporT Extensions Registry .............................20
+   12. References ....................................................20
+      12.1. Normative References .....................................20
+      12.2. Informative References ...................................22
+   Appendix A. Example ES256-Based PASSporT JWS Serialization and
+               Signature .............................................23
+     A.1. X.509 Private Key in PKCS #8 Format for ES256 Example ......24
+     A.2. X.509 Public Key for ES256 Example .........................25
+   Acknowledgments ...................................................25
+   Authors' Addresses ................................................25
+
+
+
+
+
+
+
+
+Wendt & Peterson             Standards Track                    [Page 3]
+
+RFC 8225                        PASSporT                   February 2018
+
+
+1.  Introduction
+
+   In today's IP-enabled telecommunications world, there is a growing
+   concern about the ability to trust incoming invitations for
+   communications sessions, including video, voice, and messaging
+   [RFC7340].  As an example, modern telephone networks provide the
+   ability to spoof the calling party's telephone number for many
+   legitimate purposes, including providing network features and
+   services on behalf of a legitimate telephone number.  However, as we
+   have seen, bad actors have taken advantage of this ability for
+   illegitimate and fraudulent purposes meant to trick telephone users
+   into believing that they are someone they are not.  This problem can
+   be extended to many emerging forms of personal communications.
+
+   This document defines a method for creating and validating a token
+   that cryptographically verifies an originating identity or, more
+   generally, a URI or telephone number representing the originator of
+   personal communications.  Through the extensions defined in Section 8
+   of this document, other information relevant to the personal
+   communications can also be added to the token.  The goal of PASSporT
+   is to provide a common framework for signing information related to
+   the originating identity in an extensible way.  Additionally, this
+   functionality is independent of any specific call logic for
+   personal-communications signaling, so that the assertion of
+   information related to the originating identity can be implemented in
+   a flexible way and can be used in such applications as end-to-end
+   applications that require different signaling protocols or gateways
+   between different communications systems.  It is anticipated that
+   guidance specific to the signaling protocol will be provided in other
+   related documents and specifications to specify how to use and
+   transport PASSporTs; however, this is intentionally out of scope for
+   this document.
+
+   [RFC8224] provides details of the use of PASSporT within the SIP
+   [RFC3261] signaling protocol for the signing and verification of
+   telephone numbers and SIP URIs.
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+
+
+
+
+
+
+Wendt & Peterson             Standards Track                    [Page 4]
+
+RFC 8225                        PASSporT                   February 2018
+
+
+3.  PASSporT Overview
+
+   "JSON Web Token (JWT)" [RFC7519], "JSON Web Signature (JWS)"
+   [RFC7515], and other related specifications define a standard token
+   format that can be used as a way of encapsulating claimed or asserted
+   information with an associated digital signature using X.509-based
+   certificates.  JWT provides a set of claims in JSON format that can
+   conveniently accommodate asserted originating-identity information
+   and that are easily extensible for use in the extension mechanisms
+   defined below.  Additionally, JWS provides a path for updating
+   methods and cryptographic algorithms used for the associated digital
+   signatures.
+
+   JWS defines the use of JSON data structures in a specified canonical
+   format for signing data corresponding to the JSON Object Signing and
+   Encryption (JOSE) Header, JWS Payload, and JWS Signature.  JWT
+   defines a set of claims that are represented by specified JSON
+   objects that can be extended with custom keys for specific
+   applications.  The next sections define the header and claims that
+   MUST be minimally used with JWT and JWS for PASSporT.
+
+   PASSporT specifically uses this token format and defines claims that
+   convey the identity of the origination and destination of personal
+   communications.  The primary value asserted in a PASSporT object is
+   the originating identity representing the identity of the calling
+   party or the initiator of a personal-communications session.  The
+   signer of a PASSporT object may or may not correspond to the
+   originating identity.  For a given application's use or using
+   protocol of PASSporT, the creation of the PASSporT object is
+   performed by an entity that is authoritative to assert the caller's
+   identity.  This authority is represented by the certificate
+   credentials and the signature, and the PASSporT object is created and
+   initiated to the destination(s) per the application's choice of
+   authoritative point(s) in the network.  For example, the PASSporT
+   object could be created at a device that has authenticated with a
+   user or at a network entity with an authenticated trust relationship
+   with that device and its user.  Destination identities represent the
+   intended destination of the personal communications, i.e., the
+   identity(s) being called by the caller.  The destination point or
+   points determined by the application need to have the capability to
+   verify the PASSporT and the digital signature.  The PASSporT-
+   associated certificate is used to validate the authority of the
+   originating signer, generally via a certificate chain to the trust
+   anchor for that application.
+
+
+
+
+
+
+
+Wendt & Peterson             Standards Track                    [Page 5]
+
+RFC 8225                        PASSporT                   February 2018
+
+
+4.  PASSporT Header
+
+   The JWS token header is a JOSE Header ([RFC7515], Section 4) that
+   defines the type and encryption algorithm used in the token.
+
+   The PASSporT header should include, at a minimum, the Header
+   Parameters defined in the next three subsections.
+
+4.1.  "typ" (Type) Header Parameter
+
+   The "typ" (Type) Header Parameter is defined in JWS ([RFC7515],
+   Section 4.1.9) to declare the media type of the complete JWS.
+
+   For the PASSporT, the "typ" header MUST be the string "passport".
+   This signifies that the encoded token is a JWT of type "passport".
+
+4.2.  "alg" (Algorithm) Header Parameter
+
+   The "alg" (Algorithm) Header Parameter is defined in JWS ([RFC7515],
+   Section 4.1.1).  This definition includes the ability to specify the
+   use of a cryptographic algorithm for the signature part of the JWS.
+   It also refers to a list of defined "alg" values as part of a
+   registry established by JSON Web Algorithms (JWA) ([RFC7518],
+   Section 3.1).
+
+   For the creation and verification of PASSporTs and their digital
+   signatures, implementations MUST support ES256 as defined in JWA
+   ([RFC7518], Section 3.4).  Implementations MAY support other
+   algorithms registered in the "JSON Web Signature and Encryption
+   Algorithms" registry created by [RFC7518].  The contents of that
+   registry may be updated in the future, depending on cryptographic
+   strength requirements guided by current security best practices.  The
+   mandatory-to-support algorithm for PASSporTs may likewise be updated
+   in future updates to this document.
+
+   Implementations of PASSporT digital signatures using ES256 as defined
+   above SHOULD use the deterministic Elliptic Curve Digital Signature
+   Algorithm (ECDSA) if or when supported for the reasons stated in
+   [RFC6979].
+
+4.3.  "x5u" (X.509 URL) Header Parameter
+
+   As defined in JWS ([RFC7515], Section 4.1.5), the "x5u" Header
+   Parameter defines a URI [RFC3986] referring to the resource for the
+   X.509 public key certificate or certificate chain [RFC5280]
+   corresponding to the key used to digitally sign the JWS.  Generally,
+   as defined in JWS ([RFC7515], Section 4.1.5), this would correspond
+   to an HTTPS or DNSSEC resource using integrity protection.
+
+
+
+Wendt & Peterson             Standards Track                    [Page 6]
+
+RFC 8225                        PASSporT                   February 2018
+
+
+4.4.  Example PASSporT Header
+
+   An example of the header would be the following, including the
+   specified passport type, ES256 algorithm, and a URI referencing the
+   network location of the certificate needed to validate the PASSporT
+   signature.
+
+   {
+     "typ":"passport",
+     "alg":"ES256",
+     "x5u":"https://cert.example.org/passport.cer"
+   }
+
+5.  PASSporT Payload
+
+   The token claims consist of the information that needs to be verified
+   at the destination party.  These claims follow the definition of a
+   JWT claim ([RFC7519], Section 4) and are encoded as defined by the
+   JWS Payload ([RFC7515], Section 3).
+
+   PASSporT defines the use of a standard JWT-defined claim as well as
+   custom claims corresponding to the two parties associated with
+   personal communications -- the originator and destination, as
+   detailed below.
+
+   For PASSporT, any claim names MUST use the ASCII character set.  Any
+   claim values can contain characters that are outside the ASCII range,
+   consistent with the rules of creating a JWT Claims Set as defined in
+   [RFC7519], Section 7.1.
+
+5.1.  JWT-Defined Claims
+
+5.1.1.  "iat" (Issued At) Claim
+
+   The JSON claim MUST include the "iat" (Issued At) claim ([RFC7519],
+   Section 4.1.6).  As defined, the "iat" claim should be set to the
+   date and time of issuance of the JWT and MUST indicate the date and
+   time of the origination of the personal communications.  The time
+   value should be of the NumericDate format as defined in [RFC7519],
+   Section 2.  This is included for securing the token against replay
+   and cut-and-paste attacks, as explained further in Section 10
+   ("Security Considerations").
+
+
+
+
+
+
+
+
+
+Wendt & Peterson             Standards Track                    [Page 7]
+
+RFC 8225                        PASSporT                   February 2018
+
+
+5.2.  PASSporT-Specific Claims
+
+5.2.1.  Originating and Destination Identity Claims
+
+   The originating identity and the destination identity are represented
+   by two claims that are required for PASSporT -- the "orig" and "dest"
+   claims.  Both "orig" and "dest" MUST contain claim values that are
+   identity claim JSON objects where the child claim name represents an
+   identity type and the claim value is the identity string, both
+   defined in subsequent subsections.  Currently, these identities can
+   be represented as either telephone numbers or Uniform Resource
+   Indicators (URIs).
+
+   The "orig" claim is a JSON object with the claim name of "orig" and a
+   claim value that is a JSON object representing the asserted identity
+   of any type (currently either "tn" or "uri") of the originator of the
+   personal-communications signaling.  There MUST be exactly one "orig"
+   claim with exactly one identity claim object in a PASSporT object.
+
+   Note: As explained in Section 3, the originating identity represents
+   the calling party and may or may not correspond to the authoritative
+   signer of the token.
+
+   The "dest" claim is a JSON object with the claim name of "dest" and
+   MUST have at least one identity claim object.  The "dest" claim value
+   is an array containing one or more identity claim JSON objects
+   representing the destination identities of any type (currently "tn"
+   or "uri").  If the "dest" claim value array contains both "tn" and
+   "uri" claim names, the JSON object should list the "tn" array first
+   and the "uri" array second.  Within the "tn" and "uri" arrays, the
+   identity strings should be put in lexicographical order, including
+   the scheme-specific portion of the URI characters.
+
+   Note: As explained in Section 3, the destination identity represents
+   the called party and may or may not correspond to the authoritative
+   party verifying the token signature.
+
+5.2.1.1.  "tn" (Telephone Number) Identity
+
+   If the originating or destination identity is a telephone number, the
+   claim name representing the identity MUST be "tn".
+
+   The claim value for the "tn" claim is the telephone number and MUST
+   be canonicalized according to the procedures specified in [RFC8224],
+   Section 8.3.
+
+
+
+
+
+
+Wendt & Peterson             Standards Track                    [Page 8]
+
+RFC 8225                        PASSporT                   February 2018
+
+
+5.2.1.2.  "uri" (URI) Identity
+
+   If any of the originating or destination identities is in the form of
+   a URI as defined in [RFC3986], the claim name representing the
+   identity MUST be "uri", and the claim value is the URI form of the
+   identity.
+
+5.2.1.3.  Future Identity Forms
+
+   We recognize that in the future there may be other standard
+   mechanisms for representing identities.  The "orig" and "dest" claims
+   currently support "tn" and "uri" but could be extended in the future
+   to allow for other identity types with new IANA-registered unique
+   types to represent these forms.
+
+5.2.1.4.  Examples
+
+   The following is an example of a single originator with telephone
+   number identity +12155551212, to a single destination with URI
+   identity "sip:alice@example.com":
+
+   {
+     "dest":{"uri":["sip:alice@example.com"]},
+     "iat":1443208345,
+     "orig":{"tn":"12155551212"}
+   }
+
+   The following is an example of a single originator with telephone
+   number identity +12155551212, to multiple destination identities with
+   telephone number identity +12125551212 and two URI identities --
+   "sip:alice@example.com" and "sip:bob@example.com":
+
+   {
+     "dest":{
+       "tn":["12125551212"],
+       "uri":["sip:alice@example.com",
+         "sip:bob@example.net"]
+     },
+     "iat":1443208345,
+     "orig":{"tn":"12155551212"}
+   }
+
+
+
+
+
+
+
+
+
+
+Wendt & Peterson             Standards Track                    [Page 9]
+
+RFC 8225                        PASSporT                   February 2018
+
+
+5.2.2.  "mky" (Media Key) Claim
+
+   Some protocols that use PASSporT may also want to protect media
+   security keys delivered within their signaling in order to bind those
+   keys to the identities established in the signaling layers.  The
+   "mky" claim is an optional PASSporT claim defining the assertion of
+   media key fingerprints carried in the Session Description Protocol
+   (SDP) [RFC4566] via the "a=fingerprint" attribute ([RFC4572],
+   Section 5).  This claim can support either a single fingerprint or
+   multiple fingerprints appearing in a single SDP body corresponding to
+   one or more media streams offered as defined in [RFC8122].
+
+   The "mky" claim MUST be formatted as a JSON object with an array that
+   includes the "alg" and "dig" claims with the corresponding algorithm
+   and hexadecimal values.  If there is more than one fingerprint value
+   associated with different media streams in SDP, the fingerprint
+   values MUST be constructed as a JSON array denoted by square brackets
+   ("[" and "]").  For the "dig" claim, the claim value MUST be the hash
+   of the hexadecimal value without any colons.
+
+   The "mky" claim is a JSON object with a claim name of "mky" and a
+   claim value of a JSON array denoted by brackets.  The "mky" claim
+   value JSON array MUST be constructed as follows:
+
+   1.  Take each "a=fingerprint" line carried in the SDP.
+
+   2.  Sort the lines based on the UTF-8 [RFC3629] encoding of the
+       concatenation of the "alg" and "dig" claim value strings.
+
+   3.  Encode the array in the order of the sorted lines, where each
+       "mky" array element is a JSON object with two elements
+       corresponding to the "alg" and "dig" objects, with "alg" first
+       and "dig" second.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wendt & Peterson             Standards Track                   [Page 10]
+
+RFC 8225                        PASSporT                   February 2018
+
+
+   An example claim with the "mky" claim is as follows:
+
+   For an SDP offer that includes the following fingerprint values,
+
+   a=fingerprint:sha-256 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:
+   5D:49:6B:19:E5:7C:AB:3E:4B:65:2E:7D:46:3F:54:42:CD:54:F1
+   a=fingerprint:sha-256 02:1A:CC:54:27:AB:EB:9C:53:3F:3E:4B:65
+   :2E:7D:46:3F:54:42:CD:54:F1:7A:03:A2:7D:F9:B0:7F:46:19:B2
+
+   the PASSporT Payload object would be:
+
+   {
+     "dest":{"uri":["sip:alice@example.com"]},
+     "iat":1443208345,
+     "mky":[
+       {
+         "alg":"sha-256",
+         "dig":"021ACC5427ABEB9C533F3E4B652E7D463F5442CD54
+           F17A03A27DF9B07F4619B2"
+       },
+       {
+         "alg":"sha-256",
+         "dig":"4AADB9B13F82183B540212DF3E5D496B19E57C
+           AB3E4B652E7D463F5442CD54F1"
+       }
+     ],
+     "orig":{"tn":"12155551212"}
+   }
+
+6.  PASSporT Signature
+
+   The signature of the PASSporT is created as specified by JWS
+   ([RFC7515], Section 5.1, Steps 1 through 6).  PASSporT MUST use the
+   JWS Protected Header.  For the JWS Payload and the JWS Protected
+   Header, however, the lexicographic ordering and whitespace rules
+   described in Sections 4 and 5 of this document, and the JSON
+   serialization rules in Section 9 of this document, MUST be followed.
+
+   Appendix A of this document has a detailed example of how to follow
+   the steps to create the JWS Signature.
+
+   Step 7 of the JSON serialization procedure in [RFC7515], Section 5.1
+   is not supported for PASSporT.
+
+   [RFC7515], Section 5.1, Step 8 describes the method to create the
+   final JWS Compact Serialization form of the PASSporT.
+
+
+
+
+
+Wendt & Peterson             Standards Track                   [Page 11]
+
+RFC 8225                        PASSporT                   February 2018
+
+
+7.  Compact Form of PASSporT
+
+   For a using protocol of PASSporT, the PASSporT claims as well as the
+   PASSporT header may include redundant or default information that
+   could be reconstructed at the destination based on information
+   provided in the signaling protocol transporting the PASSporT object.
+   In this case, it may be advantageous to have a more compact form of
+   PASSporT to save the transmission of the bytes needed to represent
+   the header and claims.
+
+   This specification defines the compact form of the PASSporT, in the
+   spirit of the form defined in [RFC7515], Appendix F, with the use of
+   two periods ("..") to represent the header and claim objects being
+   removed, followed by the PASSporT signature as defined in Section 6,
+   and the need for the destination to reconstruct the header and claim
+   objects in order to verify the signature.
+
+   In order to construct the compact form of the PASSporT string, the
+   procedure described in Section 6 MUST be used, with the exception of
+   [RFC7515], Section 5.1, Step 8.  This step would be replaced by the
+   following construction of the compact form of PASSporT, ".." ||
+   BASE64URL(JWS Signature).
+
+   The using protocol of the compact form of PASSporT MUST be
+   accompanied by a specification for how the header and claims objects
+   can be reconstructed from information in the signaling protocol being
+   used.
+
+   Note that the full form of the PASSporT, containing the entire
+   header, payload, and signature, should also use the lexicographic
+   ordering and whitespace serialization rules, particularly in the case
+   where some using protocols or interworking between protocols may
+   require switching between full and compact forms and maintaining the
+   integrity of the signature.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wendt & Peterson             Standards Track                   [Page 12]
+
+RFC 8225                        PASSporT                   February 2018
+
+
+7.1.  Example Compact Form of PASSporT
+
+   The compact form of the following example token (with line breaks
+   between periods used for readability purposes only)
+
+   eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9j
+   ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9
+   .
+   eyJkZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI
+   6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0
+   .
+   rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYsojN
+   CpTzO3QfPOlckGaS6hEck7w
+
+   would be as follows:
+
+   ..rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYsojN
+   CpTzO3QfPOlckGaS6hEck7w
+
+8.  Extending PASSporT
+
+   PASSporT includes the bare-minimum set of claims needed to securely
+   assert the originating identity and support the secure properties
+   discussed in various parts of this document.  JWT supports a
+   straightforward way to add additional asserted or signed information
+   by simply adding new claims.  PASSporT can be extended beyond the
+   defined base set of claims to represent other information requiring
+   assertion or validation beyond the originating identity itself as
+   needed.
+
+8.1.  "ppt" (PASSporT) Header Parameter
+
+   Any using protocol can extend the payload of PASSporT with additional
+   JWT claims.  JWT claims are managed by the "JSON Web Token Claims"
+   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 that 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".
+
+
+
+
+
+
+
+Wendt & Peterson             Standards Track                   [Page 13]
+
+RFC 8225                        PASSporT                   February 2018
+
+
+   Using protocols MUST explicitly define how they carry each claim 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 (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.
+
+8.2.  Example Extended PASSporT Header
+
+   An example header with a PASSporT extension type of "foo" is as
+   follows:
+
+   {
+     "alg":"ES256",
+     "ppt":"foo",
+     "typ":"passport",
+     "x5u":"https://tel.example.org/passport.cer"
+   }
+
+8.3.  Extended PASSporT Claims
+
+   Specifications that define extensions to the PASSporT mechanism MUST
+   explicitly specify what claims they include beyond the base set of
+   claims from this document, the order in which they will appear, and
+   any further information necessary to implement the extension.  All
+   extensions MUST include the baseline PASSporT claim elements
+   specified in Section 5; claims may only be appended to the claims
+   object specified; they can never be removed or reordered.  Specifying
+   new claims follows the baseline JWT procedures ([RFC7519],
+   Section 10.1).  Understanding an extension or new claims defined by
+   the extension on the destination verification of the PASSporT is
+   optional.  The creator of a PASSporT object cannot assume that
+   destination systems will understand any given extension.
+   Verification of PASSporTs by destination systems that do support an
+   extension may then trigger appropriate application-level behavior in
+   the presence of an extension; authors of extensions should provide
+   appropriate extension-specific guidance to application developers on
+   this point.
+
+
+
+
+
+
+Wendt & Peterson             Standards Track                   [Page 14]
+
+RFC 8225                        PASSporT                   February 2018
+
+
+   An example set of extended claims, extending the first example in
+   Section 5.2.1.4 using "bar" as the newly defined claim, would be as
+   follows:
+
+   {
+     "bar":"beyond all recognition"
+     "dest":{"uri":["sip:alice@example.com"]},
+     "iat":1443208345,
+     "orig":{"tn":"12155551212"}
+   }
+
+9.  Deterministic JSON Serialization
+
+   JSON objects can include spaces and line breaks, and key value pairs
+   can occur in any order.  It is therefore a non-deterministic string
+   format.  In order to make the digital signature verification work
+   deterministically, the JSON representation of the JWS Protected
+   Header object and JWS Payload object MUST be computed as follows.
+
+   The JSON object MUST follow the following rules.  These rules are
+   based on the thumbprint of a JSON Web Key (JWK) as defined in
+   Section 3 Step 1 of [RFC7638].
+
+   1.  The JSON object MUST contain no whitespace or line breaks before
+       or after any syntactic elements.
+
+   2.  JSON objects MUST have the keys ordered lexicographically by the
+       Unicode [UNICODE] code points of the member names.
+
+   3.  JSON value literals MUST be lowercase.
+
+   4.  JSON numbers are to be encoded as integers unless the field is
+       defined to be encoded otherwise.
+
+   5.  Encoding rules MUST be applied recursively to member values and
+       array values.
+
+   Note: For any PASSporT extension claims, member names within the
+   scope of a JSON object MUST NOT be equal to other member names;
+   otherwise, serialization will not be deterministic.
+
+
+
+
+
+
+
+
+
+
+
+Wendt & Peterson             Standards Track                   [Page 15]
+
+RFC 8225                        PASSporT                   February 2018
+
+
+9.1.  Example PASSporT Deterministic JSON Form
+
+   This section demonstrates the deterministic JSON serialization for
+   the example PASSporT Payload shown in Section 5.2.1.4.
+
+   The initial JSON object is shown here:
+
+   {
+     "dest":{"uri":["sip:alice@example.com"]},
+     "orig":{"tn":"12155551212"}
+     "iat":1443208345,
+     "mky":[
+       {
+         "alg":"sha-256",
+         "dig":"021ACC5427ABEB9C533F3E4B652E7D463F5442CD54
+           F17A03A27DF9B07F4619B2"
+       },
+       {
+         "alg":"sha-256",
+         "dig":"4AADB9B13F82183B540212DF3E5D496B19E57C
+           AB3E4B652E7D463F5442CD54F1"
+       }
+     ],
+   }
+
+   The parent members of the JSON object are as follows:
+
+   o  "dest"
+
+   o  "orig"
+
+   o  "iat"
+
+   o  "mky"
+
+   Their lexicographic order is:
+
+   o  "dest"
+
+   o  "iat"
+
+   o  "mky"
+
+   o  "orig"
+
+
+
+
+
+
+
+Wendt & Peterson             Standards Track                   [Page 16]
+
+RFC 8225                        PASSporT                   February 2018
+
+
+   The final constructed deterministic JSON serialization
+   representation, with whitespace and line breaks removed (with line
+   breaks used for display purposes only), is:
+
+   {"dest":{"uri":["sip:alice@example.com"],"iat":1443208345,"mky":
+   [{"alg":"sha-256","dig":"021ACC5427ABEB9C533F3E4B652E7D463F5442CD5
+   4F17A03A27DF9B07F4619B2"},{"alg":"sha-256","dig":"4AADB9B13F82183B5
+   40212DF3E5D496B19E57CAB3E4B652E7D463F5442CD54F1"}],
+   "orig":{"tn":"12155551212"}}
+
+10.  Security Considerations
+
+10.1.  Avoidance of Replay and Cut-and-Paste Attacks
+
+   There are a number of security considerations regarding the use of
+   the token for the avoidance of replay and cut-and-paste attacks.
+   PASSporTs SHOULD only be sent with application-level protocol
+   information (e.g., for SIP, an INVITE as defined in [RFC3261])
+   corresponding to the required fields in the token.  A unique set of
+   token claims and token signature is constructed using the originating
+   identity being asserted with the "orig" claim along with the
+   following two claims:
+
+   o  The "iat" claim should correspond to a date/time that the message
+      was originated.  It should also be within a relative time that is
+      reasonable for clock drift and transmission time characteristics
+      associated with the application using the PASSporT.  Therefore,
+      validation of the token should consider date and time correlation,
+      which could be influenced by usage specific to the signaling
+      protocol and by network time differences.
+
+   o  The "dest" claim is included to further restrict the use of a
+      valid PASSporT being sent as a replay attack to other destination
+      parties.  The verification of the PASSporT at the destination
+      should verify that the "dest" claim matches the destination party
+      as the intended recipient of the message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wendt & Peterson             Standards Track                   [Page 17]
+
+RFC 8225                        PASSporT                   February 2018
+
+
+10.2.  Solution Considerations
+
+   The use of PASSporTs based on the validation of the digital signature
+   and the associated certificate requires consideration of the
+   authentication and authority or reputation of the signer to attest to
+   the identity being asserted.  The following considerations should be
+   recognized when using PASSporT:
+
+   o  The use of this token should not, in its own right, be considered
+      a full solution for absolute non-repudiation of the identity being
+      asserted.
+
+   o  In many applications, the signer and the end user represented by
+      the asserted identity may not be one and the same.  For example,
+      when a service provider signs and validates the token on behalf of
+      the user consuming the service, the provider MUST have an
+      authenticated and secure relationship with the end user or the
+      device initiating and terminating the communications signaling.
+
+   o  Applications that use PASSporT should ensure that the verification
+      of the signature includes a means for verifying that the signer is
+      authoritative through the use of an application-specific or
+      service-specific set of common trust anchors for the application.
+
+11.  IANA Considerations
+
+11.1.  Media Type Registration
+
+   This section registers the "application/passport" media type (see
+   [RFC2046] for the definition of "media type") in the "Media Types"
+   registry in the manner described in [RFC6838], to indicate that the
+   content is a PASSporT-defined JWT.
+
+   o  Type name: application
+
+   o  Subtype name: passport
+
+   o  Required parameters: N/A
+
+   o  Optional parameters: N/A
+
+   o  Encoding considerations: 8bit; application/passport values are
+      encoded as a series of base64url-encoded values (some of which may
+      be the empty string) separated by period (".") characters.
+
+   o  Security considerations: See the Security Considerations section
+      of [RFC7515].
+
+
+
+
+Wendt & Peterson             Standards Track                   [Page 18]
+
+RFC 8225                        PASSporT                   February 2018
+
+
+   o  Interoperability considerations: N/A
+
+   o  Published specification: RFC 8225
+
+   o  Applications that use this media type: Secure Telephone Identity
+      Revisited (STIR) and other applications that require
+      identity-related assertion
+
+   o  Fragment identifier considerations: N/A
+
+   o  Additional information:
+
+         Magic number(s): N/A
+
+         File extension(s): N/A
+
+         Macintosh file type code(s): N/A
+
+   o  Person & email address to contact for further information: Chris
+      Wendt, chris-ietf@chriswendt.net
+
+   o  Intended usage: COMMON
+
+   o  Restrictions on usage: none
+
+   o  Author: Chris Wendt <chris-ietf@chriswendt.net>
+
+   o  Change Controller: IESG
+
+   o  Provisional registration?  No
+
+11.2.  Registrations in "JSON Web Token Claims"
+
+   Claim Name: "orig"
+   Claim Description: Originating Identity String
+   Change Controller: IESG
+   Reference: Section 5.2.1 of RFC 8225
+
+   Claim Name: "dest"
+   Claim Description: Destination Identity String
+   Change Controller: IESG
+   Reference: Section 5.2.1 of RFC 8225
+
+   Claim Name: "mky"
+   Claim Description: Media Key Fingerprint String
+   Change Controller: IESG
+   Reference: Section 5.2.2 of RFC 8225
+
+
+
+
+Wendt & Peterson             Standards Track                   [Page 19]
+
+RFC 8225                        PASSporT                   February 2018
+
+
+11.3.  Registration in "JSON Web Signature and Encryption Header
+       Parameters"
+
+   Header Parameter Name: "ppt"
+   Header Parameter Description: PASSporT extension identifier
+   Header Parameter Usage Location(s): JWS
+   Change Controller: IESG
+   Reference: Section 8.1 of RFC 8225
+
+11.4.  PASSporT Extensions Registry
+
+   The IANA has created a new PASSporT Type registry for "ppt" parameter
+   values.  That parameter and its values are defined in Section 8.1.
+   New registry entries must contain the name of the "ppt" parameter
+   value and the specification in which the value is described.  The
+   policy for this registry is Specification Required [RFC8126].
+
+12.  References
+
+12.1.  Normative References
+
+   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+              Extensions (MIME) Part Two: Media Types", RFC 2046,
+              DOI 10.17487/RFC2046, November 1996,
+              <https://www.rfc-editor.org/info/rfc2046>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of
+              ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629,
+              November 2003, <https://www.rfc-editor.org/info/rfc3629>.
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66,
+              RFC 3986, DOI 10.17487/RFC3986, January 2005,
+              <https://www.rfc-editor.org/info/rfc3986>.
+
+   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+              Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
+              July 2006, <https://www.rfc-editor.org/info/rfc4566>.
+
+
+
+
+
+
+
+
+Wendt & Peterson             Standards Track                   [Page 20]
+
+RFC 8225                        PASSporT                   February 2018
+
+
+   [RFC4572]  Lennox, J., "Connection-Oriented Media Transport over the
+              Transport Layer Security (TLS) Protocol in the Session
+              Description Protocol (SDP)", RFC 4572,
+              DOI 10.17487/RFC4572, July 2006,
+              <https://www.rfc-editor.org/info/rfc4572>.
+
+   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
+              Specifications and Registration Procedures", BCP 13,
+              RFC 6838, DOI 10.17487/RFC6838, January 2013,
+              <https://www.rfc-editor.org/info/rfc6838>.
+
+   [RFC6979]  Pornin, T., "Deterministic Usage of the Digital Signature
+              Algorithm (DSA) and Elliptic Curve Digital Signature
+              Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979,
+              August 2013, <https://www.rfc-editor.org/info/rfc6979>.
+
+   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
+              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515,
+              May 2015, <https://www.rfc-editor.org/info/rfc7515>.
+
+   [RFC7518]  Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
+              DOI 10.17487/RFC7518, May 2015,
+              <https://www.rfc-editor.org/info/rfc7518>.
+
+   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
+              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
+              <https://www.rfc-editor.org/info/rfc7519>.
+
+   [RFC7638]  Jones, M. and N. Sakimura, "JSON Web Key (JWK)
+              Thumbprint", RFC 7638, DOI 10.17487/RFC7638,
+              September 2015, <https://www.rfc-editor.org/info/rfc7638>.
+
+   [RFC8122]  Lennox, J. and C. Holmberg, "Connection-Oriented Media
+              Transport over the Transport Layer Security (TLS) Protocol
+              in the Session Description Protocol (SDP)", RFC 8122,
+              DOI 10.17487/RFC8122, March 2017,
+              <https://www.rfc-editor.org/info/rfc8122>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in
+              RFC 2119 Key Words", BCP 14, RFC 8174,
+              DOI 10.17487/RFC8174, May 2017,
+              <https://www.rfc-editor.org/info/rfc8174>.
+
+
+
+
+
+
+
+
+
+Wendt & Peterson             Standards Track                   [Page 21]
+
+RFC 8225                        PASSporT                   February 2018
+
+
+   [RFC8224]  Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
+              "Authenticated Identity Management in the Session
+              Initiation Protocol (SIP)", RFC 8224,
+              DOI 10.17487/RFC8224, February 2018,
+              <https://www.rfc-editor.org/info/rfc8224>.
+
+   [UNICODE]  The Unicode Consortium, "The Unicode Standard",
+              <http://www.unicode.org/versions/latest/>.
+
+12.2.  Informative References
+
+   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+              A., Peterson, J., Sparks, R., Handley, M., and E.
+              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+              DOI 10.17487/RFC3261, June 2002,
+              <https://www.rfc-editor.org/info/rfc3261>.
+
+   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+              Housley, R., and W. Polk, "Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
+              <https://www.rfc-editor.org/info/rfc5280>.
+
+   [RFC7340]  Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
+              Telephone Identity Problem Statement and Requirements",
+              RFC 7340, DOI 10.17487/RFC7340, September 2014,
+              <https://www.rfc-editor.org/info/rfc7340>.
+
+   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+              Writing an IANA Considerations Section in RFCs", BCP 26,
+              RFC 8126, DOI 10.17487/RFC8126, June 2017,
+              <https://www.rfc-editor.org/info/rfc8126>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wendt & Peterson             Standards Track                   [Page 22]
+
+RFC 8225                        PASSporT                   February 2018
+
+
+Appendix A.  Example ES256-Based PASSporT JWS Serialization and
+             Signature
+
+   For PASSporT, there will always be a JWS with the following members:
+
+   o  "protected", with the value BASE64URL(UTF8(JWS Protected Header))
+
+   o  "payload", with the value BASE64URL(JWS Payload)
+
+   o  "signature", with the value BASE64URL(JWS Signature)
+
+   This example will follow the steps in JWS ([RFC7515], Section 5.1,
+   Steps 1-6 and 8); it incorporates the additional serialization steps
+   required for PASSporT.
+
+   Step 1 for JWS references the JWS Payload.  An example PASSporT
+   Payload is as follows:
+
+   {
+     "dest":{"uri":["sip:alice@example.com"]}
+     "iat":1471375418,
+     "orig":{"tn":"12155551212"}
+   }
+
+   This would be serialized to the following form (with line break used
+   for display purposes only):
+
+   {"dest":{"uri":["sip:alice@example.com"]},"iat":1471375418,
+   "orig":{"tn":"12155551212"}}
+
+   Step 2 computes the BASE64URL(JWS Payload), producing this value
+   (with line break used for display purposes only):
+
+   eyJkZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI
+   6MTQ3MTM3NTQxOCwib3JpZyI6eyJ0biI6IjEyMTU1NTUxMjEyIn19
+
+   For Step 3, an example PASSporT Protected Header constructed as a
+   JOSE Header is as follows:
+
+   {
+     "alg":"ES256",
+     "typ":"passport",
+     "x5u":"https://cert.example.org/passport.cer"
+   }
+
+
+
+
+
+
+
+Wendt & Peterson             Standards Track                   [Page 23]
+
+RFC 8225                        PASSporT                   February 2018
+
+
+   This would be serialized to the following form (with line break used
+   for display purposes only):
+
+   {"alg":"ES256","typ":"passport","x5u":"https://cert.example.org
+     /passport.cer"}
+
+   Step 4 performs the BASE64URL(UTF8(JWS Protected Header)) operation
+   and encoding, producing this value (with line break used for display
+   purposes only):
+
+   eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9j
+   ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9
+
+   Steps 5 and 6 perform the computation of the digital signature of the
+   PASSporT Signing Input ASCII(BASE64URL(UTF8(JWS Protected Header)) ||
+   "." || BASE64URL(JWS Payload)), using ES256 as the algorithm and the
+   BASE64URL(JWS Signature).
+
+   VLBCIVDCaeK6M4hLJb6SHQvacAQVvoiiEOWQ_iUkqk79UD81fHQ0E1b3_GluIkb
+   a7UWYRM47ZbNFdOJquE35cw
+
+   Step 8 describes how to create the final PASSporT, concatenating the
+   values in the order Header.Payload.Signature with period (".")
+   characters.  For the above example values, this would produce the
+   following (with line breaks between periods used for readability
+   purposes only):
+
+   eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9j
+   ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9
+   .
+   eyJkZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI
+   6MTQ3MTM3NTQxOCwib3JpZyI6eyJ0biI6IjEyMTU1NTUxMjEyIn19
+   .
+   VLBCIVDCaeK6M4hLJb6SHQvacAQVvoiiEOWQ_iUkqk79UD81fHQ0E1b3_GluIkb
+   a7UWYRM47ZbNFdOJquE35cw
+
+A.1.  X.509 Private Key in PKCS #8 Format for ES256 Example
+
+   -----BEGIN PRIVATE KEY-----
+   MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgi7q2TZvN9VDFg8Vy
+   qCP06bETrR2v8MRvr89rn4i+UAahRANCAAQWfaj1HUETpoNCrOtp9KA8o0V79IuW
+   ARKt9C1cFPkyd3FBP4SeiNZxQhDrD0tdBHls3/wFe8++K2FrPyQF9vuh
+   -----END PRIVATE KEY-----
+
+
+
+
+
+
+
+
+Wendt & Peterson             Standards Track                   [Page 24]
+
+RFC 8225                        PASSporT                   February 2018
+
+
+A.2.  X.509 Public Key for ES256 Example
+
+   -----BEGIN PUBLIC KEY-----
+   MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8HNbQd/TmvCKwPKHkMF9fScavGeH
+   78YTU8qLS8I5HLHSSmlATLcslQMhNC/OhlWBYC626nIlo7XeebYS7Sb37g==
+   -----END PUBLIC KEY-----
+
+Acknowledgments
+
+   Particular thanks to members of the ATIS and SIP Forum NNI Task
+   Group, including Jim McEachern, Martin Dolly, Richard Shockey, John
+   Barnhill, Christer Holmberg, Victor Pascual Avila, Mary Barnes, and
+   Eric Burger, for their review, ideas, and contributions.  Thanks also
+   to Henning Schulzrinne, Russ Housley, Alan Johnston, Richard Barnes,
+   Mark Miller, Ted Hardie, Dave Crocker, Robert Sparks, and Jim Schaad
+   for valuable feedback on the technical and security aspects of the
+   document.  Additional thanks to Harsha Bellur for assistance in
+   coding the example tokens.
+
+Authors' Addresses
+
+   Chris Wendt
+   Comcast
+   One Comcast Center
+   Philadelphia, PA  19103
+   United States of America
+
+   Email: chris-ietf@chriswendt.net
+
+
+   Jon Peterson
+   Neustar Inc.
+   1800 Sutter St. Suite 570
+   Concord, CA  94520
+   United States of America
+
+   Email: jon.peterson@neustar.biz
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wendt & Peterson             Standards Track                   [Page 25]
+