idnits 2.17.1 draft-ietf-stir-passport-rcd-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 9 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Compact form of an "rcd" PASSporT claim has some restrictions that will be enumerated below, but mainly follows standard PASSporT compact form procedures. For re-construction of the "nam" claim the string for the display-name in the From header field. "jcl" and "jcd" MAY NOT be used with compact form due to integrity rules and URI reference rules in this specification leading to too restrictive of a set of constraints. Future specifications may revisit this to propose a consisent and comprehensive way of addressing integrity and security of information. -- The document date (24 April 2022) is 733 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCThis' is mentioned on line 1292, but not defined == Outdated reference: A later version (-10) exists of draft-ietf-sipcore-callinfo-rcd-04 ** Downref: Normative reference to an Informational RFC: RFC 3325 ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) ** Downref: Normative reference to an Informational RFC: RFC 7340 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Wendt 3 Internet-Draft Somos Inc. 4 Intended status: Standards Track J. Peterson 5 Expires: 26 October 2022 Neustar Inc. 6 24 April 2022 8 PASSporT Extension for Rich Call Data 9 draft-ietf-stir-passport-rcd-17 11 Abstract 13 This document extends PASSporT, a token for conveying 14 cryptographically-signed call information about personal 15 communications, to include rich meta-data about a call and caller 16 that can be signed and integrity protected, transmitted, and 17 subsequently rendered to the called party. This framework is 18 intended to include and extend caller and call specific information 19 beyond human-readable display name comparable to the "Caller ID" 20 function common on the telephone network. The JSON element defined 21 for this purpose, Rich Call Data (RCD), is an extensible object 22 defined to either be used as part of STIR or with SIP Call-Info to 23 include related information about calls that helps people decide 24 whether to answer an incoming set of communications from another 25 party. This signing of the RCD information is also enhanced with a 26 integrity mechanism that is designed to protect the authoring and 27 transport of this information between authoritative and non- 28 authoritative parties generating and signing the Rich Call Data for 29 support of different usage and content policies. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on 26 October 2022. 48 Copyright Notice 50 Copyright (c) 2022 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Revised BSD License text as 59 described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Revised BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Overview of the use of the Rich Call Data PASSporT 67 extension . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Overview of Rich Call Data Integrity . . . . . . . . . . . . 5 69 5. PASSporT Claim "rcd" Definition and Usage . . . . . . . . . . 7 70 5.1. PASSporT "rcd" Claim . . . . . . . . . . . . . . . . . . 7 71 5.1.1. "nam" key . . . . . . . . . . . . . . . . . . . . . . 7 72 5.1.2. "apn" key . . . . . . . . . . . . . . . . . . . . . . 7 73 5.1.3. "icn" key . . . . . . . . . . . . . . . . . . . . . . 8 74 5.1.4. "jcd" key . . . . . . . . . . . . . . . . . . . . . . 9 75 5.1.5. "jcl" key . . . . . . . . . . . . . . . . . . . . . . 9 76 6. "rcdi" RCD Integrity Claim Definition and Usage . . . . . . . 10 77 6.1. Creation of the "rcd" element digests . . . . . . . . . . 11 78 6.1.1. "nam" and "apn" elements . . . . . . . . . . . . . . 12 79 6.1.2. "icn" elements . . . . . . . . . . . . . . . . . . . 12 80 6.1.3. "jcd" elements . . . . . . . . . . . . . . . . . . . 12 81 6.1.4. "jcl" elements . . . . . . . . . . . . . . . . . . . 14 82 6.2. JWT Claim Constraints for "rcd" claims only . . . . . . . 15 83 7. JWT Claim Constraints usage for "rcd" and "rcdi" claims . . . 15 84 8. PASSporT "crn" claim - Call Reason Definition and Usage . . . 16 85 8.1. JWT Constraint for "crn" claim . . . . . . . . . . . . . 16 86 9. Rich Call Data Claims Usage Rules . . . . . . . . . . . . . . 17 87 9.1. "rcd" PASSporT Verification . . . . . . . . . . . . . . . 17 88 9.2. "rcdi" Integrity Verification . . . . . . . . . . . . . . 18 89 9.3. Example "rcd" PASSporTs . . . . . . . . . . . . . . . . . 18 90 10. Compact form of "rcd" PASSporT . . . . . . . . . . . . . . . 20 91 10.1. Compact form of the "rcd" PASSporT claim . . . . . . . . 20 92 10.2. Compact form of the "rcdi" PASSporT claim . . . . . . . 21 93 10.3. Compact form of the "crn" PASSporT claim . . . . . . . . 21 94 11. Further Information Associated with Callers . . . . . . . . . 21 95 12. Third-Party Uses . . . . . . . . . . . . . . . . . . . . . . 22 96 12.1. Signing as a Third Party . . . . . . . . . . . . . . . . 23 97 13. Levels of Assurance . . . . . . . . . . . . . . . . . . . . . 24 98 14. Using "rcd" in SIP . . . . . . . . . . . . . . . . . . . . . 24 99 14.1. Authentication Service Behavior . . . . . . . . . . . . 24 100 14.2. Verification Service Behavior . . . . . . . . . . . . . 25 101 15. Using "rcd" and "rcdi" as additional claims to other PASSporT 102 extensions . . . . . . . . . . . . . . . . . . . . . . . 26 103 15.1. Procedures for applying "rcd" as claims only . . . . . . 27 104 15.2. Example for applying "rcd" as claims only . . . . . . . 27 105 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 106 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 107 17.1. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 28 108 17.2. PASSporT Types . . . . . . . . . . . . . . . . . . . . . 29 109 17.3. PASSporT RCD Types . . . . . . . . . . . . . . . . . . . 29 110 18. Security Considerations . . . . . . . . . . . . . . . . . . . 29 111 18.1. The use of JWT Claim Constraints in delegate certificates 112 to exclude unauthorized claims . . . . . . . . . . . . . 30 113 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 114 19.1. Normative References . . . . . . . . . . . . . . . . . . 30 115 19.2. Informative References . . . . . . . . . . . . . . . . . 32 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 118 1. Introduction 120 PASSporT [RFC8225] is a token format based on JWT [RFC7519] for 121 conveying cryptographically-signed information about the parties 122 involved in personal communications; it is used to convey a signed 123 assertion of the identity of the participants in real-time 124 communications established via a protocol like SIP [RFC8224]. The 125 STIR problem statement [RFC7340] declared securing the display name 126 of callers outside of STIR's initial scope, so baseline STIR provides 127 no features for caller name. This specification documents an 128 optional mechanism for PASSporT and the associated STIR procedures 129 which extend PASSporT objects to protect additional elements 130 conveying richer information: information that is intended to be 131 rendered to assist a called party in determining whether to accept or 132 trust incoming communications. This includes the name of the person 133 or entity on one side of a communications session, the traditional 134 "Caller ID" of the telephone network, along with related display 135 information that would be rendered to the called party during 136 alerting, or potentially used by an automaton to determine whether 137 and how to alert a called party. 139 Traditional telephone network signaling protocols have long supported 140 delivering a 'calling name' from the originating side, though in 141 practice, the terminating side is often left to derive a name from 142 the calling party number by consulting a local address book or an 143 external database. SIP similarly can carry this information in a 144 'display-name' in the From header field value from the originating to 145 terminating side, or alternatively in the Call-Info header field. 146 However, both are unsecured fields that really cannot be trusted in 147 most interconnected SIP deployments, and therefore is a good starting 148 point for a framework that utilizes STIR techniques and procedures 149 for protecting call related information including but not limited to 150 calling name. 152 As such, the baseline use-case for this document extends PASSporT to 153 provide cryptographic protection for the "display-name" field of SIP 154 requests as well as further "rich call data" (RCD) about the caller, 155 which includes the contents of the Call-Info header field or other 156 data structures that can be added to the PASSporT. This document 157 furthermore specifies a third-party profile that would allow external 158 authorities to convey rich information associated with a calling 159 number via a new type of PASSporT. Finally, this document describes 160 how to preserve the integrity of the RCD in scenarios where there may 161 be non-authoritative users initiating and signing RCD and therefore a 162 constraint on the RCD data that a PASSporT can attest via 163 certificate-level controls. 165 2. Terminology 167 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 169 "OPTIONAL" in this document are to be interpreted as described in BCP 170 14 [RFC2119] [RFC8174] when, and only when, they appear in all 171 capitals, as shown here. 173 3. Overview of the use of the Rich Call Data PASSporT extension 175 The main intended use of the signing of Rich Call Data (RCD) using 176 STIR within SIP [RFC8224] or more generally as a PASSporT extension 177 [RFC8225] is for the entity that originates a call, either directly 178 the caller themselves, if they are authoritative, or a service 179 provider or third-party service that may be authoritative over the 180 rich call data on behalf of the caller. 182 The RCD associated with the identity of the calling party described 183 in this document is of two main categories. The first data is a more 184 traditional set of info about a caller associated with "display-name" 185 in SIP [RFC3261], typically a textual description of the caller, or 186 alternate presentation numbers often used in From Header field 187 [RFC3261] or P-Asserted-ID [RFC3325]. The second category is a set 188 of RCD that is defined as part of the jCard definitions or extensions 189 to that data. [I-D.ietf-sipcore-callinfo-rcd] describes the optional 190 use of jCard in Call-Info header field as RCD with the "jcard" Call- 191 Info purpose token. Either or both of these two types of data can be 192 incorporated into an "rcd" claim defined in this document. 194 Additionally, in relation to the description of the specific 195 communications event itself (versus the identity description in 196 previous paragraph), [I-D.ietf-sipcore-callinfo-rcd] also describes a 197 "call-reason" parameter intended for description of the intent or 198 reason for a particular call. A new PASSporT claim "crn", or call 199 reason, can contain the string or object that describes the intent of 200 the call. This claim is intentionally kept separate from the "rcd" 201 claim because it is envisioned that call reason is not the same as 202 information associated with the caller and may change on a more 203 frequent, per call, type of basis. 205 4. Overview of Rich Call Data Integrity 207 When incorporating call data that represents a user, even in 208 traditional calling name services today, often there is policy and 209 restrictions around what data is allowed to be used. Whether 210 preventing offensive language or icons or enforcing uniqueness, 211 potential trademark or copyright violations or other policy 212 enforcement, there might be the desire to pre-certify or "vet" the 213 specific use of rich call data. This document defines a mechanism 214 that allows for a direct or indirect party that controls the policy 215 to approve or certify the content, create a cryptographic digest that 216 can be used to validate that data and applies a constraint in the 217 certificate to allow the recipient and verifier to validate that the 218 specific content of the RCD is as intended at its creation and 219 approval or certification. 221 There are two mechanisms that are defined to accomplish that for two 222 distinct categories of purposes. The first of the mechanisms include 223 the definition of an integrity claim. The RCD integrity mechanism is 224 a process of generating a sufficiently strong cryptographic digest 225 for each resource referenced by a URI within a claim value (e.g., an 226 image file referenced by "jcd" or a jCard referenced by "jcl"). This 227 mechanism is inspired by and based on the W3C Subresource Integrity 228 specification (http://www.w3.org/TR/SRI/). The second of the 229 mechanisms uses the capability called JWT Claim Constraints, defined 230 in [RFC8226] and extended in [RFC9118]. The JWT Claim Constraints 231 specifically guide the verifier within the certificate used to sign 232 the PASSporT for the inclusion (or exclusion) of specific claims and 233 their values, so that the content intended by the signer can be 234 verified to be accurate. 236 Both of these mechanisms, integrity digests and JWT Claims 237 Constraints, can be used together or separately depending on the 238 intended purpose. The first category of purpose is whether the rich 239 call data conveyed by the RCD passport is pass-by-value or passed-by- 240 reference; i.e., is the information contained in the passport claims 241 and therefore integrity protected by the passport signature, or is 242 the information contained in an external resource referenced by a URI 243 in the RCD PASSporT. The second category of purpose is whether the 244 signer is authoritative or has responsibility for the accuracy of the 245 RCD based on the policies of the eco-system the RCD PASSporTs are 246 being used. 248 The following table provides an overview of the framework for how 249 integrity should be used with RCD. (Auth represents authoritative in 250 this table) 252 +----------+---------------------+--------------------------------+ 253 | Modes | No external URIs | Includes URI refs | 254 +----------+---------------------+--------------------------------+ 255 | Auth | 1: No integrity req | 2: RDC Integrity | 256 +----------+---------------------+--------------------------------+ 257 | Non-Auth | 3: JWT Claim Const. | 4: RCD Integ./JWT Claim Const. | 258 +----------+---------------------+--------------------------------+ 260 The first and simplest mode is exclusively for when all RCD content 261 is directly included as part of the claims (i.e. no external 262 reference URIs are included in the content) and when the signer is 263 authoritative over the content. In this mode, integrity protection 264 is not required and the set of claims is simply protected by the 265 signature of the standard PASSporT [RFC8225] and SIP identity header 266 [RFC8224] procedures. The second mode is an extension of the first 267 where the signer is authoritative and an "rcd" claim contents include 268 a URI identifying external resources. In this mode, an RCD Integrity 269 or "rcdi" claim MUST be included. This integrity claim is defined 270 later in this document and provides a digest of the "rcd" claim 271 content so that, particularly for the case where there are URI 272 references in the RCD, the content of that RCD can be comprehensively 273 validated that it was received as intended by the signer of the 274 PASSporT. 276 The third and fourth mode cover cases where there is a different 277 authoritative entity responsible for the content of the RCD, separate 278 from the signer of the PASSporT itself, allowing the ability to have 279 forward control at the time of the creation of the certificate of the 280 allowed or vetted content included in or referenced by the RCD claim 281 contents. The primary framework for allowing the separation of 282 authority and the signing of PASSporTs by non-authorized entities is 283 detailed in [RFC9060] although other cases may apply. As with the 284 first and second modes, the third and fourth modes differ with the 285 absence or inclusion of externally referenced content using URIs. 287 5. PASSporT Claim "rcd" Definition and Usage 289 5.1. PASSporT "rcd" Claim 291 This specification defines a new JSON Web Token claim for "rcd", Rich 292 Call Data, the value of which is a JSON object that can contain one 293 or more key value pairs. This document defines a default set of key 294 values. 296 5.1.1. "nam" key 298 The "nam" key value is a display name, associated with the originator 299 of personal communications, which may for example derive from the 300 display-name component of the From header field value of a SIP 301 request or alternatively from the P-Asserted-Identity header field 302 value, or a similar field in other PASSporT using protocols. This 303 key MUST be included once as part of the "rcd" claim value JSON 304 object. If there is no string associated with a display name, the 305 claim value MUST then be an empty string. 307 5.1.2. "apn" key 309 The "apn" key value is an optional alternate presentation number 310 associated with the originator of personal communications, which may 311 for example derive from the user component of the From header field 312 value of a SIP request (in cases where a network number is carried in 313 the P-Asserted-Identity [RFC3325]), or alternatively from the 314 Additional-Identity header field value [3GPP TS 24.229 v16.7.0], or a 315 similar field in other PASSporT using protocols. Its intended 316 semantics are to convey a number that the originating user is 317 authorized to show to called parties in lieu of their default number, 318 such as cases where a remote call agent uses the main number of a 319 call center instead of their personal telephone number. The "apn" 320 key value is a canonicalized telephone number per [RFC8224] 321 Section 8.3. If present, this key MUST be included once as part of 322 the "rcd" claim value JSON object. 324 The use of the optional "apn" key is intended for cases where the 325 signer of an rcd PASSporT authorizes the use of an alternate 326 presentation number by the user. How the signer determines that a 327 user is authorized to present the number in question is a policy 328 decision outside the scope of this document, however, the vetting of 329 the alternate presentation number should follow the same level of 330 vetting as telephone identities or any other information contained in 331 an RCD PASSporT. This usage is intended as an alternative to 332 conveying the presentation number in the "tel" key value of a jCard, 333 in situations where no other rich jCard data needs to be conveyed 334 with the call. Only one "apn" key may be present. "apn" MUST be used 335 when it is the intent of the caller or signer to display the 336 alternate presentation number even if "jcd" or "jcl" keys are present 337 in a PASSporT with a "tel" key value. 339 5.1.3. "icn" key 341 The "icn" key value is an optional URI reference to an image that can 342 be used to pictorially represent the originator of personal 343 communications. This icon key value should be used as a base or 344 default method of associating an image with a calling party. 346 When being used for SIP [RFC3261] this claim key value used to 347 protect the call-info header field with a purpose parameter value of 348 "icon" as described in Section 20.9 [RFC3261]. Example as follows: 350 Call-Info: ; 351 purpose=icon 353 Note that [I-D.ietf-sipcore-callinfo-rcd] extends the specific usage 354 of "icon" in SIP in the context of the larger rich call data 355 framework with specific guidance on referencing images and image 356 types, sizes and formats. 358 It should be also noted that with jCard, as described in the 359 following "jcd" and "jcl" key value sections and in 360 [I-D.ietf-sipcore-callinfo-rcd], there are alternative ways of 361 including photos and logos as URI references. The "icn" key should 362 be then considered a base or default image and jCard usage should be 363 considered for profiles and extensions that provide more direct 364 guidance on the usage of specific defined usage of what each image 365 type represents for the proper rendering to end users. 367 5.1.4. "jcd" key 369 The "jcd" key value is defined to contain a jCard [RFC7095] JSON 370 object. This jCard object is intended to represent and derives from 371 the Call-Info header field value defined in 372 [I-D.ietf-sipcore-callinfo-rcd] with a type of "jcard". As also 373 defined in [I-D.ietf-sipcore-callinfo-rcd], format of the jCard and 374 properties used should follow the normative usage and formatting 375 rules and procedures. It is an extensible object where the calling 376 party can provide both the standard types of information defined in 377 jCard or can use the built-in extensibility of the jCard 378 specification to add additional information. The "jcd" key is 379 optional. If included, this key MUST only be included once in the 380 "rcd" JSON object and MUST NOT be included if there is a "jcl" key 381 included. The use of "jcd" and "jcl" keys are mutually exclusive. 383 The jCard object value for "jcd" MUST only have referenced content 384 for URI values that do not further reference URIs. Future 385 specifications may extend this capability, but as stated in 386 [I-D.ietf-sipcore-callinfo-rcd] it constrains the security properties 387 of RCD information and the integrity of the content referenced by 388 URIs. 390 Note: even though we refer to [I-D.ietf-sipcore-callinfo-rcd] as the 391 definition of the jcard properties for usage in an "rcd" PASSporT, 392 other future specifications and protocols are encouraged to be 393 adapted for use of "jcd" (or similarly "jcl" below) key beyond SIP 394 and Call-Info. 396 5.1.5. "jcl" key 398 The "jcl" key value is defined to contain a URI that refers the 399 recipient to a jCard [RFC7095] JSON object hosted on a HTTPS enabled 400 web server. The web server MUST use the MIME media type for JSON 401 text as application/json with a default encoding of UTF-8 [RFC4627]. 402 This link may derive from the Call-Info header field value defined in 403 [I-D.ietf-sipcore-callinfo-rcd] with a type of "jcard". As also 404 defined in [I-D.ietf-sipcore-callinfo-rcd], format of the jCard and 405 properties used should follow the normative usage and formatting 406 rules and procedures. The "jcl" key is optional. If included, this 407 key MUST only be included once in the "rcd" JSON object and MUST NOT 408 be included if there is a "jcd" key included. The use of "jcd" and 409 "jcl" keys are mutually exclusive. 411 The jCard object referenced by the URI value for "jcl" MUST only have 412 referenced content for URI values that do not further reference URIs. 413 Future specifications may extend this capability, but as stated in 414 [I-D.ietf-sipcore-callinfo-rcd] it constrains the security properties 415 of RCD information and the integrity of the content referenced by 416 URIs. 418 6. "rcdi" RCD Integrity Claim Definition and Usage 420 The "rcdi" claim is included for the second and fourth modes 421 described in the integrity overview Section 4 of this document. If 422 this claim is present it MUST be included only once with the 423 corresponding single "rcd" claim. The value of the "rcdi" claim is a 424 JSON object that is defined as follows. 426 The claim value of "rcdi" claim key is a JSON object with a set of 427 JSON key/value pairs. These objects correspond to each of the 428 elements of the "rcd" claim object that require integrity protection 429 with an associated digest over the content referenced by the key 430 string. The individual digest of different elements of the "rcd" 431 claim data and external URI referenced content is kept specifically 432 separate to allow the ability to verify the integrity of only the 433 elements that are ultimately retrieved or downloaded or rendered to 434 the end-user. 436 The key value references a specific object within the "rcd" claim 437 value using a JSON pointer defined in [RFC6901] with a minor 438 additional rule to support external URI references that include JSON 439 objects themselves, for the specific case of the use of "jcl". JSON 440 pointer syntax is the key value that specifies exactly the part of 441 JSON that is used to generate the digest which produce the resulting 442 string that makes up the value for the corresponding key. Detailed 443 procedures are provided below, but an example "rcdi" is provided 444 here: 446 "rcdi" : { 447 "/jcl": "sha256-7kdCBZqH0nqMSPsmABvsKlHPhZEStgjojhdSJGRr3rk", 448 "/jcl/1/2/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI" 449 } 451 The values of each key/value pair consists of a digest across either 452 the direct values or indirectly referenced resources, combined with a 453 string that defines the crypto algorithm used to generate the digest. 454 RCD implementations MUST support the following hash algorithms, 455 "SHA256", "SHA384", and "SHA512". The SHA-256, SHA-384, and SHA-512 456 are part of the SHA-2 set of cryptographic hash functions defined by 457 the National Institute of Standards and Technologies (NIST). 458 Implementations MAY support additional algorithms, but MUST NOT 459 support known weak algorithms such as MD5 or SHA-1. In the future, 460 the list of algorithms may be re-evaluated based on security best 461 practices. The algorithms are represented in the text by "sha256", 462 "sha384", or "sha512". The character following the algorithm string 463 MUST be a minus character, "-". The subsequent characters are the 464 base64 encoded [RFC4648] digest of a canonicalized and concatenated 465 string or binary data based on the JSON pointer referenced elements 466 of "rcd" claim or the URI referenced content contained in the claim. 467 The details of the determination of the input string used to 468 determine the digest are defined in the next section. 470 6.1. Creation of the "rcd" element digests 472 "rcd" claim objects can contain "nam", "apn", "icn", "jcd", or "jcl" 473 keys as part of the "rcd" JSON object claim value. This 474 specification defines the use of JSON pointer [RFC6901] as a 475 mechanism to reference specific "rcd" claim elements. 477 In order to facilitate proper verification of the digests and whether 478 the "rcd" elements or content referenced by URIs were modified, the 479 input to the digest must be completely deterministic at three points 480 in the process. First, at the certification point where the content 481 is evaluated to conform to the application policy and the JWT Claim 482 Constraints is applied to the certificate containing the digest. 483 Second, when the call is signed at the Authentication Service, there 484 may be a local policy to verify that the provided "rcd" claim 485 corresponds to each digest. Third, when the "rcd" data is verified 486 at the Verification Service, the verification is performed for each 487 digest by constructing the input digest string for the element being 488 verified and referenced by the JSON pointer string. 490 The procedure for the creation of each "rcd" element digest string 491 corresponding to a JSON pointer string key is as follows. 493 1. The JSON pointer either refers to a value that is a part or the 494 whole of a JSON object or to a string that is a URI referencing 495 an external resource. 497 2. For a JSON value, serialize the JSON to remove all white space 498 and line breaks. The procedures of this deterministic JSON 499 serialization are defined in [RFC8225], Section 9. The resulting 500 string is the input for the hash function. 502 3. For any URI referenced content, the bytes of the body of the HTTP 503 response is the input for the hash function. 505 6.1.1. "nam" and "apn" elements 507 In the case of "nam" and "apn", the only allowed value is a string. 508 For both of these key values an "rcdi" JSON pointer or integrity 509 digest is optional because the direct value is protected by the 510 signature and can be constrained directly with JWTClaimConstraints. 511 If used, the JSON key value referenced by the JSON pointer is the 512 string includes the quotes, so quotes MUST be included to compute the 513 digest. 515 6.1.2. "icn" elements 517 In the case of "icn", the only allowed value is a URI value that 518 references an image file. If the URI references externally linked 519 content there would need to be a JSON pointer and digest entry for 520 the content in that linked resource. In order to reference the "icn" 521 value for a digest, the JSON pointer string would be "/icn" and the 522 digest string would be created using the image file data following 523 the rules of JSON pointer. Even though this is probably not the 524 typical case, an "rcdi" JSON pointer or integrity digest is optional 525 if the image value is directly included via a data URI. However, 526 even though the direct value can be protected by the signature and 527 can be constrained directly with JWTClaimConstraints, since the 528 length of the image data is likely much larger than the integrity 529 digest, this specification would recommend the use of the "rcdi" JSON 530 pointer and integrity digest as the constraint value in 531 JWTClaimConstraints over the image data. 533 6.1.3. "jcd" elements 535 In the case of "jcd", the value associated is a jCard JSON object, 536 which happens to be a JSON array with sub-arrays. JSON pointer 537 notation uses numeric indexes into elements of arrays, including when 538 those elements are arrays themselves. 540 As example, for the following "rcd" claim: 542 "rcd": { 543 "jcd": ["vcard", 544 [ ["version",{},"text","4.0"], 545 [“fn",{},"text","Q Branch"], 546 [“org",{},"text","MI6;Q Branch Spy Gadgets"], 547 ["photo",{},"uri", 548 "https://example.com/photos/quartermaster-256x256.png"], 549 ["logo",{},"uri", 550 "https://example.com/logos/mi6-256x256.jpg"], 551 ["logo",{},"uri", 552 "https://example.com/logos/mi6-64x64.jpg"] 553 ] 554 ], 555 "nam": "Q Branch Spy Gadgets" 556 } 558 In order to use JSON pointer to refer to the URIs, the following 559 example "rcdi" claim includes a digest for the entire "jcd" array 560 string as well as three additional digests for the URIs, where, as 561 defined in [RFC6901] zero-based array indexes are used to reference 562 the URI strings. 564 "rcdi": { 565 "/jcd": "sha256-tbxXX9mRY2dtss3vNdNkNkt9hrV9N1LqGST2hDlw97I", 566 "/jcd/1/3/3": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4", 567 "/jcd/1/4/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI", 568 "/jcd/1/5/3": "sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo" 569 } 570 } 572 The use of a JSON pointer and integrity digest for the "jcd" claim 573 key and value is optional. The "jcd" value is the directly included 574 jCard array and can be protected by the signature and can be 575 constrained directly with JWTClaimConstraints. However, for data 576 length reasons (as with "icn" above) or more importantly for 577 potential privacy and/or security considerations with a publically 578 accessible certificate this specification would recommend the use of 579 the "rcdi" JSON pointer and integrity digest as the contraint value 580 in JWTClaimConstraints over the jCard data. 582 It is important to remember the array indexes for JSON Pointer are 583 dependent on the order of the elements in the jCard. The use of 584 digest for the "/jcd" corresponding to the entire jCard array string 585 can be included as a redundant mechanism to avoid any possibility of 586 substitution, insertion attacks, or other potential techniques that 587 may be possible to avoid integrity detection. 589 Each URI referenced in the jCard array string MUST have a 590 corresponding JSON pointer string key and digest value. 592 6.1.4. "jcl" elements 594 In the case of the use of a "jcl" URI reference to an external jCard, 595 the procedures are similar to "jcd" with the exception and the minor 596 modification to JSON pointer, where "/jcl" is used to refer to the 597 external jCard array string and any following numeric array indexes 598 added to the "jcl" (e.g., "/jcl/1/2/3") are treated as if the 599 externally referenced jCard was directly part of the overall "rcd" 600 claim JSON object. The following example illustrates a "jcl" version 601 of the above "jcd" example. 603 "rcd": { 604 "jcl": "https://example.com/qbranch.json", 605 "nam": "Q Branch Spy Gadgets" 606 }, 607 "rcdi": { 608 "/jcl": "sha256-Gb0lOkj7Z9+plqbOkN32H+YX0Yav3fbioSk7DxQdGZU", 609 "/jcl/1/3/3": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4", 610 "/jcl/1/4/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI", 611 "/jcl/1/5/3": "sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo" 612 } 614 The following is the example contents of resource pointed to by 615 https://example.com/qbranch.json used to calculate the above digest 616 for "/jcl" 618 ["vcard", 619 [ ["version",{},"text","4.0"], 620 [“fn",{},"text","Q Branch"], 621 [“org",{},"text","MI6;Q Branch Spy Gadgets"] 622 ["photo",{},"uri", 623 "https://example.com/photos/quartermaster-256x256.png"] 624 ["logo",{},"uri", 625 "https://example.com/logos/mi6-256x256.jpg"] 626 ["logo",{},"uri", 627 "https://example.com/logos/mi6-64x64.jpg"] 628 ] 629 ] 631 6.2. JWT Claim Constraints for "rcd" claims only 633 For the third mode described in the integrity overview Section 4 of 634 this document, where only JWT Claim Constraints for "rcd" claims 635 without an "rcdi" claim is required, the procedure when creating the 636 certificate with the intent to always include an "rcd" claim, to 637 include a JWT Claim Constraints on inclusion of an "rcd" claim with 638 the intended values required to be constrained by the certificate 639 used to sign the PASSporT. 641 The "permittedValues" for the "rcd" claim may optionally contain 642 multiple entries, to support the case where the certificate holder is 643 authorized to use different sets of rich call data. 645 Only including "permittedValues" for "rcd" (with no "mustInclude") 646 provides the ability to either have no "rcd" claim or only the set of 647 constrained "permittedValues" values for an included "rcd" claim. 649 7. JWT Claim Constraints usage for "rcd" and "rcdi" claims 651 The integrity overview Section 4 of this document describes a fourth 652 mode where both "rcdi" and JWT Claim Constraints is used. The use of 653 this mode implies the signing of an "rcdi" claim is required to be 654 protected by the authoritative certificate creator using JWT Claims 655 Constraints in the certificate. The objective of the use of both of 656 these mechanisms is to constrain the signer to construct the "rcd" 657 and "rcdi" claims with the "rcd" jCard object including reference 658 external content via URI. Once both the contents of the "rcd" claim 659 and any linked content is certified by the party that is 660 authoritative for the certificate being created and the construction 661 of the "rcdi" claim is complete, the "rcdi" claim is linked to the 662 STIR certificate associated with the signature in the PASSporT via 663 JWT Claim Constraints extension as defined in [RFC8226] Section 8. 664 It should be recognized that the "rcdi" set of digests is intended to 665 be unique for only a specific combination of "rcd" content and URI 666 referenced external content, and therefore provides a robust 667 integrity mechanism for an authentication service being performed by 668 a non-authoritative party. This would often be associated with the 669 use of delegate certificates [RFC9060] for the signing of calls by 670 the calling party directly as an example, even though the "authorized 671 party" is not necessarily the subject of a STIR certificate. 673 For the case that there should always be both "rcd" and "rcdi" values 674 included in the "rcd" PASSporT, the certificate JWT Claims Constraint 675 extension MUST include both of the following: 677 * a "mustInclude" for the "rcd" claim, which simply constrains the 678 fact that an "rcd" must be included 680 * a "mustInclude" for the "rcdi" claim and a "permittedValues" equal 681 to the created "rcdi" claim value string. 683 Note that optionally the "rcd" claims may be included in the 684 "permittedValues" however it is recognized that this may be redundant 685 with the "rcdi" permittedValues because the "rcdi" digest will imply 686 the content of the "rcd" claims themselves. 688 The "permittedValues" for the "rcdi" claims (or "rcd" claims more 689 generally) may contain multiple entries, to support the case where 690 the certificate holder is authorized to use different sets of rich 691 call data. 693 8. PASSporT "crn" claim - Call Reason Definition and Usage 695 This specification defines a new JSON Web Token claim for "crn", Call 696 Reason, the value of which is a single string or object that can 697 contains information as defined in [I-D.ietf-sipcore-callinfo-rcd] 698 corresponding to the "call-reason" parameter for the Call-Info 699 header. This claim is optional. 701 Example "crn" claim with "rcd": 703 "crn" : "For your ears only", 704 "rcd": { "nam": "James Bond", 705 "jcl": "https://example.org/james_bond.json"} 707 As also noted in [I-D.ietf-sipcore-callinfo-rcd] this claim is 708 included as corresponding to "call-reason" Call-Info parameter, but 709 there is an alternative suggested way to include call-reason which is 710 to use the "cif" claim with a "call-reason" key value, as defined 711 below in this document. 713 8.1. JWT Constraint for "crn" claim 715 The integrity of the "crn" claim can optionally be protected by the 716 authoritative certificate creator using JWT Constraints in the 717 certificate. If the intent of the issuer of the certificate is to 718 always including a call reason, a "mustInclude" for the "crn" claim 719 indicates that a "crn" claim must be present. If the issuer of the 720 certificate wants to constrain the contents of "crn", then it may set 721 "permittedValues" for "crn" in the certificate. 723 9. Rich Call Data Claims Usage Rules 725 Either or both the "rcd" or "crn" claims may appear in any PASSporT 726 claims object as optional elements. The creator of a PASSporT MAY 727 also add a "ppt" value of "rcd" to the header of a PASSporT as well, 728 in which case the PASSporT claims MUST contain either an "rcd" or 729 "crn" claim, and any entities verifying the PASSporT object are 730 required to understand the "ppt" extension in order to process the 731 PASSporT in question. An example PASSporT header with the "ppt" 732 included is shown as follows: 734 { "typ":"passport", 735 "ppt":"rcd", 736 "alg":"ES256", 737 "x5u":"https://www.example.com/cert.cer" } 739 The PASSporT claims object contains the "rcd" key with its 740 corresponding value. The value of "rcd" is an array of JSON objects, 741 of which one, the "nam" object, is mandatory. The key syntax of 742 "nam" follows the display-name ABNF given in [RFC3261]. 744 After the header and claims PASSporT objects have been constructed, 745 their signature is generated normally per the guidance in [RFC8225]. 747 9.1. "rcd" PASSporT Verification 749 An "rcd" PASSporT that uses claims defined in this specification, in 750 order to have a successful verification outcome, MUST conform to the 751 following: 753 * have a valid signature 755 * abide by all rules set forth in the proper construction of the 756 claims 758 * abide by JWT Claims Constraint rules defined in [RFC8226] 759 Section 8 or extended in [RFC9118] if present in the certificate 760 used to sign the PASSporT 762 Consistent with the verification rules of PASSporTs more generally 763 [RFC8225], if any of the above criteria is not met, relying parties 764 MUST NOT use any of the claims in the PASSporT. 766 9.2. "rcdi" Integrity Verification 768 If the "rcdi" claim exists, any party that dereferences a URI (i.e. 769 downloading content for display to users) from the "rcd" claim MUST 770 perform integrity validation of the content against the corresponding 771 digest. Consequently, if URIs with contents covered by integrity 772 digests are passed to another entity, the corresponding integrity 773 digest MUST also be included, for example by passing the PASSporT. 774 Entities that pass on the content without the URI do not have to pass 775 on the corresponding integrity digest. An entity that does not 776 otherwise need to dereference a URI from the "rcd" claim would be 777 discouraged from unnecessarily dereferencing the URI solely to 778 perform integrity verification. 780 If there is any issue with completing the integrity verification 781 procedures for externally referenced content, including HTTP or HTTPS 782 errors, the referenced content MUST be considered not verified. This 783 SHOULD NOT however impact the result of base PASSporT verification 784 for claims content that is directly included in the claims of the 785 PASSporT. 787 9.3. Example "rcd" PASSporTs 789 An example of a "nam" only PASSporT claims object is shown next (with 790 line breaks for readability only). 792 { "orig":{"tn":"12025551000"}, 793 "dest":{"tn":["12025551001"]}, 794 "iat":1443208345, 795 "rcd":{"nam":"James Bond"} } 797 An example of a "nam" and "apn" only PASSporT claims object is shown 798 next (with line breaks for readability only). 800 { "orig":{"tn":"12025551000"}, 801 "dest":{"tn":["12155551001"]}, 802 "iat":1443208345, 803 "rcd":{ 804 "apn":"12025559990", 805 "nam":"Her Majesty's Secret Service" } } 807 An example of an "rcd" claims object that includes the "jcd" and also 808 contains URI references to content which requires the inclusion of an 809 "rcdi" claim and corresponding digests. 811 { 812 "crn": "Rendezvous for Little Nellie", 813 "orig": { "tn": "12025551000"}, 814 "dest": { "tn": ["12155551001"]}, 815 "iat": 1443208345, 816 "rcd": { 817 "jcd": ["vcard", 818 [ ["version",{},"text","4.0"], 819 ["fn",{},"text","Q Branch"], 820 ["org",{},"text","MI6;Q Branch Spy Gadgets"], 821 ["photo",{},"uri","https://example.com/photos/q-256x256.png"], 822 ["logo",{},"uri","https://example.com/logos/mi6-256x256.jpg"], 823 ["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg"] 824 ] ], 825 "nam": "Q Branch Spy Gadgets" 826 }, 827 "rcdi": { 828 "/jcd/1/3/3": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4", 829 "/jcd/1/4/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI", 830 "/jcd/1/5/3": "sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo" 831 } 832 } 834 In an example PASSporT, where a jCard is linked via HTTPS URL using 835 "jcl", a jCard file served at a particular URL. 837 An example jCard JSON file hosted at the example web address of 838 https://example.com/qbranch.json is shown as follows: 840 ["vcard", 841 [ ["version",{},"text","4.0"], 842 ["fn",{},"text","Q Branch"], 843 ["org",{},"text","MI6;Q Branch Spy Gadgets"], 844 ["photo",{},"uri","https://example.com/photos/q-256x256.png"], 845 ["logo",{},"uri","https://example.com/logos/mi6-256x256.jpg"], 846 ["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg"] 847 ] 848 ] 850 For the above referenced jCard, the corresponding PASSporT claims 851 object would be as follows: 853 { 854 "crn": "Rendezvous for Little Nellie", 855 "orig": {"tn": "12025551000"}, 856 "dest": {"tn": ["12155551001"]}, 857 "iat": 1443208345, 858 "rcd": { 859 "nam": "Q Branch Spy Gadgets", 860 "jcl": "https://example.com/qbranch.json" 861 }, 862 "rcdi": { 863 "/jcl": "sha256-qCn4pEH6BJu7zXndLFuAP6DwlTv5fRmJ1AFkqftwnCs", 864 "/jcl/1/3/3": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4", 865 "/jcl/1/4/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI", 866 "/jcl/1/5/3": "sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo" 867 } 868 } 870 An example "rcd" PASSporT that uses "nam" and "icn" keys with "rcdi" 871 for calling name and referenced icon image content: 873 { 874 "crn": "Rendezvous for Little Nellie", 875 "orig": {"tn": "12025551000"}, 876 "dest": {"tn": ["12155551001"]}, 877 "iat": 1443208345, 878 "rcd": { 879 "nam": "Q Branch Spy Gadgets", 880 "icn": "https://example.com/photos/q-256x256.png" 881 }, 882 "rcdi": { 883 "/nam": "sha256-sM275lTgzCte+LHOKHtU4SxG8shlOo6OS4ot8IJQImY", 884 "/icn": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4" 885 } 886 } 888 10. Compact form of "rcd" PASSporT 890 10.1. Compact form of the "rcd" PASSporT claim 892 Compact form of an "rcd" PASSporT claim has some restrictions that 893 will be enumerated below, but mainly follows standard PASSporT 894 compact form procedures. For re-construction of the "nam" claim the 895 string for the display-name in the From header field. "jcl" and "jcd" 896 MAY NOT be used with compact form due to integrity rules and URI 897 reference rules in this specification leading to too restrictive of a 898 set of constraints. Future specifications may revisit this to 899 propose a consisent and comprehensive way of addressing integrity and 900 security of information. 902 10.2. Compact form of the "rcdi" PASSporT claim 904 Compact form of an "rcdi" PASSporT claim is not supported, so if 905 "rcdi" is required compact form MUST NOT be used. 907 10.3. Compact form of the "crn" PASSporT claim 909 Compact form of a "crn" PASSporT claim shall be re-constructed using 910 the "call-reason" parameter of a Call-Info header as defined by 911 [I-D.ietf-sipcore-callinfo-rcd]. 913 11. Further Information Associated with Callers 915 Beyond naming information and the information that can be contained 916 in a jCard [RFC7095] object, there may be additional human-readable 917 information about the calling party that should be rendered to the 918 end user in order to help the called party decide whether or not to 919 pick up the phone. This is not limited to information about the 920 caller, but includes information about the call itself, which may 921 derive from analytics that determine based on call patterns or 922 similar data if the call is likely to be one the called party wants 923 to receive. Such data could include: 925 * information related to the location of the caller, or 927 * any organizations or institutions that the caller is associated 928 with, or even categories of institutions (is this a government 929 agency, or a bank, or what have you), or 931 * hyperlinks to images, such as logos or pictures of faces, or to 932 similar external profile information, or 934 * information processed by an application before rendering it to a 935 user, like social networking data that shows that an unknown 936 caller is a friend-of-a-friend, or reputation scores derived from 937 crowdsourcing, or confidence scores based on broader analytics 938 about the caller and callee. 940 All of these data elements would benefit from the secure attestations 941 provided by the STIR and PASSporT frameworks. A new IANA registry 942 has been defined to hold potential values of the "rcd" array; see 943 Section 17.3. Specific extensions to the "rcd" PASSporT claim are 944 left for future specification. 946 There is a few ways RCD can be extended in the future, jCard is an 947 extensible object and the key/values in the RCD claim object can also 948 be extended. General guidance for future extensibility that were 949 followed by the authors is that jCard generally should refer to data 950 that references the caller as an individual or entity, where other 951 claims, such as "crn" refer to data regarding the specific call. 952 There may be other considerations discovered in the future, but this 953 logical grouping of data to the extent possible should be followed 954 for future extensibility. 956 12. Third-Party Uses 958 While rich data about the call can be provided by an originating 959 authentication service, an intermediary in the call path could also 960 acquire rich call data by querying a third-party service. Such a 961 service effectively acts as a STIR Authentication Service, generating 962 its own PASSporT, and that PASSporT could be attached to a SIP call 963 by either the originating or terminating side. This third-party 964 PASSporT attests information about the calling number, rather than 965 the call or caller itself, and as such its RCD MUST NOT be used when 966 a call lacks a first-party PASSporT that assures verification 967 services that the calling party number is not spoofed. It is 968 intended to be used in cases when the originating side does not 969 supply a display-name for the caller, so instead some entity in the 970 call path invokes a third-party service to provide rich caller data 971 for a call. 973 In telephone operations today, a third-party information service is 974 commonly queried with the calling party's number in order to learn 975 the name of the calling party, and potentially other helpful 976 information could also be passed over that interface. The value of 977 using a PASSporT to convey this information from third parties lies 978 largely in the preservation of the third party's signature over the 979 data, and the potential for the PASSporT to be conveyed from 980 intermediaries to endpoint devices. Effectively, these use cases 981 form a sub-case of out-of-band [RFC8816] use cases. The manner in 982 which third-party services are discovered is outside the scope of 983 this document. 985 An intermediary use case might look as follows: a SIP INVITE carries 986 a display name in its From header field value and an initial PASSporT 987 object without the "rcd" claim. When a terminating verification 988 service implemented at a SIP proxy server receives this request, and 989 determines that the signature is valid, it might query a third-party 990 service that maps telephone numbers to calling party names. Upon 991 receiving the PASSport in a response from that third-party service, 992 the terminating side could add a new Identity header field to the 993 request for the "rcd" PASSporT object provided by the third-party 994 service. It would then forward the INVITE to the terminating user 995 agent. If the display name in the "rcd" PASSporT object matches the 996 display name in the INVITE, then the name would presumably be 997 rendered to the end user by the terminating user agent. 999 A very similar flow could be followed by an intermediary closer to 1000 the origination of the call. Presumably such a service could be 1001 implemented at an originating network in order to decouple the 1002 systems that sign for calling party numbers from the systems that 1003 provide rich data about calls. 1005 In an alternative use case, the terminating user agent might query a 1006 third-party service. In this case, no new Identity header field 1007 would be generated, though the terminating user agent might receive a 1008 PASSporT object in return from the third-party service, and use the 1009 "rcd" field in the object as a calling name to render to users while 1010 alerting. 1012 While in the traditional telephone network, the business relationship 1013 between calling customers and their telephone service providers is 1014 the ultimate root of information about a calling party's name, some 1015 other forms of data like crowdsourced reputation scores might derive 1016 from third parties. When those elements are present, they MUST be in 1017 a third-party "rcd" PASSporT using "iss" claim described in the next 1018 section. 1020 12.1. Signing as a Third Party 1022 A third-party PASSporT contains an "iss" element to distinguish its 1023 PASSporTs from first-party PASSporTs. Third-party "rcd" PASSporTs 1024 are signed with credentials that do not have authority over the 1025 identity that appears in the "orig" element of the PASSporT claims. 1026 The presence of "iss" signifies that a different category of 1027 credential is being used to sign a PASSporT than the [RFC8226] 1028 certificates used to sign STIR calls; it is instead a certificate 1029 that identifies the source of the "rcd" data. How those credentials 1030 are issued and managed is outside the scope of this specification; 1031 the value of "iss" however MUST reflect the Subject of the 1032 certificate used to sign a third-party PASSporT. The explicit 1033 mechanism for reflecting the subject field of the certificate is out 1034 of scope of this document and left to the certificate governance 1035 policies that define how to map the "iss" value in the PASSporT to 1036 the subject field in the certificate. Relying parties in STIR have 1037 always been left to make their own authorization decisions about 1038 whether to trust the signers of PASSporTs, and in the third-party 1039 case, where an entity has explicitly queried a service to acquire the 1040 PASSporT object, it may be some external trust or business 1041 relationship that induces the relying party to trust a PASSporT. 1043 An example of a Third Party issued PASSporT claims object is as 1044 follows. 1046 { "orig":{"tn":"12025551000"}, 1047 "dest":{"tn":["12025551001"]}, 1048 "iat":1443208345, 1049 "iss":"Zorin Industries", 1050 "rcd":{"nam":"James St. John Smythe"} } 1052 13. Levels of Assurance 1054 As "rcd" can be provided by either first or third parties, relying 1055 parties could benefit from an additional claim that indicates the 1056 relationship of the attesting party to the caller. Even in first 1057 party cases, this admits of some complexity: the Communications 1058 Service Provider (CSP) to which a number was assigned might in turn 1059 delegate the number to a reseller, who would then sell the number to 1060 an enterprise, in which case the CSP might have little insight into 1061 the caller's name. In third party cases, a caller's name could 1062 derive from any number of data sources, on a spectrum between public 1063 data scraped from web searches to a direct business relationship to 1064 the caller. As multiple PASSporTs can be associated with the same 1065 call, potentially a verification service could receive attestations 1066 of the caller name from multiple sources, which have different levels 1067 of granularity or accuracy. Therefore, third-party PASSporTs that 1068 carry "rcd" data MUST also carry an indication of the relationship of 1069 the generator of the PASSporT to the caller in the form of the "iss" 1070 claim. As stated in the previous section, the use of "iss" MUST 1071 reflect the subject field of the certificate used to sign a third- 1072 party PASSporT to represent that relationship. 1074 14. Using "rcd" in SIP 1076 This section specifies SIP-specific usage for the "rcd" claim in 1077 PASSporT, and in the SIP Identity header field value. Other using 1078 protocols of PASSporT may define their own usages for the "rcd" 1079 claim. 1081 14.1. Authentication Service Behavior 1083 An authentication service creating a PASSporT containing an "rcd" 1084 claim MAY include a "ppt" for "rcd" or not. Third-party 1085 authentication services following the behavior in Section 12.1 MUST 1086 include a "ppt" of "rcd". If "ppt" does contain an "rcd", then any 1087 SIP authentication services MUST add a "ppt" parameter to the 1088 Identity header containing that PASSporT with a value of "rcd". The 1089 resulting Identity header might look as follows: 1091 Identity: sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9 1092 dlxkWzoeU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgt 1093 w0Lu5csIppPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=; 1094 info=;alg=ES256; 1095 ppt="rcd" 1097 This specification assumes that by default, a SIP authentication 1098 service derives the value of "rcd", specifically only for the "nam" 1099 key value, from the display-name component of the From header field 1100 value of the request, alternatively for some calls this may come from 1101 the P-Asserted-ID header. It is however a matter of authentication 1102 service policy to decide how it populates the value of "nam" key, 1103 which MAY also derive from other fields in the request, from customer 1104 profile data, or from access to external services. If the 1105 authentication service generates an "rcd" claim containing "nam" with 1106 a value that is not equivalent to the From header field display-name 1107 value, it MUST use the full form of the PASSporT object in SIP. 1109 14.2. Verification Service Behavior 1111 [RFC8224] Section 6.2 Step 5 requires that specifications defining 1112 "ppt" values describe any additional verifier behavior. The behavior 1113 specified for the "ppt" values of "rcd" is as follows. If the 1114 PASSporT is in compact form, then the verification service SHOULD 1115 extract the display-name from the From header field value, if any, 1116 and use that as the value for the "nam" key when it recomputes the 1117 header and claims of the PASSporT object. Additionally, if there 1118 exists a Call-Info header field as defined in 1119 [I-D.ietf-sipcore-callinfo-rcd], the "jcard" value can be derived to 1120 determine the "jcd" key when it recomputes the header and claims of 1121 the PASSporT object. If the signature validates over the recomputed 1122 object, then the verification should be considered successful. 1124 However, if the PASSport is in full form with a "ppt" value of "rcd", 1125 then the verification service MUST extract the value associated with 1126 the "rcd" "nam" key in the object. If the signature validates, then 1127 the verification service can use the value of the "rcd" "nam" key as 1128 the display name of calling party, which would in turn be rendered to 1129 alerted users or otherwise leveraged in accordance with local policy. 1130 This allows SIP networks that convey the display name through a field 1131 other than the From header field to interoperate with this 1132 specification. Similarly, the "jcd" or linked "jcl" jcard 1133 information and "crn" can be optionally, based on local policy for 1134 devices that support it, used to populate a Call-Info header field 1135 following the format of [I-D.ietf-sipcore-callinfo-rcd]. 1137 The third-party "rcd" PASSporT cases presents some new challenges, as 1138 an attacker could attempt to cut-and-paste such a third-party 1139 PASSporT into a SIP request in an effort to get the terminating user 1140 agent to render the display name or confidence values it contains to 1141 a call that should have no such assurance. A third-party "rcd" 1142 PASSporT provides no assurance that the calling party number has not 1143 been spoofed: if it is carried in a SIP request, for example, then 1144 some other PASSporT in another Identity header field value would have 1145 to carry a PASSporT attesting that. A verification service MUST 1146 determine that the calling party number shown in the "orig" of the 1147 "rcd" PASSporT corresponds to the calling party number of the call it 1148 has received, and that the "iat" field of the "rcd" PASSporT is 1149 within the date interval that the verification service would 1150 ordinarily accept for a PASSporT. 1152 Verification services may alter their authorization policies for the 1153 credentials accepted to sign PASSporTs when third parties generate 1154 PASSporT objects, per Section 12.1. This may include accepting a 1155 valid signature over a PASSporT even if it is signed with a 1156 credential that does not attest authority over the identity in the 1157 "orig" claim of the PASSporT, provided that the verification service 1158 has some other reason to trust the signer. No further guidance on 1159 verification service authorization policy is given here. 1161 The behavior of a SIP UAS upon receiving an INVITE containing a 1162 PASSporT object with an "rcd" claim largely remains a matter of 1163 implementation policy. In most cases, implementations would render 1164 this calling party name information to the user while alerting. Any 1165 user interface additions to express confidence in the veracity of 1166 this information are outside the scope of this specification. 1168 15. Using "rcd" and "rcdi" as additional claims to other PASSporT 1169 extensions 1171 Rich Call Data, including calling name information, as a common 1172 example, is often data that is additive to the personal 1173 communications information defined in the core PASSporT data required 1174 to support the security properties defined in [RFC8225]. For cases 1175 where the entity originating the personal communications is 1176 supporting the authentication service for the calling identity and is 1177 the authority of the Rich Call Data, rather than creating multiple 1178 Identity header fields cooresponding to multiple PASSporT extensions, 1179 the authentication service can alternatively directly add the "rcd" 1180 claim to a PASSporT that authenticates the calling identity. 1182 Note: There is one very important caveat to this capability, because 1183 generally if there is URI referenced content in an "rcd" PASSporT 1184 there is often the requirement to use "rcdi" and JWT Claims 1185 Constraints. So, it is important for the user of this specification 1186 to recognize that the certificates used should include the necessary 1187 JWT Claims Constraints for proper integrity and security of the 1188 values in the "rcd" claim incorporated into PASSporTs that are not 1189 "rcd". 1191 15.1. Procedures for applying "rcd" as claims only 1193 For a given PASSporT using some other extension than "rcd", the 1194 Authentication Service MAY additionally include the "rcd" claim as 1195 defined in this document. This would result in a set of claims that 1196 correspond to the original intended extension with the addition of 1197 the "rcd" claim. 1199 The Verification service that receives the PASSporT, if it supports 1200 this specification and chooses to, should interpret the "rcd" claim 1201 as simply just an additional claim intended to deliver and/or 1202 validate delivered Rich Call Data. 1204 15.2. Example for applying "rcd" as claims only 1206 In the case of [RFC8588] which is the PASSporT extension supporting 1207 the SHAKEN specification [ATIS-1000074.v002], a common case for an 1208 Authentication service to co-exist in a CSP network along with the 1209 authority over the calling name used for the call. Rather than 1210 require two identity headers, the CSP Authentication Service can 1211 apply both the SHAKEN PASSporT claims and extension and simply add 1212 the "rcd" required claims defined in this document. 1214 For example, the PASSporT claims for the "shaken" PASSporT with "rcd" 1215 claims would be as follows: 1217 Protected Header 1218 { 1219 "alg":"ES256", 1220 "typ":"passport", 1221 “ppt”:”shaken”, 1222 "x5u":"https://cert.example.org/passport.cer" 1223 } 1224 Payload 1225 { 1226 “attest”:”A”, 1227 "dest":{“tn”:["12025551001"]}, 1228 "iat":1443208345, 1229 "orig":{“tn”:"12025551000"}, 1230 “origid”:”123e4567-e89b-12d3-a456-426655440000”, 1231 "rcd":{"nam":"James Bond"} 1232 } 1233 A Verification Service that supports "rcd" and "shaken" PASSporT 1234 extensions is able to receive the above PASSporT and interpret both 1235 the "shaken" claims as well as the "rcd" defined claim. 1237 If the Verification Service only understands the "shaken" PASSporT 1238 extension claims and doesn't support "rcd" PASSporT extension, then 1239 the "rcd" claim is used during PASSporT signature validation but is 1240 otherwise ignored and disregarded. 1242 16. Acknowledgements 1244 We would like to thank David Hancock, Robert Sparks, Russ Housley, 1245 Eric Burger, Alec Fenichel, Ben Campbell, Jack Rickard, Jordan 1246 Simpson for helpful suggestions, review, and comments. 1248 17. IANA Considerations 1250 17.1. JSON Web Token Claim 1252 This specification requests that the IANA add three new claims to the 1253 JSON Web Token Claims registry as defined in [RFC7519]. 1255 Claim Name: "rcd" 1257 Claim Description: Rich Call Data Information 1259 Change Controller: IESG 1261 Specification Document(s): [RFCThis] 1263 Claim Name: "rcdi" 1265 Claim Description: Rich Call Data Integrity Information 1267 Change Controller: IESG 1269 Specification Document(s): [RFCThis] 1271 Claim Name: "crn" 1273 Claim Description: Call Reason 1275 Change Controller: IESG 1277 Specification Document(s): [RFCThis] 1279 17.2. PASSporT Types 1281 This specification requests that the IANA add a new entry to the 1282 PASSporT Types registry for the type "rcd" which is specified in 1283 [RFCThis]. 1285 17.3. PASSporT RCD Types 1287 This document requests that the IANA create a new registry for 1288 PASSporT RCD types. Registration of new PASSporT RCD types shall be 1289 under the Specification Required policy. 1291 This registry is to be initially populated with four values, "nam", 1292 "apn", "jcd", and "jcl", which are specified in [RFCThis]. 1294 18. Security Considerations 1296 Whether its identities, alternate identities, images, logos, physical 1297 addresses, all of the information contained in a RCD PASSporT must 1298 follow some form of vetting in which the authoritative entity or user 1299 of the information being signed MUST follow an applicable policy of 1300 the eco-system using RCD. This can be of many forms, depending on 1301 the setup and constraints of the eco-system so is therefore out-of- 1302 scope of this document. However, the general chain of trust that 1303 signers of RCD PASSporT are either directly authoritative or have 1304 been delegated authority through certificates using JWT Claim 1305 Constraints and integrity mechanisms defined in this and related 1306 documents is critical to maintain the integrity of the eco-system 1307 utilizing this and other STIR related specifications. 1309 Revealing information such as the name, location, and affiliation of 1310 a person necessarily entails certain privacy risks. Baseline 1311 PASSporT has no particular confidentiality requirement, as the 1312 information it signs over in a using protocol like SIP is all 1313 information that SIP carries in the clear anyway. Transport-level 1314 security can hide those SIP fields from eavesdroppers, and the same 1315 confidentiality mechanisms would protect any PASSporT(s) carried in 1316 SIP. 1318 The use of JWTClaimConstraints, a mechanism defined in [RFC8226] and 1319 extended in [RFC9118] to constrain any of the RCD information in the 1320 public certificate by including that information in the certificate, 1321 depending on the availbility in the deployment of the PKI system, may 1322 present a privacy issue. The use of "rcdi" claim and digests for 1323 representing JWT claim contents may be a recommended way of 1324 preventing the exposure of that information through the certificates 1325 which are often publically accessible and available. 1327 Since computation of "rcdi" digests for URIs requires the loading of 1328 referenced content, it would be best practice to validate that 1329 content at the creation of the "rcdi" or corresponding JWT claim 1330 constraint value by checking for content that may cause issues for 1331 verification services or that doesn't follow the behavior defined in 1332 this document, e.g., unreasonably sized data, the inclusion of 1333 recursive URI references, etc. Along the same lines, the 1334 verification service should also use precautionary best practices to 1335 avoid attacks when accessing URI linked content. 1337 18.1. The use of JWT Claim Constraints in delegate certificates to 1338 exclude unauthorized claims 1340 While this can apply to any PASSporT that is signed with a STIR 1341 Delegate Certificates [RFC9060], it is important to note that when 1342 constraining PASSporTs to include specific claims or contents of 1343 claims, it is also important to consider potential attacks by non- 1344 authorized signers that may include other potential PASSporT claims 1345 that weren't originally vetted by the authorized entity providing the 1346 delegate certificate. The use of JWT claims constraints as defined 1347 in [RFC9118] for preventing the ability to include claims beyond the 1348 claims defined in this document may need to be considered. 1350 Certificate issuers SHOULD NOT include an entry in mustExclude for 1351 the "rcdi" claim for a certificate that will be used with the 1352 PASSporT Extension for Rich Call Data defined in this document. 1353 Excluding this claim would prevent the integrity protection mechanism 1354 from working properly. 1356 19. References 1358 19.1. Normative References 1360 [I-D.ietf-sipcore-callinfo-rcd] 1361 Wendt, C. and J. Peterson, "SIP Call-Info Parameters for 1362 Rich Call Data", Work in Progress, Internet-Draft, draft- 1363 ietf-sipcore-callinfo-rcd-04, 7 March 2022, 1364 . 1367 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1368 Requirement Levels", BCP 14, RFC 2119, 1369 DOI 10.17487/RFC2119, March 1997, 1370 . 1372 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1373 A., Peterson, J., Sparks, R., Handley, M., and E. 1374 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1375 DOI 10.17487/RFC3261, June 2002, 1376 . 1378 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1379 Extensions to the Session Initiation Protocol (SIP) for 1380 Asserted Identity within Trusted Networks", RFC 3325, 1381 DOI 10.17487/RFC3325, November 2002, 1382 . 1384 [RFC4627] Crockford, D., "The application/json Media Type for 1385 JavaScript Object Notation (JSON)", RFC 4627, 1386 DOI 10.17487/RFC4627, July 2006, 1387 . 1389 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1390 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1391 . 1393 [RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., 1394 "JavaScript Object Notation (JSON) Pointer", RFC 6901, 1395 DOI 10.17487/RFC6901, April 2013, 1396 . 1398 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, 1399 DOI 10.17487/RFC7095, January 2014, 1400 . 1402 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 1403 Telephone Identity Problem Statement and Requirements", 1404 RFC 7340, DOI 10.17487/RFC7340, September 2014, 1405 . 1407 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1408 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1409 . 1411 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1412 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1413 May 2017, . 1415 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 1416 "Authenticated Identity Management in the Session 1417 Initiation Protocol (SIP)", RFC 8224, 1418 DOI 10.17487/RFC8224, February 2018, 1419 . 1421 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 1422 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 1423 . 1425 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 1426 Credentials: Certificates", RFC 8226, 1427 DOI 10.17487/RFC8226, February 2018, 1428 . 1430 [RFC8588] Wendt, C. and M. Barnes, "Personal Assertion Token 1431 (PaSSporT) Extension for Signature-based Handling of 1432 Asserted information using toKENs (SHAKEN)", RFC 8588, 1433 DOI 10.17487/RFC8588, May 2019, 1434 . 1436 [RFC9060] Peterson, J., "Secure Telephone Identity Revisited (STIR) 1437 Certificate Delegation", RFC 9060, DOI 10.17487/RFC9060, 1438 September 2021, . 1440 [RFC9118] Housley, R., "Enhanced JSON Web Token (JWT) Claim 1441 Constraints for Secure Telephone Identity Revisited (STIR) 1442 Certificates", RFC 9118, DOI 10.17487/RFC9118, August 1443 2021, . 1445 19.2. Informative References 1447 [ATIS-1000074.v002] 1448 ATIS/SIP Forum NNI Task Group, "Signature-based Handling 1449 of Asserted information using toKENs (SHAKEN) 1450 ", November 2021. 1453 [RFC8816] Rescorla, E. and J. Peterson, "Secure Telephone Identity 1454 Revisited (STIR) Out-of-Band Architecture and Use Cases", 1455 RFC 8816, DOI 10.17487/RFC8816, February 2021, 1456 . 1458 Authors' Addresses 1460 Chris Wendt 1461 Somos Inc. 1462 Email: chris-ietf@chriswendt.net 1464 Jon Peterson 1465 Neustar Inc. 1466 Email: jon.peterson@neustar.biz