idnits 2.17.1 draft-ietf-stir-passport-rcd-14.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 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. For re-construction of the "jcl", the Call-Info header as with purpose "jcard" defined in [I-D.ietf-sipcore-callinfo-rcd] MUST be used. "jcd" claim MAY NOT be used as part of compact form. -- The document date (25 October 2021) is 907 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 1207, but not defined == Outdated reference: A later version (-10) exists of draft-ietf-sipcore-callinfo-rcd-02 ** 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 Comcast 4 Intended status: Standards Track J. Peterson 5 Expires: 28 April 2022 Neustar Inc. 6 25 October 2021 8 PASSporT Extension for Rich Call Data 9 draft-ietf-stir-passport-rcd-14 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 28 April 2022. 48 Copyright Notice 50 Copyright (c) 2021 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 Simplified BSD License text 59 as described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Simplified 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" Defintion and Usage . . . . . . . . . . 7 70 5.1. PASSporT "rcd" Claim . . . . . . . . . . . . . . . . . . 7 71 5.1.1. "nam" key . . . . . . . . . . . . . . . . . . . . . . 7 72 5.1.2. "apn" key . . . . . . . . . . . . . . . . . . . . . . 8 73 5.1.3. "jcd" key . . . . . . . . . . . . . . . . . . . . . . 8 74 5.1.4. "jcl" key . . . . . . . . . . . . . . . . . . . . . . 9 75 6. "rcdi" RCD Integrity Claim Definition and Usage . . . . . . . 9 76 6.1. Creation of the "rcd" element digests . . . . . . . . . . 10 77 6.2. JWT Claim Constraints for "rcd" claims only . . . . . . . 13 78 7. JWT Claim Constraints usage for "rcd" and "rcdi" claims . . . 14 79 8. PASSporT "crn" claim - Call Reason Defintion and Usage . . . 15 80 8.1. JWT Constraint for "crn" claim . . . . . . . . . . . . . 15 81 9. Rich Call Data Claims Usage Rules . . . . . . . . . . . . . . 15 82 9.1. Verification rules . . . . . . . . . . . . . . . . . . . 16 83 9.2. Example "rcd" PASSporTs . . . . . . . . . . . . . . . . . 16 84 10. Compact form of "rcd" PASSporT . . . . . . . . . . . . . . . 18 85 10.1. Compact form of the "rcd" PASSporT claim . . . . . . . . 18 86 10.2. Compact form of the "rcdi" PASSporT claim . . . . . . . 19 87 10.3. Compact form of the "crn" PASSporT claim . . . . . . . . 19 88 11. Further Information Associated with Callers . . . . . . . . . 19 89 12. Third-Party Uses . . . . . . . . . . . . . . . . . . . . . . 20 90 12.1. Signing as a Third Party . . . . . . . . . . . . . . . . 21 91 13. Levels of Assurance . . . . . . . . . . . . . . . . . . . . . 22 92 14. Using "rcd" in SIP . . . . . . . . . . . . . . . . . . . . . 22 93 14.1. Authentication Service Behavior . . . . . . . . . . . . 22 94 14.2. Verification Service Behavior . . . . . . . . . . . . . 23 96 15. Using "rcd" as additional claims to other PASSporT 97 extensions . . . . . . . . . . . . . . . . . . . . . . . 24 98 15.1. Procedures for applying "rcd" as claims only . . . . . . 25 99 15.2. Example for applying "rcd" as claims only . . . . . . . 25 100 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 101 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 102 17.1. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 26 103 17.2. PASSporT Types . . . . . . . . . . . . . . . . . . . . . 27 104 17.3. PASSporT RCD Types . . . . . . . . . . . . . . . . . . . 27 105 18. Security Considerations . . . . . . . . . . . . . . . . . . . 27 106 18.1. The use of JWT Claim Constraints in delegate certificates 107 to exclude unauthorized claims . . . . . . . . . . . . . 28 108 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 109 19.1. Normative References . . . . . . . . . . . . . . . . . . 28 110 19.2. Informative References . . . . . . . . . . . . . . . . . 30 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 113 1. Introduction 115 PASSporT [RFC8225] is a token format based on JWT [RFC7519] for 116 conveying cryptographically-signed information about the parties 117 involved in personal communications; it is used to convey a signed 118 assertion of the identity of the participants in real-time 119 communications established via a protocol like SIP [RFC8224]. The 120 STIR problem statement [RFC7340] declared securing the display name 121 of callers outside of STIR's initial scope, so baseline STIR provides 122 no features for caller name. This specification documents an 123 optional mechanism for PASSporT and the associated STIR procedures 124 which extend PASSporT objects to protect additional elements 125 conveying richer information: information that is intended to be 126 rendered to assist a called party in determining whether to accept or 127 trust incoming communications. This includes the name of the person 128 or entity on one side of a communications session, the traditional 129 "Caller ID" of the telephone network, along with related display 130 information that would be rendered to the called party during 131 alerting, or potentially used by an automaton to determine whether 132 and how to alert a called party. 134 Traditional telephone network signaling protocols have long supported 135 delivering a 'calling name' from the originating side, though in 136 practice, the terminating side is often left to derive a name from 137 the calling party number by consulting a local address book or an 138 external database. SIP similarly can carry this information in a 139 'display-name' in the From header field value from the originating to 140 terminating side, or alternatively in the Call-Info header field. 141 However, both are unsecured fields that really cannot be trusted in 142 most interconnected SIP deployments, and therefore is a good starting 143 point for a framework that utilizes STIR techniques and procedures 144 for protecting call related information including but not limited to 145 calling name. 147 As such, the baseline use-case for this document extends PASSporT to 148 provide cryptographic protection for the "display-name" field of SIP 149 requests as well as further "rich call data" (RCD) about the caller, 150 which includes the contents of the Call-Info header field or other 151 data structures that can be added to the PASSporT. This document 152 furthermore specifies a third-party profile that would allow external 153 authorities to convey rich information associated with a calling 154 number via a new type of PASSporT. Finally, this document describes 155 how to preserve the integrity of the RCD in scenarios where there may 156 be non-authoritative users initiating and signing RCD and therefore a 157 constraint on the RCD data that a PASSporT can attest via 158 certificate-level controls. 160 2. Terminology 162 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 164 "OPTIONAL" in this document are to be interpreted as described in BCP 165 14 [RFC2119] [RFC8174] when, and only when, they appear in all 166 capitals, as shown here. 168 3. Overview of the use of the Rich Call Data PASSporT extension 170 The main intended use of the signing of Rich Call Data (RCD) using 171 STIR within SIP [RFC8224] or more generally as a PASSporT extension 172 [RFC8225] is for the entity that originates a call, either directly 173 the caller themselves, if they are authoritative, or a service 174 provider or third-party service that may be authoritative over the 175 rich call data on behalf of the caller. 177 The RCD associated with the identity of the calling party described 178 in this document is of two main categories. The first data is a more 179 traditional set of info about a caller associated with "display-name" 180 in SIP [RFC3261], typically a textual description of the caller, or 181 alternate presentation numbers often used in From Header field 183 [RFC3261] or P-Asserted-ID [RFC3325]. The second category is a set 184 of RCD that is defined as part of the jCard definitions or extensions 185 to that data. [I-D.ietf-sipcore-callinfo-rcd] describes the optional 186 use of jCard in Call-Info header field as RCD with the "jcard" Call- 187 Info purpose token. Either or both of these two types of data can be 188 incorporated into a "rcd" claim defined in this document. 190 Additionally, in relation to the description of the specific 191 communications event itself (versus the identity description in 192 previous paragraph), [I-D.ietf-sipcore-callinfo-rcd] also describes a 193 "call-reason" parameter intended for description of the intent or 194 reason for a particular call. A new PASSporT claim "crn", or call 195 reason, can contain the string or object that describes the intent of 196 the call. This claim is intentionally kept separate from the "rcd" 197 claim because it is envisioned that call reason is not the same as 198 information associated with the caller and may change on a more 199 frequent, per call, type of basis. 201 4. Overview of Rich Call Data Integrity 203 When incorporating call data that represents a user, even in 204 traditional calling name services today, often there is policy and 205 restrictions around what data is allowed to be used. Whether 206 preventing offensive language or icons or enforcing uniqueness, 207 potential trademark or copyright violations or other policy 208 enforcement, there might be the desire to pre-certify or "vet" the 209 specific use of rich call data. This document defines a mechanism 210 that allows for a direct or indirect party that controls the policy 211 to approve or certify the content, create a cryptographic digest that 212 can be used to validate that data and applies a constraint in the 213 certificate to allow the recipient and verifier to validate that the 214 specific content of the RCD is as intended at its creation and 215 approval or certification. 217 There are two mechanisms that are defined to accomplish that for two 218 distinct categories of purposes. The first of the mechanisms include 219 the definition of an integrity claim. The RCD integrity mechanism is 220 a process of generating a sufficiently strong cryptographic digest 221 for both the "rcd" claim contents (e.g. "nam", "jcd", "jcl") defined 222 below and the resources defined by one or more globally unique HTTPS 223 URLs referenced by the contents (e.g. an image file referenced by 224 "jcd" or a jCard referenced by "jcl"). This mechanism is inspired by 225 and based on the W3C Subresource Integrity specification 226 (http://www.w3.org/TR/SRI/). The second of the mechanisms uses the 227 capability called JWT Claim Constraints, defined in [RFC8226] and 228 extended in [I-D.ietf-stir-enhance-rfc8226]. The JWT Claim 229 Constraints specifically guide the verifier within the certificate 230 used to sign the PASSporT for the inclusion (or exclusion) of 231 specific claims and their values, so that the content intended by the 232 signer can be verified to be accurate. 234 Both of these mechanisms, integrity digests and JWT Claims 235 Constraints, can be used together or separately depending on the 236 intended purpose. The first category of purpose is whether the rich 237 call data conveyed by the RCD passport is pass-by-value or passed-by- 238 reference; i.e., is the information contained in the passport claims 239 and therefore integrity protected by the passport signature, or is 240 the information contained in an external resource referenced by a URI 241 in the RCD PASSporT. The second category of purpose is whether the 242 signer is authoritative or has responsibility for the accuracy of the 243 RCD based on the policies of the eco-system the RCD PASSporTs are 244 being used. 246 The following table provides an overview of the framework for how 247 integrity should be used with RCD. (Auth represents authoritative in 248 this table) 250 +----------+---------------------+--------------------------------+ 251 | Modes | No external URIs | Includes URI refs | 252 +----------+---------------------+--------------------------------+ 253 | Auth | 1: No integrity req | 2: RDC Integrity | 254 +----------+---------------------+--------------------------------+ 255 | Non-Auth | 3: JWT Claim Const. | 4: RCD Integ./JWT Claim Const. | 256 +----------+---------------------+--------------------------------+ 258 The first and simplest mode is exclusively for when all RCD content 259 is directly included as part of the claims (i.e. no external 260 reference URIs are included in the content) and when the signer is 261 authoritative over the content. In this mode, integrity protection 262 is not required and the set of claims is simply protected by the 263 signature of the standard PASSporT [RFC8225] and SIP identity header 264 [RFC8224] procedures. The second mode is an extension of the first 265 where the signer is authoritative and a "rcd" claim contents include 266 a URI identifying external resources. In this mode, an RCD Integrity 267 or "rcdi" claim MUST be included. This integrity claim is defined 268 later in this document and provides a digest of the "rcd" claim 269 content so that, particularly for the case where there are URI 270 references in the RCD, the content of that RCD can be comprehensively 271 validated that it was received as intended by the signer of the 272 PASSporT. 274 The third and fourth mode cover cases where there is a different 275 authoritative entity responsible for the content of the RCD, separate 276 from the signer of the PASSporT itself, allowing the ability to have 277 forward control at the time of the creation of the certificate of the 278 allowed or vetted content included in or referenced by the RCD claim 279 contents. The primary framework for allowing the separation of 280 authority and the signing of PASSporTs by non-authorized entities is 281 detailed in [I-D.ietf-stir-cert-delegation] although other cases may 282 apply. As with the first and second modes, the third and fourth 283 modes differ with the absence or inclusion of externally referenced 284 content using URIs. 286 5. PASSporT Claim "rcd" Defintion and Usage 288 5.1. PASSporT "rcd" Claim 290 This specification defines a new JSON Web Token claim for "rcd", Rich 291 Call Data, the value of which is a JSON object that can contain one 292 or more key value pairs. This document defines a default set of key 293 values. 295 5.1.1. "nam" key 297 The "nam" key value is a display name, associated with the originator 298 of personal communications, which may for example derive from the 299 display-name component of the From header field value of a SIP 300 request or alternatively from the P-Asserted-Identity header field 301 value, or a similar field in other PASSporT using protocols. This 302 key MUST be included once as part of the "rcd" claim value JSON 303 object. If there is no string associated with a display name, the 304 claim value MUST then be an empty string. 306 5.1.2. "apn" key 308 The "apn" key value is an optional alternate presentation number 309 associated with the originator of personal communications, which may 310 for example derive from the user component of the From header field 311 value of a SIP request (in cases where a network number is carried in 312 the P-Asserted-Identity [RFC3325]), or alternatively from the 313 Additional-Identity header field value [3GPP TS 24.229 v16.7.0], or a 314 similar field in other PASSporT using protocols. Its intended 315 semantics are to convey a number that the originating user is 316 authorized to show to called parties in lieu of their default number, 317 such as cases where a remote call agent uses the main number of a 318 call center instead of their personal telephone number. The "apn" 319 key value is a canonicalized telephone number per [RFC8224] 320 Section 8.3. If present, this key MUST be included once as part of 321 the "rcd" claim value JSON object. 323 The use of the optional "apn" key is intended for cases where the 324 signer of an rcd PASSporT authorizes the use of an alternate 325 presentation number by the user. How the signer determines that a 326 user is authorized to present the number in question is a policy 327 decision outside the scope of this document, however, the vetting of 328 the alternate presentation number should follow the same level of 329 vetting as telephone identities or any other information contained in 330 an RCD PASSporT. This usage is intended as an alternative to 331 conveying the presentation number in the "tel" key value of a jCard, 332 in situations where no other rich jCard data needs to be conveyed 333 with the call. Only one "apn" key may be present. "apn" MUST be used 334 when it is the intent of the caller or signer to display the 335 alternate presentation number even if "jcd" or "jcl" keys are present 336 in a PASSporT with a "tel" key value. 338 5.1.3. "jcd" key 340 The "jcd" key value is defined to contain a jCard [RFC7095] JSON 341 object. This jCard object is intended to represent and derives from 342 the Call-Info header field value defined in 343 [I-D.ietf-sipcore-callinfo-rcd] with a type of "jcard". As also 344 defined in [I-D.ietf-sipcore-callinfo-rcd], format of the jCard and 345 properties used should follow the normative usage and formatting 346 rules and procedures. It is an extensible object where the calling 347 party can provide both the standard types of information defined in 348 jCard or can use the built-in extensibility of the jCard 349 specification to add additional information. The "jcd" key is 350 optional. If included, this key MUST only be included once in the 351 "rcd" JSON object and MUST NOT be included if there is a "jcl" key 352 included. The use of "jcd" and "jcl" keys are mutually exclusive. 354 The jCard object value for "jcd" MUST only have referenced content 355 for URI values that do not further reference URIs. Future 356 specifications may extend this capability, but as stated in 357 [I-D.ietf-sipcore-callinfo-rcd] it constrains the security properties 358 of RCD information and the integrity of the content referenced by 359 URIs. 361 Note: even though we refer to [I-D.ietf-sipcore-callinfo-rcd] as the 362 definition of the jcard properties for usage in a "rcd" PASSporT, 363 other protocols can be adapted for use of "jcd" (or similarly "jcl" 364 below) key beyond SIP and Call-Info. 366 5.1.4. "jcl" key 368 The "jcl" key value is defined to contain a HTTPS URL that refers the 369 recipient to a jCard [RFC7095] JSON object hosted on a HTTPS enabled 370 web server. The web server MUST use the MIME media type for JSON 371 text as application/json with a default encoding of UTF-8 [RFC4627]. 372 This link may derive from the Call-Info header field value defined in 373 [I-D.ietf-sipcore-callinfo-rcd] with a type of "jcard". As also 374 defined in [I-D.ietf-sipcore-callinfo-rcd], format of the jCard and 375 properties used should follow the normative usage and formatting 376 rules and procedures. The "jcl" key is optional. If included, this 377 key MUST only be included once in the "rcd" JSON object and MUST NOT 378 be included if there is a "jcd" key included. The use of "jcd" and 379 "jcl" keys are mutually exclusive. 381 The jCard object referenced by the URI value for "jcl" MUST only have 382 referenced content for URI values that do not further reference URIs. 383 Future specifications may extend this capability, but as stated in 384 [I-D.ietf-sipcore-callinfo-rcd] it constrains the security properties 385 of RCD information and the integrity of the content referenced by 386 URIs. 388 6. "rcdi" RCD Integrity Claim Definition and Usage 390 The "rcdi" claim is included for the second and fourth modes 391 described in integrity overview section of this document. If this 392 claim is present it MUST be only included once with the corresponding 393 single "rcd" claim. The value of the "rcdi" claim is a JSON object 394 that is defined as follows. 396 The claim value of "rcdi" claim key is a JSON object with a set of 397 JSON key/value pairs. These objects correspond to each of the 398 elements of the "rcd" claim object that require integrity protection 399 with an associated digest over the content referenced by the key 400 string. The individual digest of different elements of the "rcd" 401 claim data and external URI referenced content is kept specifically 402 separate to allow the ability to verify the integrity of only the 403 elements that are ultimately retrieved or downloaded or rendered to 404 the end-user. 406 The key value references a specific object within the "rcd" claim 407 value using a JSON pointer defined in [RFC6901] with a minor 408 additional rule to support external URI references that include JSON 409 objects themselves, for the specific case of the use of "jcl". JSON 410 pointer syntax is the key value that specifies exactly the part of 411 JSON that is used to generate the digest which produce the resulting 412 string that makes up the value for the corresponding key. Detailed 413 procedures are provided below, but an example "rcdi" is provided 414 here: 416 "rcdi" : { 417 "/jcd": "sha256-7kdCBZqH0nqMSPsmABvsKlHPhZEStgjojhdSJGRr3rk", 418 "/jcd/1/2/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI" 419 } 421 The values of each key pair are a digest combined with a string that 422 defines the crypto algorithm used to generate the digest. RCD 423 implementations MUST support the following hash algorithms, "SHA256", 424 "SHA384", and "SHA512". The SHA-256, SHA-384, and SHA-512 are part 425 of the SHA-2 set of cryptographic hash functions defined by the 426 National Institute of Standards and Technologies (NIST). 427 Implementations MAY support additional algorithms, but MUST NOT 428 support known weak algorithms such as MD5 or SHA-1. In the future, 429 the list of algorithms may be re-evaluated based on security best 430 practices. The algorithms are represented in the text by "sha256", 431 "sha384", or "sha512". The character following the algorithm string 432 MUST be a minus character, "-". The subsequent characters are the 433 base64 encoded [RFC4648] digest of a canonicalized and concatenated 434 string or binary data based on the JSON pointer referenced elements 435 of "rcd" claim or the URI referenced content contained in the claim. 436 The details of the determination of the input string used to 437 determine the digest are defined in the next section. 439 6.1. Creation of the "rcd" element digests 441 "rcd" claim objects can contain "nam", "apn", "jcd", or "jcl" keys as 442 part of the "rcd" JSON object claim value. This specification 443 defines the use of JSON pointer [RFC6901] as a mechanism to reference 444 specific "rcd" claim elements. 446 In the case of "nam", the only allowed value is a "string". In order 447 to reference the "nam" string value for a digest, the JSON pointer 448 string would be "/nam" and the digest string would be created using 449 only the string pointed to by that "/nam" following the rules of JSON 450 pointer. 452 In the case of "apn", the only allowed value is a "string". In order 453 to reference the "apn" string value for a digest, the JSON pointer 454 string would be "/apn" and the digest string would be created using 455 only the string pointed to by that "/apn" following the rules of JSON 456 pointer. 458 In the case of "jcd", the value associated is a jCard JSON object, 459 which happens to be a JSON array with sub-arrays. JSON pointer 460 notation uses numeric indexes into elements of arrays, including when 461 those elements are arrays themselves. 463 As example, for the following "rcd" claim: 465 "rcd": { 466 "nam": "Q Branch Spy Gadgets", 467 "jcd": ["vcard", 468 [ ["version",{},"text","4.0"], 469 [“fn",{},"text","Q Branch"], 470 [“org",{},"text","MI6;Q Branch Spy Gadgets"], 471 ["photo",{},"uri", 472 "https://example.com/photos/quartermaster-256x256.png"], 473 ["logo",{},"uri", 474 "https://example.com/logos/mi6-256x256.jpg"], 475 ["logo",{},"uri", 476 "https://example.com/logos/mi6-64x64.jpg"] 477 ] 478 ] 479 } 481 In order to use JSON pointer to refer to the URIs, the following 482 example "rcdi" claim includes a digest for the entire "jcd" array 483 string as well as three additional digests for the URIs, where, as 484 defined in [RFC6901] zero-based array indexes are used to reference 485 the URI strings. 487 "rcdi": { 488 "/jcd": "sha256-7kdCBZqH0nqMSPsmABvsKlHPhZEStgjojhdSJGRr3rk", 489 "/jcd/1/3/3": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4", 490 "/jcd/1/4/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI", 491 "/jcd/1/5/3": "sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo" 492 } 493 } 494 For the use of JSON pointer in "jcd" and because array indexes are 495 dependent on the order of the elements in the jCard, the digest for 496 the "/jcd" corresponding to the entire jCard array string MUST be 497 included to avoid any possibility of substitution or insertion 498 attacks that may be possible to avoid integrity detection. Each URI 499 referenced in the jCard array string MUST have a corresponding JSON 500 pointer string key and digest value. 502 In the case of the use of a "jcl" URI reference to an external jCard, 503 the procedures are similar to "jcd" with the exception and the minor 504 modification to JSON pointer, where "/jcl" is used to refer to the 505 external jCard array string and any following numeric array indexes 506 added to the "jcl" (e.g. "/jcl/1/2/3") are treated as if the 507 externally referenced jCard was directly part of the overall "rcd" 508 claim JSON object. The following example illustrates a "jcl" version 509 of the above "jcd" example. 511 "rcd": { 512 "nam": "Q Branch Spy Gadgets", 513 "jcl": "https://example.com/qbranch.json" 514 }, 515 "rcdi": { 516 "/jcl": "sha256-Gb0lOkj7Z9+plqbOkN32H+YX0Yav3fbioSk7DxQdGZU", 517 "/jcl/1/3/3": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4", 518 "/jcl/1/4/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI", 519 "/jcl/1/5/3": "sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo" 520 } 522 https://example.com/qbranch.json: 523 ["vcard", 524 [ ["version",{},"text","4.0"], 525 [“fn",{},"text","Q Branch"], 526 [“org",{},"text","MI6;Q Branch Spy Gadgets"] 527 ["photo",{},"uri", 528 "https://example.com/photos/quartermaster-256x256.png"] 529 ["logo",{},"uri", 530 "https://example.com/logos/mi6-256x256.jpg"] 531 ["logo",{},"uri", 532 "https://example.com/logos/mi6-64x64.jpg"] 533 ] 534 ] 536 In order to facilitate proper verification of the digests and whether 537 the "rcd" elements or content referenced by URIs were modified, the 538 input to the digest must be completely deterministic at three points 539 in the process. First, at the certification point where the content 540 is evaluated to conform to the application policy and the JWT Claim 541 Constraints is applied to the certificate containing the digest. 543 Second, when the call is signed at the Authentication Service, there 544 may be a local policy to verify that the provided "rcd" claim 545 corresponds to each digest. Third, when the "rcd" data is verified 546 at the Verification Service, the verification is performed for each 547 digest by constructing the input digest string for the element being 548 verified and referenced by the JSON pointer string. 550 The procedure for the creation of each "rcd" element digest string 551 corresponding to a JSON pointer string key is as follows. 553 1. The JSON pointer either refers to an element that is a part or 554 whole of a JSON object string or to a string that is a URI 555 referencing an external resource. 557 2. For a JSON formatted string, serialize the element JSON to remove 558 all white space and line breaks. The procedures of this 559 deterministic JSON serialization are defined in [RFC8225], 560 Section 9. The resulting string MUST be a Base64 encoded 561 [RFC4648] digest string (for sha256 this should result in 562 approximately 44 characters). 564 3. For any URI referenced content, the content can either be a 565 string as in jCard JSON objects or binary content. For example, 566 image and audio files contain binary content. If the URI 567 referenced content is JSON formatted, follow the procedures 568 defined in list item 2 above. Either the binary data or string 569 content of the file is used to create a resulting string which 570 MUST be a Base64 encoded [RFC4648] digest string (for sha256 this 571 should result in approximately 44 characters). 573 6.2. JWT Claim Constraints for "rcd" claims only 575 For the third mode described in the integrity overview section of 576 this document, where only JWT Claim Constraints for "rcd" claims 577 without an "rcdi" claim is required, the procedure when creating the 578 certificate with the intent to always include an "rcd" claim, to 579 include a JWT Claim Constraints on inclusion of an "rcd" claim with 580 the intended values required to be constrained by the certificate 581 used to sign the PASSporT. 583 The "permittedValues" for the "rcd" claim may optionally contain 584 multiple entries, to support the case where the certificate holder is 585 authorized to use different sets of rich call data. 587 Only including "permittedValues" for "rcd" (with no "mustInclude") 588 provides the ability to either have no "rcd" claim or only the set of 589 constrained "permittedValues" values for an included "rcd" claim. 591 7. JWT Claim Constraints usage for "rcd" and "rcdi" claims 593 The integrity overview section of this document describes a fourth 594 mode where both "rcdi" and JWT Claim Constraints is used. The use of 595 this mode implies the signing of an "rcdi" claim is required to be 596 protected by the authoritative certificate creator using JWT Claims 597 Constraints in the certificate. The intension of the use of both of 598 these mechanisms is to constrain the signer to construct the "rcd" 599 and "rcdi" claims with the "rcd" jCard object including reference 600 external content via URI. Once both the contents of the "rcd" claim 601 and any linked content is certified by the party that is 602 authoritative for the certificate being created and the construction 603 of the "rcdi" claim is complete, the "rcdi" claim is linked to the 604 STIR certificate associated with the signature in the PASSporT via 605 JWT Claim Constraints as defined in [RFC8226] Section 8. It should 606 be recognized that the "rcdi" set of digests is intended to be unique 607 for only a specific combination of "rcd" content and URI referenced 608 external content, and therefore provides a robust integrity mechanism 609 for an authentication service being performed by a non-authoritative 610 party. This would often be associated with the use of delegate 611 certificates [I-D.ietf-stir-cert-delegation] for the signing of calls 612 by the calling party directly as an example, even though the 613 "authorized party" is not necessarily the subject of a STIR 614 certificate. 616 For the case that there should always be both "rcd" and "rcdi" values 617 included in the "rcd" PASSporT, the certificate JWT Claims Constraint 618 MUST include both of the following: 620 * a "mustInclude" for the "rcd" claim, which simply constrains the 621 fact that an "rcd" must be included if there is a "rcdi" 623 * a "mustInclude" for the "rcdi" claim and a "permittedValues" equal 624 to the created "rcdi" claim value string. 626 Note that optionally the "rcd" claims may be included in the 627 "permittedValues" however it is recognized that this may be redundant 628 with the "rcdi" permittedValues because the "rcdi" digest will imply 629 the content of the "rcd" claims themselves. 631 The "permittedValues" for the "rcdi" claims may contain multiple 632 entries, to support the case where the certificate holder is 633 authorized to use different sets of rich call data. 635 8. PASSporT "crn" claim - Call Reason Defintion and Usage 637 This specification defines a new JSON Web Token claim for "crn", Call 638 Reason, the value of which is a single string or object that can 639 contains information as defined in [I-D.ietf-sipcore-callinfo-rcd] 640 corresponding to the "reason" parameter for the Call-Info header. 641 This claim is optional. 643 Example "crn" claim with "rcd": 644 "rcd": { "nam": "James Bond", 645 "jcl": "https://example.org/james_bond.json"}, 646 "crn" : "For your ears only" 648 8.1. JWT Constraint for "crn" claim 650 The integrity of the "crn" claim can optionally be protected by the 651 authoritative certificate creator using JWT Constraints in the 652 certificate. If the intent of the issuer of the certificate is to 653 always including a call reason, a "mustInclude" for the "crn" claim 654 indicates that a "crn" claim must be present. If the issuer of the 655 certificate wants to constrain the contents of "crn", then it may set 656 "permittedValues" for "crn" in the certificate. 658 9. Rich Call Data Claims Usage Rules 660 Either or both the "rcd" or "crn" claims may appear in any PASSporT 661 claims object as optional elements. The creator of a PASSporT MAY 662 also add a "ppt" value of "rcd" to the header of a PASSporT as well, 663 in which case the PASSporT claims MUST contain either a "rcd" or 664 "crn" claim, and any entities verifying the PASSporT object are 665 required to understand the "ppt" extension in order to process the 666 PASSporT in question. An example PASSporT header with the "ppt" 667 included is shown as follows: 669 { "typ":"passport", 670 "ppt":"rcd", 671 "alg":"ES256", 672 "x5u":"https://www.example.com/cert.cer" } 674 The PASSporT claims object contains the "rcd" key with its 675 corresponding value. The value of "rcd" is an array of JSON objects, 676 of which one, the "nam" object, is mandatory. The key syntax of 677 "nam" follows the display-name ABNF given in [RFC3261]. 679 After the header and claims PASSporT objects have been constructed, 680 their signature is generated normally per the guidance in [RFC8225]. 682 9.1. Verification rules 684 A PASSporT that uses claims defined in this specification, in order 685 to have a successful verification outcome, MUST conform to the 686 following: 688 * abide by all rules set forth in the proper construction of the 689 claims 691 * abide by JWT Claims Constraint rules defined in [RFC8226] 692 Section 8 or extended in [I-D.ietf-stir-enhance-rfc8226] if 693 present in the certificate used to sign the PASSporT 695 * pass integrity verification using "rcdi" if present. 697 Consistent with the verification rules of PASSporTs more generally 698 [RFC8225], if any of the above criteria is not met, the PASSporT 699 verification should be considered a failed verification for all 700 claims in the PASSporT. 702 In some middle box scenarios, a relying party may not have the need 703 to validate content that is referenced by URIs (e.g. only wanting to 704 validate base PASSporT info like "orig" and "dest" or other "rcd" 705 info like "nam" or "apn"). In these scenarios, this proceedure while 706 not considered a full verification, can be performed without 707 verifying the full integrity checks of URI referenced content. 709 9.2. Example "rcd" PASSporTs 711 An example of a "nam" only PASSporT claims object is shown next (with 712 line breaks for readability only). 714 { "orig":{"tn":"12025551000"}, 715 "dest":{"tn":["12025551001"]}, 716 "iat":1443208345, 717 "rcd":{"nam":"James Bond"} } 719 An example of a "nam" and "apn" only PASSporT claims object is shown 720 next (with line breaks for readability only). 722 { "orig":{"tn":"12025551000"}, 723 "dest":{"tn":["12155551001"]}, 724 "iat":1443208345, 725 "rcd":{ 726 "apn":"12025559990", 727 "nam":"Her Majesty's Secret Service" } } 729 An example of a "nam" only PASSporT claims object with an "rcdi" 730 claim is shown next (with line breaks for readability only). 732 { "orig":{"tn":"12025551000"}, 733 "dest":{"tn":["12025551001"]}, 734 "iat":1443208345, 735 "rcd":{"nam":"James Bond"}, 736 "rcdi":{"/nam": "sha256-uDtvpG1xNw+MK0XEOh+2UNQ94MQJ5d2ftgmHxsjKeMw"} 737 } 739 An example of a "rcd" claims object that includes the "jcd" and also 740 contains a URI which requires the inclusion of an "rcdi" claim. 742 { 743 "orig": { "tn": "12025551000"}, 744 "dest": { "tn": ["12155551001"]}, 745 "iat": 1443208345, 746 "rcd": { 747 "nam": "Q Branch Spy Gadgets", 748 "jcd": ["vcard", 749 [ ["version",{},"text","4.0"], 750 ["fn",{},"text","Q Branch"], 751 ["org",{},"text","MI6;Q Branch Spy Gadgets"], 752 ["photo",{},"uri","https://example.com/photos/q-256x256.png"], 753 ["logo",{},"uri","https://example.com/logos/mi6-256x256.jpg"], 754 ["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg"] 755 ] ] 756 }, 757 "crn": "Rendezvous for Little Nellie", 758 "rcdi": { 759 "/nam": "sha256-sM275lTgzCte+LHOKHtU4SxG8shlOo6OS4ot8IJQImY", 760 "/jcd": "sha256-7kdCBZqH0nqMSPsmABvsKlHPhZEStgjojhdSJGRr3rk", 761 "/jcd/1/3/3": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4", 762 "/jcd/1/4/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI", 763 "/jcd/1/5/3": "sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo" 764 } 765 } 767 In an example PASSporT, where a jCard is linked via HTTPS URL using 768 "jcl", a jCard file served at a particular URL. 770 An example jCard JSON file is shown as follows: 772 https://example.com/qbranch.json: 773 ["vcard", 774 [ ["version",{},"text","4.0"], 775 ["fn",{},"text","Q Branch"], 776 ["org",{},"text","MI6;Q Branch Spy Gadgets"], 777 ["photo",{},"uri","https://example.com/photos/q-256x256.png"], 778 ["logo",{},"uri","https://example.com/logos/mi6-256x256.jpg"], 779 ["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg"] 780 ] 781 ] 783 If that jCard is hosted at the example address of 784 "https://example.com/qbranch.json", the corresponding PASSporT claims 785 object would be as follows: 787 { 788 "orig": {"tn": "12025551000"}, 789 "dest": {"tn": ["12155551001"]}, 790 "iat": 1443208345, 791 "rcd": { 792 "nam": "Q Branch Spy Gadgets", 793 "jcl": "https://example.com/qbranch.json" 794 }, 795 "crn": "Rendezvous for Little Nellie", 796 "rcdi": { 797 "/nam": "sha256-Gb0lOkj7Z9+plqbOkN32H+YX0Yav3fbioSk7DxQdGZU", 798 "/jcl": "sha256-Gb0lOkj7Z9+plqbOkN32H+YX0Yav3fbioSk7DxQdGZU", 799 "/jcl/1/3/3": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4", 800 "/jcl/1/4/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI", 801 "/jcl/1/5/3": "sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo" 802 } 803 } 805 10. Compact form of "rcd" PASSporT 807 10.1. Compact form of the "rcd" PASSporT claim 809 Compact form of an "rcd" PASSporT claim has some restrictions but 810 mainly follows standard PASSporT compact form procedures. For re- 811 construction of the "nam" claim the string for the display-name in 812 the From header field. For re-construction of the "jcl", the Call- 813 Info header as with purpose "jcard" defined in 814 [I-D.ietf-sipcore-callinfo-rcd] MUST be used. "jcd" claim MAY NOT be 815 used as part of compact form. 817 10.2. Compact form of the "rcdi" PASSporT claim 819 Compact form of an "rcdi" PASSporT claim is not supported, so if 820 "rcdi" is required compact form MUST NOT be used. 822 10.3. Compact form of the "crn" PASSporT claim 824 Compact form of a "crn" PASSporT claim shall be re-constructed using 825 the "call-reason" parameter of a Call-Info header as defined by 826 [I-D.ietf-sipcore-callinfo-rcd]. 828 11. Further Information Associated with Callers 830 Beyond naming information and the information that can be contained 831 in a jCard [RFC7095] object, there may be additional human-readable 832 information about the calling party that should be rendered to the 833 end user in order to help the called party decide whether or not to 834 pick up the phone. This is not limited to information about the 835 caller, but includes information about the call itself, which may 836 derive from analytics that determine based on call patterns or 837 similar data if the call is likely to be one the called party wants 838 to receive. Such data could include: 840 * information related to the location of the caller, or 842 * any organizations or institutions that the caller is associated 843 with, or even categories of institutions (is this a government 844 agency, or a bank, or what have you), or 846 * hyperlinks to images, such as logos or pictures of faces, or to 847 similar external profile information, or 849 * information processed by an application before rendering it to a 850 user, like social networking data that shows that an unknown 851 caller is a friend-of-a-friend, or reputation scores derived from 852 crowdsourcing, or confidence scores based on broader analytics 853 about the caller and callee. 855 All of these data elements would benefit from the secure attestations 856 provided by the STIR and PASSporT frameworks. A new IANA registry 857 has been defined to hold potential values of the "rcd" array; see 858 Section 17.3. Specific extensions to the "rcd" PASSporT claim are 859 left for future specification. 861 There is a few ways RCD can be extended in the future, jCard is an 862 extensible object and the key/values in the RCD claim object can also 863 be extended. General guidance for future extensibility that were 864 followed by the authors is that jCard generally should refer to data 865 that references the caller as an individual or entity, where other 866 claims, such as "crn" refer to data regarding the specific call. 867 There may be other considerations discovered in the future, but this 868 logical grouping of data to the extent possible should be followed 869 for future extensibility. 871 12. Third-Party Uses 873 While rich data about the call can be provided by an originating 874 authentication service, an intermediary in the call path could also 875 acquire rich call data by querying a third-party service. Such a 876 service effectively acts as a STIR Authentication Service, generating 877 its own PASSporT, and that PASSporT could be attached to a SIP call 878 by either the originating or terminating side. This third-party 879 PASSporT attests information about the calling number, rather than 880 the call or caller itself, and as such its RCD MUST NOT be used when 881 a call lacks a first-party PASSporT that assures verification 882 services that the calling party number is not spoofed. It is 883 intended to be used in cases when the originating side does not 884 supply a display-name for the caller, so instead some entity in the 885 call path invokes a third-party service to provide rich caller data 886 for a call. 888 In telephone operations today, a third-party information service is 889 commonly queried with the calling party's number in order to learn 890 the name of the calling party, and potentially other helpful 891 information could also be passed over that interface. The value of 892 using a PASSporT to convey this information from third parties lies 893 largely in the preservation of the third party's signature over the 894 data, and the potential for the PASSporT to be conveyed from 895 intermediaries to endpoint devices. Effectively, these use cases 896 form a sub-case of out-of-band [I-D.ietf-stir-oob] use cases. The 897 manner in which third-party services are discovered is outside the 898 scope of this document. 900 An intermediary use case might look as follows: a SIP INVITE carries 901 a display name in its From header field value and an initial PASSporT 902 object without the "rcd" claim. When a terminating verification 903 service implemented at a SIP proxy server receives this request, and 904 determines that the signature is valid, it might query a third-party 905 service that maps telephone numbers to calling party names. Upon 906 receiving the PASSport in a response from that third-party service, 907 the terminating side could add a new Identity header field to the 908 request for the "rcd" PASSporT object provided by the third-party 909 service. It would then forward the INVITE to the terminating user 910 agent. If the display name in the "rcd" PASSporT object matches the 911 display name in the INVITE, then the name would presumably be 912 rendered to the end user by the terminating user agent. 914 A very similar flow could be followed by an intermediary closer to 915 the origination of the call. Presumably such a service could be 916 implemented at an originating network in order to decouple the 917 systems that sign for calling party numbers from the systems that 918 provide rich data about calls. 920 In an alternative use case, the terminating user agent might query a 921 third-party service. In this case, no new Identity header field 922 would be generated, though the terminating user agent might receive a 923 PASSporT object in return from the third-party service, and use the 924 "rcd" field in the object as a calling name to render to users while 925 alerting. 927 While in the traditional telephone network, the business relationship 928 between calling customers and their telephone service providers is 929 the ultimate root of information about a calling party's name, some 930 other forms of data like crowdsourced reputation scores might derive 931 from third parties. When those elements are present, they MUST be in 932 a third-party "rcd" PASSporT using "iss" claim described in the next 933 section. 935 12.1. Signing as a Third Party 937 A third-party PASSporT contains an "iss" element to distinguish its 938 PASSporTs from first-party PASSporTs. Third-party "rcd" PASSporTs 939 are signed with credentials that do not have authority over the 940 identity that appears in the "orig" element of the PASSporT claims. 941 The presence of "iss" signifies that a different category of 942 credential is being used to sign a PASSporT than the [RFC8226] 943 certificates used to sign STIR calls; it is instead a certificate 944 that identifies the source of the "rcd" data. How those credentials 945 are issued and managed is outside the scope of this specification; 946 the value of "iss" however MUST reflect the Subject of the 947 certificate used to sign a third-party PASSporT. The explicit 948 mechanism for reflecting the subject field of the certificate is out 949 of scope of this document and left to the certificate governance 950 policies that define how to map the "iss" value in the PASSporT to 951 the subject field in the certificate. Relying parties in STIR have 952 always been left to make their own authorization decisions about 953 whether to trust the signers of PASSporTs, and in the third-party 954 case, where an entity has explicitly queried a service to acquire the 955 PASSporT object, it may be some external trust or business 956 relationship that induces the relying party to trust a PASSporT. 958 An example of a Third Party issued PASSporT claims object is as 959 follows. 961 { "orig":{"tn":"12025551000"}, 962 "dest":{"tn":["12025551001"]}, 963 "iat":1443208345, 964 "iss":"Zorin Industries", 965 "rcd":{"nam":"James St. John Smythe"} } 967 13. Levels of Assurance 969 As "rcd" can be provided by either first or third parties, relying 970 parties could benefit from an additional claim that indicates the 971 relationship of the attesting party to the caller. Even in first 972 party cases, this admits of some complexity: the Communications 973 Service Provider (CSP) to which a number was assigned might in turn 974 delegate the number to a reseller, who would then sell the number to 975 an enterprise, in which case the CSP might have little insight into 976 the caller's name. In third party cases, a caller's name could 977 derive from any number of data sources, on a spectrum between public 978 data scraped from web searches to a direct business relationship to 979 the caller. As multiple PASSporTs can be associated with the same 980 call, potentially a verification service could receive attestations 981 of the caller name from multiple sources, which have different levels 982 of granularity or accuracy. Therefore, third-party PASSporTs that 983 carry "rcd" data MUST also carry an indication of the relationship of 984 the generator of the PASSporT to the caller in the form of the "iss" 985 claim. As stated in the previous section, the use of "iss" MUST 986 reflect the subject field of the certificate used to sign a third- 987 party PASSporT to represent that relationship. 989 14. Using "rcd" in SIP 991 This section specifies SIP-specific usage for the "rcd" claim in 992 PASSporT, and in the SIP Identity header field value. Other using 993 protocols of PASSporT may define their own usages for the "rcd" 994 claim. 996 14.1. Authentication Service Behavior 998 An authentication service creating a PASSporT containing a "rcd" 999 claim MAY include a "ppt" for "rcd" or not. Third-party 1000 authentication services following the behavior in Section 12.1 MUST 1001 include a "ppt" of "rcd". If "ppt" does contain a "rcd", then any 1002 SIP authentication services MUST add a "ppt" parameter to the 1003 Identity header containing that PASSporT with a value of "rcd". The 1004 resulting Identity header might look as follows: 1006 Identity: sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9 1007 dlxkWzoeU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgt 1008 w0Lu5csIppPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=; 1009 info=;alg=ES256; 1010 ppt="rcd" 1012 This specification assumes that by default, a SIP authentication 1013 service derives the value of "rcd", specifically only for the "nam" 1014 key value, from the display-name component of the From header field 1015 value of the request, alternatively for some calls this may come from 1016 the P-Asserted-ID header. It is however a matter of authentication 1017 service policy to decide how it populates the value of "nam" key, 1018 which MAY also derive from other fields in the request, from customer 1019 profile data, or from access to external services. If the 1020 authentication service generates a "rcd" claim containing "nam" with 1021 a value that is not equivalent to the From header field display-name 1022 value, it MUST use the full form of the PASSporT object in SIP. 1024 14.2. Verification Service Behavior 1026 [RFC8224] Section 6.2 Step 5 requires that specifications defining 1027 "ppt" values describe any additional verifier behavior. The behavior 1028 specified for the "ppt" values of "rcd" is as follows. If the 1029 PASSporT is in compact form, then the verification service SHOULD 1030 extract the display-name from the From header field value, if any, 1031 and use that as the value for the "nam" key when it recomputes the 1032 header and claims of the PASSporT object. Additionally, if there 1033 exists a Call-Info header field as defined in 1034 [I-D.ietf-sipcore-callinfo-rcd], the "jcard" value can be derived to 1035 determine the "jcd" key when it recomputes the header and claims of 1036 the PASSporT object. If the signature validates over the recomputed 1037 object, then the verification should be considered successful. 1039 However, if the PASSport is in full form with a "ppt" value of "rcd", 1040 then the verification service MUST extract the value associated with 1041 the "rcd" "nam" key in the object. If the signature validates, then 1042 the verification service can use the value of the "rcd" "nam" key as 1043 the display name of calling party, which would in turn be rendered to 1044 alerted users or otherwise leveraged in accordance with local policy. 1045 This allows SIP networks that convey the display name through a field 1046 other than the From header field to interoperate with this 1047 specification. Similarly, the "jcd" or linked "jcl" jcard 1048 information and "crn" can be optionally, based on local policy for 1049 devices that support it, used to populate a Call-Info header field 1050 following the format of [I-D.ietf-sipcore-callinfo-rcd]. 1052 The third-party "rcd" PASSporT cases presents some new challenges, as 1053 an attacker could attempt to cut-and-paste such a third-party 1054 PASSporT into a SIP request in an effort to get the terminating user 1055 agent to render the display name or confidence values it contains to 1056 a call that should have no such assurance. A third-party "rcd" 1057 PASSporT provides no assurance that the calling party number has not 1058 been spoofed: if it is carried in a SIP request, for example, then 1059 some other PASSporT in another Identity header field value would have 1060 to carry a PASSporT attesting that. A verification service MUST 1061 determine that the calling party number shown in the "orig" of the 1062 "rcd" PASSporT corresponds to the calling party number of the call it 1063 has received, and that the "iat" field of the "rcd" PASSporT is 1064 within the date interval that the verification service would 1065 ordinarily accept for a PASSporT. 1067 Verification services may alter their authorization policies for the 1068 credentials accepted to sign PASSporTs when third parties generate 1069 PASSporT objects, per Section 12.1. This may include accepting a 1070 valid signature over a PASSporT even if it is signed with a 1071 credential that does not attest authority over the identity in the 1072 "orig" claim of the PASSporT, provided that the verification service 1073 has some other reason to trust the signer. No further guidance on 1074 verification service authorization policy is given here. 1076 The behavior of a SIP UAS upon receiving an INVITE containing a 1077 PASSporT object with a "rcd" claim largely remains a matter of 1078 implementation policy. In most cases, implementations would render 1079 this calling party name information to the user while alerting. Any 1080 user interface additions to express confidence in the veracity of 1081 this information are outside the scope of this specification. 1083 15. Using "rcd" as additional claims to other PASSporT extensions 1085 Rich Call Data, including calling name information, for example, is 1086 often data that is additive data to the personal communications 1087 information defined in the core PASSporT data required to support the 1088 security properties defined in [RFC8225]. For cases where the entity 1089 that is originating the personal communications and additionally is 1090 supporting the authentication service and also is the authority of 1091 the Rich Call Data, rather than creating multiple identity headers 1092 with multiple PASSporT extensions or defining multiple combinations 1093 and permutations of PASSporT extension definitions, the 1094 authentication service can alternatively directly add the "rcd" 1095 claims to the PASSporT it is creating, whether it is constructed with 1096 a PASSporT extension or not. 1098 Note: There is one very important caveat to this capability, because 1099 generally if there is URI referenced content in an "rcd" PASSporT 1100 there is often the requirement to use "rcdi" and JWT Claims 1101 Constraints. So, it is important for the user of this specification 1102 to recognize that the certificates used must include the necessary 1103 JWT Claims Constraints for proper integrity and security of the 1104 values in the "rcd" claim incorporated into PASSporTs that are not 1105 "rcd". 1107 15.1. Procedures for applying "rcd" as claims only 1109 For a given PASSporT using some other extension than "rcd", the 1110 Authentication Service MAY additionally include the "rcd" claim as 1111 defined in this document. This would result in a set of claims that 1112 correspond to the original intended extension with the addition of 1113 the "rcd" claim. 1115 The Verification service that receives the PASSporT, if it supports 1116 this specification and chooses to, should interpret the "rcd" claim 1117 as simply just an additional claim intended to deliver and/or 1118 validate delivered Rich Call Data. 1120 15.2. Example for applying "rcd" as claims only 1122 In the case of [RFC8588] which is the PASSporT extension supporting 1123 the SHAKEN specification [ATIS-1000074], a common case for an 1124 Authentication service to co-exist in a CSP network along with the 1125 authority over the calling name used for the call. Rather than 1126 require two identity headers, the CSP Authentication Service can 1127 apply both the SHAKEN PASSporT claims and extension and simply add 1128 the "rcd" required claims defined in this document. 1130 For example, the PASSporT claims for the "shaken" PASSporT with "rcd" 1131 claims would be as follows: 1133 Protected Header 1134 { 1135 "alg":"ES256", 1136 "typ":"passport", 1137 “ppt”:”shaken”, 1138 "x5u":"https://cert.example.org/passport.cer" 1139 } 1140 Payload 1141 { 1142 “attest”:”A”, 1143 "dest":{“tn”:["12025551001"]}, 1144 "iat":1443208345, 1145 "orig":{“tn”:"12025551000"}, 1146 “origid”:”123e4567-e89b-12d3-a456-426655440000”, 1147 "rcd":{"nam":"James Bond"} 1148 } 1150 A Verification Service that supports "rcd" and "shaken" PASSporT 1151 extensions is able to receive the above PASSporT and interpret both 1152 the "shaken" claims as well as the "rcd" defined claim. 1154 If the Verification Service only understands the "shaken" extension 1155 claims but doesn't support "rcd", the "rcd" is ignored and 1156 disregarded. 1158 16. Acknowledgements 1160 We would like to thank David Hancock, Robert Sparks, Russ Housley, 1161 Eric Burger, Alec Fenichel, Ben Campbell, Jack Rickard for helpful 1162 suggestions, review, and comments. 1164 17. IANA Considerations 1166 17.1. JSON Web Token Claim 1168 This specification requests that the IANA add three new claims to the 1169 JSON Web Token Claims registry as defined in [RFC7519]. 1171 Claim Name: "rcd" 1173 Claim Description: Rich Call Data Information 1175 Change Controller: IESG 1177 Specification Document(s): [RFCThis] 1179 Claim Name: "rcdi" 1180 Claim Description: Rich Call Data Integrity Information 1182 Change Controller: IESG 1184 Specification Document(s): [RFCThis] 1186 Claim Name: "crn" 1188 Claim Description: Call Reason 1190 Change Controller: IESG 1192 Specification Document(s): [RFCThis] 1194 17.2. PASSporT Types 1196 This specification requests that the IANA add a new entry to the 1197 PASSporT Types registry for the type "rcd" which is specified in 1198 [RFCThis]. 1200 17.3. PASSporT RCD Types 1202 This document requests that the IANA create a new registry for 1203 PASSporT RCD types. Registration of new PASSporT RCD types shall be 1204 under the Specification Required policy. 1206 This registry is to be initially populated with four values, "nam", 1207 "apn", "jcd", and "jcl", which are specified in [RFCThis]. 1209 18. Security Considerations 1211 Whether its identities, alternate identities, images, logos, physical 1212 addresses, all of the information contained in a RCD PASSporT must 1213 follow some form of vetting in which the authoritative entity or user 1214 of the information being signed MUST follow an applicable policy of 1215 the eco-system using RCD. This can be of many forms, depending on 1216 the setup and constraints of the eco-system so is therefore out-of- 1217 scope of this document. However, the general chain of trust that 1218 signers of RCD PASSporT are either directly authoritative or have 1219 been delegated authority through certificates using JWT Claim 1220 Constraints and integrity mechanisms defined in this and related 1221 documents is critical to maintain the integrity of the eco-system 1222 utilizing this and other STIR related specifications. 1224 Revealing information such as the name, location, and affiliation of 1225 a person necessarily entails certain privacy risks. Baseline 1226 PASSporT has no particular confidentiality requirement, as the 1227 information it signs over in a using protocol like SIP is all 1228 information that SIP carries in the clear anyway. Transport-level 1229 security can hide those SIP fields from eavesdroppers, and the same 1230 confidentiality mechanisms would protect any PASSporT(s) carried in 1231 SIP. 1233 Since computation of "rcdi" digests for URIs requires the loading of 1234 referenced content, it would be best practice to validate that 1235 content at the creation of the "rcdi" or corresponding JWT claim 1236 constraint value by checking for content that may cause issues for 1237 verification services or that doesn't follow the behavior defined in 1238 this document, e.g. unreasonably sized data, the inclusion of 1239 recursive URI references, etc. Along the same lines, the 1240 verification service should also use precautionary best practices to 1241 avoid attacks when accessing URI linked content. 1243 18.1. The use of JWT Claim Constraints in delegate certificates to 1244 exclude unauthorized claims 1246 While this can apply to any PASSporT that is signed with a STIR 1247 Delegate Certificates [I-D.ietf-stir-cert-delegation], it is 1248 important to note that when constraining PASSporTs to include 1249 specific claims or contents of claims, it is also important to 1250 consider potential attacks by non-authorized signers that may include 1251 other potential PASSporT claims that weren't originally vetted by the 1252 authorized entity providing the delegate certificate. The use of JWT 1253 claims constraints as defined in [I-D.ietf-stir-enhance-rfc8226] for 1254 preventing the ability to include claims beyond the claims defined in 1255 this document may need to be considered. 1257 Certificate issuers SHOULD NOT include an entry in mustExclude for 1258 the "rcdi" claim for a certificate that will be used with the 1259 PASSporT Extension for Rich Call Data defined in this document. 1260 Excluding this claim would prevent the integrity protection mechanism 1261 from working properly. 1263 19. References 1265 19.1. Normative References 1267 [I-D.ietf-sipcore-callinfo-rcd] 1268 Wendt, C. and J. Peterson, "SIP Call-Info Parameters for 1269 Rich Call Data", Work in Progress, Internet-Draft, draft- 1270 ietf-sipcore-callinfo-rcd-02, 22 February 2021, 1271 . 1274 [I-D.ietf-stir-cert-delegation] 1275 Peterson, J., "Secure Telephone Identity Revisited (STIR) 1276 Certificate Delegation", Work in Progress, Internet-Draft, 1277 draft-ietf-stir-cert-delegation-04, 22 February 2021, 1278 . 1281 [I-D.ietf-stir-enhance-rfc8226] 1282 Housley, R., "Enhanced JSON Web Token (JWT) Claim 1283 Constraints for Secure Telephone Identity Revisited (STIR) 1284 Certificates", Work in Progress, Internet-Draft, draft- 1285 ietf-stir-enhance-rfc8226-05, 26 July 2021, 1286 . 1289 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1290 Requirement Levels", BCP 14, RFC 2119, 1291 DOI 10.17487/RFC2119, March 1997, 1292 . 1294 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1295 A., Peterson, J., Sparks, R., Handley, M., and E. 1296 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1297 DOI 10.17487/RFC3261, June 2002, 1298 . 1300 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1301 Extensions to the Session Initiation Protocol (SIP) for 1302 Asserted Identity within Trusted Networks", RFC 3325, 1303 DOI 10.17487/RFC3325, November 2002, 1304 . 1306 [RFC4627] Crockford, D., "The application/json Media Type for 1307 JavaScript Object Notation (JSON)", RFC 4627, 1308 DOI 10.17487/RFC4627, July 2006, 1309 . 1311 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1312 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1313 . 1315 [RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., 1316 "JavaScript Object Notation (JSON) Pointer", RFC 6901, 1317 DOI 10.17487/RFC6901, April 2013, 1318 . 1320 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, 1321 DOI 10.17487/RFC7095, January 2014, 1322 . 1324 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 1325 Telephone Identity Problem Statement and Requirements", 1326 RFC 7340, DOI 10.17487/RFC7340, September 2014, 1327 . 1329 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1330 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1331 . 1333 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1334 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1335 May 2017, . 1337 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 1338 "Authenticated Identity Management in the Session 1339 Initiation Protocol (SIP)", RFC 8224, 1340 DOI 10.17487/RFC8224, February 2018, 1341 . 1343 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 1344 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 1345 . 1347 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 1348 Credentials: Certificates", RFC 8226, 1349 DOI 10.17487/RFC8226, February 2018, 1350 . 1352 [RFC8588] Wendt, C. and M. Barnes, "Personal Assertion Token 1353 (PaSSporT) Extension for Signature-based Handling of 1354 Asserted information using toKENs (SHAKEN)", RFC 8588, 1355 DOI 10.17487/RFC8588, May 2019, 1356 . 1358 19.2. Informative References 1360 [ATIS-1000074] 1361 ATIS/SIP Forum NNI Task Group, "Signature-based Handling 1362 of Asserted information using toKENs (SHAKEN) 1363 ", January 2017. 1366 [I-D.ietf-stir-oob] 1367 Rescorla, E. and J. Peterson, "Secure Telephone Identity 1368 Revisited (STIR) Out-of-Band Architecture and Use Cases", 1369 Work in Progress, Internet-Draft, draft-ietf-stir-oob-07, 1370 9 March 2020, . 1373 Authors' Addresses 1375 Chris Wendt 1376 Comcast 1377 Comcast Technology Center 1378 Philadelphia, PA 19103, 1379 United States of America 1381 Email: chris-ietf@chriswendt.net 1383 Jon Peterson 1384 Neustar Inc. 1385 1800 Sutter St Suite 570 1386 Concord, CA 94520, 1387 United States of America 1389 Email: jon.peterson@neustar.biz