idnits 2.17.00 (12 Aug 2021) /tmp/idnits58287/draft-ietf-stir-passport-rcd-12.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: ---------------------------------------------------------------------------- No issues found here. 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 (July 12, 2021) is 313 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 1109, but not defined -- Possible downref: Normative reference to a draft: ref. 'I-D.housley-stir-enhance-rfc8226' == Outdated reference: A later version (-04) exists of draft-ietf-sipcore-callinfo-rcd-02 == Outdated reference: draft-ietf-stir-cert-delegation has been published as RFC 9060 ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) ** Downref: Normative reference to an Experimental RFC: RFC 6919 ** Downref: Normative reference to an Informational RFC: RFC 7340 == Outdated reference: draft-ietf-stir-oob has been published as RFC 8816 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 3 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: January 13, 2022 Neustar Inc. 6 July 12, 2021 8 PASSporT Extension for Rich Call Data 9 draft-ietf-stir-passport-rcd-12 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 intended called party. This framework 18 is intended to include and extend caller and call specific 19 information beyond human-readable display name comparable to the 20 "Caller ID" function common on the telephone network. The JSON 21 element defined for this purpose, Rich Call Data (RCD), is an 22 extensible object defined to either be used as part of STIR or with 23 SIP Call-Info to include related information about calls that helps 24 people decide whether to pick up the phone. This signing of the RCD 25 information is also enhanced with a integrity mechanism that is 26 designed to protect the authoring and transport of this information 27 between authoritative and non-authoritative parties generating and 28 signing the Rich Call Data for support of different usage and content 29 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 January 13, 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 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Overview of the use of the Rich Call Data PASSporT extension 4 68 4. Overview of Rich Call Data Integrity . . . . . . . . . . . . 5 69 5. PASSporT Claim "rcd" Defintion and Usage . . . . . . . . . . 6 70 5.1. PASSporT "rcd" Claim . . . . . . . . . . . . . . . . . . 6 71 5.1.1. "nam" key . . . . . . . . . . . . . . . . . . . . . . 7 72 5.1.2. "jcd" key . . . . . . . . . . . . . . . . . . . . . . 7 73 5.1.3. "jcl" key . . . . . . . . . . . . . . . . . . . . . . 7 74 6. "rcdi" RCD Integrity Claim Definition and Usage . . . . . . . 8 75 6.1. Creation of the "rcd" element digests . . . . . . . . . . 9 76 6.2. JWT Claim Constraint for "rcd" claims only . . . . . . . 12 77 7. JWT Claim Constraint usage for "rcd" and "rcdi" claims . . . 12 78 8. PASSporT "crn" claim - Call Reason Defintion and Usage . . . 13 79 8.1. JWT Constraint for "crn" claim . . . . . . . . . . . . . 13 80 9. Rich Call Data Claims Usage Rules . . . . . . . . . . . . . . 13 81 9.1. Example "rcd" PASSporTs . . . . . . . . . . . . . . . . . 14 82 10. Compact form of "rcd" PASSporT . . . . . . . . . . . . . . . 16 83 10.1. Compact form of the "rcd" PASSporT claim . . . . . . . . 16 84 10.2. Compact form of the "rcdi" PASSporT claim . . . . . . . 16 85 10.3. Compact form of the "crn" PASSporT claim . . . . . . . . 16 86 11. Further Information Associated with Callers . . . . . . . . . 16 87 12. Third-Party Uses . . . . . . . . . . . . . . . . . . . . . . 17 88 12.1. Signing as a Third Party . . . . . . . . . . . . . . . . 19 89 13. Levels of Assurance . . . . . . . . . . . . . . . . . . . . . 19 90 14. Using "rcd" in SIP . . . . . . . . . . . . . . . . . . . . . 20 91 14.1. Authentication Service Behavior . . . . . . . . . . . . 20 92 14.2. Verification Service Behavior . . . . . . . . . . . . . 21 93 15. Using "rcd" as additional claims to other PASSporT extensions 22 94 15.1. Procedures for applying "rcd" as claims only . . . . . . 22 95 15.2. Example for applying "rcd" as claims only . . . . . . . 23 97 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 98 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 99 17.1. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 24 100 17.2. PASSporT Types . . . . . . . . . . . . . . . . . . . . . 24 101 17.3. PASSporT RCD Types . . . . . . . . . . . . . . . . . . . 24 102 18. Security Considerations . . . . . . . . . . . . . . . . . . . 25 103 18.1. The use of JWT Claim Constraints in delegate 104 certificates to exclude unauthorized claims . . . . . . 25 105 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 106 19.1. Normative References . . . . . . . . . . . . . . . . . . 25 107 19.2. Informative References . . . . . . . . . . . . . . . . . 27 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 110 1. Introduction 112 PASSporT [RFC8225] is a token format based on JWT [RFC7519] for 113 conveying cryptographically-signed information about the parties 114 involved in personal communications; it is used to convey a signed 115 assertion of the identity of the participants in real-time 116 communications established via a protocol like SIP [RFC8224]. The 117 STIR problem statement [RFC7340] declared securing the display name 118 of callers outside of STIR's initial scope, so baseline STIR provides 119 no features for caller name. This specification documents an 120 optional mechanism for PASSporT and the associated STIR procedures 121 which extend PASSporT objects to protect additional elements 122 conveying richer information: information that is intended to be 123 rendered to assist a called party in determining whether to accept or 124 trust incoming communications. This includes the name of the person 125 on one side of a communications session, the traditional "Caller ID" 126 of the telephone network, along with related display information that 127 would be rendered to the called party during alerting, or potentially 128 used by an automaton to determine whether and how to alert a called 129 party. 131 Traditional telephone network signaling protocols have long supported 132 delivering a 'calling name' from the originating side, though in 133 practice, the terminating side is often left to derive a name from 134 the calling party number by consulting a local address book or an 135 external database. SIP similarly can carry this information in a 136 'display-name' in the From header field value from the originating to 137 terminating side, or alternatively in the Call-Info header field. 138 However, both are unsecured fields that really cannot be trusted in 139 most interconnected SIP deployments, and therefore is a good starting 140 point for a framework that utilizes STIR techniques and procedures 141 for protecting call related information including but not limited to 142 calling name. 144 As such, the baseline use-case for this document extends PASSporT to 145 provide cryptographic protection for the "display-name" field of SIP 146 requests as well as further "rich call data" (RCD) about the caller, 147 which includes the contents of the Call-Info header field or other 148 data structures that can be added to the PASSporT. This document 149 furthermore specifies a third-party profile that would allow external 150 authorities to convey rich information associated with a calling 151 number via a new type of PASSporT. Finally, this document describes 152 how to preserve the integrity of the RCD in scenarios where there may 153 be non-authoritative users initiating and signing RCD and therefore a 154 constraint on the RCD data that a PASSporT can attest via 155 certificate-level controls. 157 2. Terminology 159 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 160 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 161 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 162 described in [RFC2119] and [RFC6919]. 164 3. Overview of the use of the Rich Call Data PASSporT extension 166 The main intended use of the signing of Rich Call Data (RCD) using 167 STIR [RFC8224] and as a PASSporT extension [RFC8225] is for the 168 entity that originates a call, either directly the caller themselves, 169 if they are authoritative, or a service provider or third-party 170 service that may be authoritative over the rich call data on behalf 171 of the caller. 173 The RCD described in this document is of two main categories. The 174 first data is a more traditional set of info about a caller 175 associated with "display-name" in SIP [RFC3261], typically a textual 176 description of the caller. The second category is a set of RCD that 177 is defined as part of the jCard definitions or extensions to that 178 data. [I-D.ietf-sipcore-callinfo-rcd] describes the optional use of 179 jCard in Call-Info header field as RCD with the "jcard" Call-Info 180 purpose token. Either or both of these two types of data can be 181 incorporated into a "rcd" claim defined in this document. 183 Additionally, [I-D.ietf-sipcore-callinfo-rcd] also describes a "call- 184 reason" parameter intended for description of the intent or reason 185 for a particular call. A new PASSporT claim "crn", or call reason, 186 can contain the string or object that describes the intent of the 187 call. This claim is intentionally kept separate from the "rcd" claim 188 because it is envisioned that call reason is not the same as 189 information associated with the caller and may change on a more 190 frequent, per call, type of basis. 192 4. Overview of Rich Call Data Integrity 194 When incorporating call data that represents a user, even in 195 traditional calling name services today, often there is policy and 196 restrictions around what data is allowed to be used. Whether 197 preventing offensive language or icons or enforcing uniqueness, 198 potential trademark violations or other policy enforcement, there 199 should be the desire to pre-certify or "vet" the specific use of rich 200 call data. This document defines a mechanism that allows for a 201 direct or indirect party that controls the policy to approve or 202 certify the content, create a cryptographic digest that can be used 203 to validate that data and applies a constraint in the certificate to 204 allow the recipient and verifier to validate that the specific 205 content of the RCD is as intended at its creation and approval or 206 certification. 208 There are two mechanisms that are defined to accomplish that for two 209 distinct categories of purposes. The first of the mechanisms include 210 the definition of an integrity claim. The RCD integrity mechanism is 211 a process of generating a sufficiently strong cryptographic digest 212 for both the "rcd" claim contents (e.g. "nam", "jcd", "jcl") defined 213 below and the resources defined by one or more globally unique HTTPS 214 URLs referenced by the contents (e.g. an image file referenced by 215 "jcd" or a jCard referenced by "jcl"). This mechanism is inspired by 216 and based on the W3C Subresource Integrity specification 217 (http://www.w3.org/TR/SRI/). The second of the mechanisms uses the 218 capability called JWT Claim Constraints, defined in [RFC8226] and 219 extended in [I-D.housley-stir-enhance-rfc8226]. The JWT Claim 220 Constraints specifically guide the verifier within the certificate 221 used to sign the PASSporT for the inclusion (or exclusion) of 222 specific claims and their values, so that the content intended by the 223 signer can be verified to be accurate. 225 Both of these mechanisms, integrity digests and JWT Claims 226 Constraints, can be used together or separately depending on the 227 intended purpose. The first category of purpose is whether the rich 228 call data conveyed by the RCD passport is pass-by-value or passed-by- 229 reference; i.e., is the information contained in the passport claims 230 and therefore integrity protected by the passport signature, or is 231 the information contained in an external resource referenced by a URI 232 in the RCD PASSporT. The second category of purpose is whether the 233 signer is authoritative or has responsibility for the accuracy of the 234 RCD based on the policies of the eco-system the RCD PASSporTs are 235 being used. 237 The following table provides an overview of the framework for how 238 integrity should be used with RCD. (Auth represents authoritative in 239 this table) 240 +----------+---------------------+--------------------------------+ 241 | Modes | No external URIs | Includes URI refs | 242 +----------+---------------------+--------------------------------+ 243 | Auth | 1: No integrity req | 2: RDC Integrity | 244 +----------+---------------------+--------------------------------+ 245 | Non-Auth | 3: JWT Claim Const. | 4: RCD Integ./JWT Claim Const. | 246 +----------+---------------------+--------------------------------+ 248 The first and simplest mode is exclusively for when all RCD content 249 is directly included as part of the claims (i.e. no external 250 reference URIs are included in the content) and when the signer is 251 authoritative over the content. In this mode, integrity protection 252 is not required and the set of claims is simply protected by the 253 signature of the standard PASSporT [RFC8225] and SIP identity header 254 [RFC8224] procedures. The second mode is an extension of the first 255 where the signer is authoritative and a "rcd" claim contents include 256 a URI identifying external resources. In this mode, an RCD Integrity 257 or "rcdi" claim MUST be included. This integrity claim is defined 258 later in this document and provides a digest of the "rcd" claim 259 content so that, particularly for the case where there are URI 260 references in the RCD, the content of that RCD can be comprehensively 261 validated that it was received as intended by the signer of the 262 PASSporT. 264 The third and fourth mode cover cases where there is a different 265 authoritative entity responsible for the content of the RCD, separate 266 from the signer of the PASSporT itself, allowing the ability to have 267 forward control at the time of the creation of the certificate of the 268 allowed or vetted content included in or referenced by the RCD claim 269 contents. The primary framework for allowing the separation of 270 authority and the signing of PASSporTs by non-authorized entities is 271 detailed in [I-D.ietf-stir-cert-delegation] although other cases may 272 apply. As with the first and second modes, the third and fourth 273 modes differ with the absence or inclusion of externally referenced 274 content using URIs. 276 5. PASSporT Claim "rcd" Defintion and Usage 278 5.1. PASSporT "rcd" Claim 280 This specification defines a new JSON Web Token claim for "rcd", Rich 281 Call Data, the value of which is a JSON object that can contain one 282 or more key value pairs. This document defines a default set of key 283 values. 285 5.1.1. "nam" key 287 The "nam" key value is a display name, associated with the originator 288 of personal communications, which may for example derive from the 289 display-name component of the From header field value of a SIP 290 request or alternatively from the P-Asserted-Identity header field 291 value, or a similar field in other PASSporT using protocols. This 292 key MUST be included once and MUST be included as part of the "rcd" 293 claim value JSON object. If there is no string associated with a 294 display name, the claim value SHOULD then be an empty string. 296 5.1.2. "jcd" key 298 The "jcd" key value is defined to contain a value of a jCard 299 [RFC7095] JSON object. This jCard object is intended to represent 300 and derives from the Call-Info header field value defined in 301 [I-D.ietf-sipcore-callinfo-rcd] with a type of "jcard". As also 302 defined in [I-D.ietf-sipcore-callinfo-rcd], format of the jCard and 303 properties used should follow the normative usage and formatting 304 rules and procedures. It is an extensible object where the calling 305 party can provide both the standard types of information defined in 306 jCard or can use the built-in extensibility of the jCard 307 specification to add additional information. The "jcd" is optional. 308 If included, this key MUST only be included once in the "rcd" JSON 309 object and MUST NOT be included if there is a "jcl" key included. 310 The use of "jcd" and "jcl" keys are mutually exclusive. 312 The jCard object value for "jcd" MUST only have referenced content 313 for URI values that do not further reference URIs. Future 314 specifications may extend this capability, but as stated in 315 [I-D.ietf-sipcore-callinfo-rcd] it constrains the security properties 316 of RCD information and the integrity of the content referenced by 317 URIs. 319 Note: even though we refer to [I-D.ietf-sipcore-callinfo-rcd] as the 320 definition of the jcard properties for usage in a "rcd" PASSporT, 321 other protocols can be adapted for use of "jcd" (or similarly "jcl" 322 below) key beyond SIP and Call-Info. 324 5.1.3. "jcl" key 326 The "jcl" key value is defined to contain a HTTPS URL that refers the 327 recipient to a jCard [RFC7095] JSON object hosted on a HTTPS enabled 328 web server. The web server MUST use the MIME media type for JSON 329 text as application/json with a default encoding of UTF-8 [RFC4627]. 330 This link may derive from the Call-Info header field value defined in 331 [I-D.ietf-sipcore-callinfo-rcd] with a type of "jcard". As also 332 defined in [I-D.ietf-sipcore-callinfo-rcd], format of the jCard and 333 properties used should follow the normative usage and formatting 334 rules and procedures. The "jcl" key is optional. If included, this 335 key MUST only be included once in the "rcd" JSON object and MUST NOT 336 be included if there is a "jcd" key included. The use of "jcd" and 337 "jcl" keys are mutually exclusive. 339 The jCard object value referenced in the URI value for "jcl" MUST 340 only have referenced content for URI values that do not further 341 reference URIs. Future specifications may extend this capability, 342 but as stated in [I-D.ietf-sipcore-callinfo-rcd] it constrains the 343 security properties of RCD information and the integrity of the 344 content referenced by URIs. 346 6. "rcdi" RCD Integrity Claim Definition and Usage 348 The "rcdi" claim is included for the second and fourth modes 349 described in integrity overview section of this document. If this 350 claim is present it MUST be only included once with the corresponding 351 single "rcd" claim. The value of the "rcdi" key pair is a JSON 352 object that is defined as follows. 354 The claim value of "rcdi" claim key is a JSON object with a set of 355 JSON key/value pairs. These objects correspond to each of the 356 elements of the "rcd" claim object that require integrity protection 357 with an associated digest over the content referenced by the key 358 string. The individual digest of different elements of the "rcd" 359 claim data and external URI referenced content is kept specifically 360 separate to allow the ability to verify the integrity of only the 361 elements that are ultimately retrieved or downloaded or rendered to 362 the end-user. 364 The key value references a specific object within the "rcd" claim 365 value using a JSON pointer defined in [RFC6901] with a minor 366 additional rule to support external URI references that include JSON 367 objects themselves, in particular for the specific case of the use of 368 "jcl". JSON pointer syntax is the key value that specifies exactly 369 the part of JSON that is used to generate the digest which produce 370 the resulting string that makes up the value for the corresponding 371 key. Detailed procedures are provided below, but an example "rcdi" 372 is provided here: 374 "rcdi" : { 375 "/jcd": "sha256-H8BRh8j48O9oAZzq6A9RINQZngK7T62em8MUt1FLm52", 376 "/jcd/1/2/3": "sha256-AZzq6A9RINQZngK7T62em8MUt1FLm52H8BRh8j48O9o" 377 } 379 The values of each key pair are a digest combined with a string that 380 defines the crypto algorithm used to generate the digest. For RCD, 381 implementations MUST support the following hash algorithms, "SHA256", 382 "SHA384", or "SHA512". The SHA-256, SHA-384, and SHA-512 are part of 383 the SHA-2 set of cryptographic hash functions defined by the NIST. 384 Implementations MAY support additional algorithms, but MUST NOT 385 support known weak algorithms such as MD5 or SHA-1. In the future, 386 the list of algorithms may be re-evaluated based on security best 387 practices. The algorithms are represented in the text by "sha256", 388 "sha384", or "sha512". The character following the algorithm string 389 MUST be a minus character, "-". The subsequent characters are the 390 base64 encoded digest of a canonicalized and concatenated string 391 based on the JSON pointer referenced elements of "rcd" claim or the 392 URI referenced content contained in the claim. The details of the 393 determination of the input string used to determine the digest are 394 defined in the next section. 396 6.1. Creation of the "rcd" element digests 398 "rcd" claim objects can contain "nam", "jcd", or "jcl" keys as part 399 of the "rcd" JSON object claim value. This specification defines the 400 use of JSON pointer [RFC6901] as a basic to reference specific 401 elements. 403 In the case of "nam", the only allowed value is a "string". In order 404 to reference the "nam" string value for a digest, the JSON pointer 405 string would be "/nam" and the digest string would be created using 406 only the string pointed to by that "/nam" following the rules of JSON 407 pointer. 409 In the case of "jcd", the value associated is a jCard JSON object, 410 which happens to be a JSON array with sub-arrays. JSON pointer 411 notation uses numeric indexes into elements of arrays, including when 412 those elements are arrays themselves. 414 As example, for the following "rcd" claim: 416 "rcd": { 417 "nam": "Q Branch Spy Gadgets", 418 "jcd": ["vcard", 419 [ ["version",{},"text","4.0"], 420 ["fn",{},"text","Q Branch"], 421 ["org",{},"text","MI6;Q Branch Spy Gadgets"], 422 ["photo",{},"uri", 423 "https://example.com/photos/quartermaster-256x256.png"], 424 ["logo",{},"uri", 425 "https://example.com/logos/mi6-256x256.jpg"], 426 ["logo",{},"uri", 427 "https://example.com/logos/mi6-64x64.jpg"] 428 ] 429 ] 430 } 432 In order to use JSON pointer to refer to the URIs, the following 433 example "rcdi" claim includes a digest for the entire "jcd" array 434 string as well as three additional digests for the URIs, where, as 435 defined in [RFC6901] zero-based array indexes are used to reference 436 the URI strings. 438 "rcdi": { 439 "/jcd": "sha256-30SFLGHL40498527", 440 "/jcd/1/3/3": "sha256-12938918VNJDSNCJ", 441 "/jcd/1/4/3": "sha256-VNJDSNCJ12938918", 442 "/jcd/1/5/3": "sha256-4049852730SFLGHL" 443 } 444 } 446 For the use of JSON pointer in "jcd" and because array indexes are 447 dependent on the order of the elements in the jCard, the digest for 448 the "/jcd" corresponding to the entire jCard array string MUST be 449 included to avoid any possibility of substitution or insertion 450 attacks that may be possible to avoid integrity detection, even 451 though unlikely. Each URI referenced in the jCard array string MUST 452 have a corresponding JSON pointer string key and digest value. 454 In the case of the use of a "jcl" URI reference to an external jCard, 455 the procedures are similar to "jcd" with the exception and the minor 456 modification to JSON pointer, where "/jcl" is used to refer to the 457 external jCard array string and any following numeric array indexes 458 added to the "jcl" (e.g. "/jcl/1/2/3") are treated as if the 459 externally referenced jCard was directly part of the overall "rcd" 460 claim JSON object. The following example illustrates a "jcl" version 461 of the above "jcd" example. 463 "rcd": { 464 "nam": "Q Branch Spy Gadgets", 465 "jcl": "https://example.com/qbranch.json" 466 }, 467 "rcdi": { 468 "/jcl": "sha256-30SFLGHL40498527", 469 "/jcl/1/3/3": "sha256-12938918VNJDSNCJ", 470 "/jcl/1/4/3": "sha256-VNJDSNCJ12938918", 471 "/jcl/1/5/3": "sha256-4049852730SFLGHL" 472 } 474 https://example.com/qbranch.json: 475 ["vcard", 476 [ ["version",{},"text","4.0"], 477 ["fn",{},"text","Q Branch"], 478 ["org",{},"text","MI6;Q Branch Spy Gadgets"] 479 ["photo",{},"uri", 480 "https://example.com/photos/quartermaster-256x256.png"] 481 ["logo",{},"uri", 482 "https://example.com/logos/mi6-256x256.jpg"] 483 ["logo",{},"uri", 484 "https://example.com/logos/mi6-64x64.jpg"] 485 ] 486 ] 488 In order to facilitate proper verification of the digests and whether 489 the "rcd" elements or content referenced by URIs were modified, the 490 input to the digest must be completely deterministic at three points 491 in the process. First, at the certification point where the content 492 is evaluated to conform to the application policy and the JWT Claim 493 Constraints is applied to the certificate containing the digest. 494 Second, when the call is signed at the Authentication Service, there 495 may be a local policy to verify that the provided "rcd" claim 496 corresponds to each digest. Third, when the "rcd" data is verified 497 at the Verification Service, the verification is performed for each 498 digest by constructing the input digest string for the element being 499 verified and referenced by the JSON pointer string. 501 The procedure for the creation of each "rcd" element digest string 502 corresponding to a JSON pointer string key is as follows. 504 1. The JSON pointer either refers to an element that is a part or 505 whole of a JSON object string or to a string that is a URI 506 referencing an external resource. 508 2. For a JSON formatted string, serialize the element JSON to remove 509 all white space and line breaks. The procedures of this 510 deterministic JSON serialization are defined in [RFC8225], 511 Section 9. The resulting string is used to create the digest. 513 3. For any URI referenced content, the content can either be a 514 string as in jCard JSON objects or binary content. For example, 515 image and audio files contain binary content. If the content is 516 binary format it should be Base64 encoded to create a string, 517 otherwise the direct string content of the file is used to create 518 the digest. 520 6.2. JWT Claim Constraint for "rcd" claims only 522 For the third mode described in the integrity overview section of 523 this document, where only JWT Claim Constraint for "rcd" claims 524 without an "rcdi" claim is required, the procedure should be, when 525 creating the certificate, to include a JWT Claim Constraint on 526 inclusion of an "rcd" claim as well as the contents of the certified 527 "rcd" claim. 529 The certificate JWT Claims Constraint MUST include the following: 531 o a "mustInclude" for the "rcd" claim and a "permittedValues" equal 532 to the created "rcd" claim value string. 534 The "permitedValues" for the "rcd" claim may optionally contain 535 multiple entries, to support the case where the certificate holder is 536 authorized to use different sets of rich call data. 538 7. JWT Claim Constraint usage for "rcd" and "rcdi" claims 540 The integrity overview section of this document describes a fourth 541 mode where both "rcdi" and JWT Claim Constraints is used. The use of 542 this mode implies the signing of an "rcdi" claim is required to be 543 protected by the authoritative certificate creator using JWT Claims 544 Constraints in the certificate. The intension of the use of both of 545 these mechanisms is to constrain the signer to construct the "rcd" 546 and "rcdi" claims with the "rcd" jCard object including reference 547 external content via URI. Once both the contents of the "rcd" claim 548 and any linked content is certified by the party that is 549 authoritative for the certificate being created and the construction 550 of the "rcdi" claim is complete, the "rcdi" claim is linked to the 551 STIR certificate associated with the signature in the PASSporT via 552 JWT Claim Constraints as defined in [RFC8226] Section 8. It should 553 be recognized that the "rcdi" set of digests is intended to be unique 554 for only a specific combination of "rcd" content and URI referenced 555 external content, and therefore provides a robust integrity mechanism 556 for an authentication service being performed by a non-authoritative 557 party. This would often be associated with the use of delegate 558 certificates [I-D.ietf-stir-cert-delegation] for the signing of calls 559 by the calling party directly as an example, even though they aren't 560 considered an "authorized party" in the STIR certificate eco-system. 562 The certificate JWT Claims Constraint MUST include both of the 563 following: 565 o a "mustInclude" for the "rcd" claim, which simply constrains the 566 fact that an "rcd" should be included if there is a "rcdi" 568 o a "mustInclude" for the "rcdi" claim and a "permittedValues" equal 569 to the created "rcdi" claim value string. 571 The "permitedValues" for the "rcdi" claim may contain multiple 572 entries, to support the case where the certificate holder is 573 authorized to use different sets of rich call data. 575 8. PASSporT "crn" claim - Call Reason Defintion and Usage 577 This specification defines a new JSON Web Token claim for "crn", Call 578 Reason, the value of which is a single string or object that can 579 contains information as defined in [I-D.ietf-sipcore-callinfo-rcd] 580 corresponding to the "reason" parameter for the Call-Info header. 581 This claim is optional. 583 Example "crn" claim with "rcd": 584 "rcd": { "nam": "James Bond", 585 "jcl": "https://example.org/james_bond.json"}, 586 "crn" : "For your ears only" 588 8.1. JWT Constraint for "crn" claim 590 The integrity of the "crn" claim can optionally be protected by the 591 authoritative certificate creator using JWT Constraints in the 592 certificate. If this protection is used, a "mustInclude" for the 593 "crn" claim and a "permittedValues" equal to the "crn" claim value 594 string SHOULD be included. 596 9. Rich Call Data Claims Usage Rules 598 Either or both the "rcd" or "crn" claims may appear in any PASSporT 599 claims object as optional elements. The creator of a PASSporT MAY 600 also add a "ppt" value of "rcd" to the header of a PASSporT as well, 601 in which case the PASSporT claims MUST contain either a "rcd" or 602 "crn" claim, and any entities verifying the PASSporT object are 603 required to understand the "ppt" extension in order to process the 604 PASSporT in question. An example PASSporT header with the "ppt" 605 included is shown as follows: 607 { "typ":"passport", 608 "ppt":"rcd", 609 "alg":"ES256", 610 "x5u":"https://www.example.com/cert.cer" } 612 The PASSporT claims object contains the "rcd" key with its 613 corresponding value. The value of "rcd" is an array of JSON objects, 614 of which one, the "nam" object, is mandatory. The key syntax of 615 "nam" follows the display-name ABNF given in [RFC3261]. 617 After the header and claims PASSporT objects have been constructed, 618 their signature is generated normally per the guidance in [RFC8225]. 620 9.1. Example "rcd" PASSporTs 622 An example of a "nam" only PASSporT claims object is shown next (with 623 line breaks for readability only). 625 { "orig":{"tn":"12025551000"}, 626 "dest":{"tn":["12025551001"]}, 627 "iat":1443208345, 628 "rcd":{"nam":"James Bond"} } 630 An example of a "nam" only PASSporT claims object with an "rcdi" 631 claim is shown next (with line breaks for readability only). 633 { "orig":{"tn":"12025551000"}, 634 "dest":{"tn":["12025551001"]}, 635 "iat":1443208345, 636 "rcd":{"nam":"James Bond"}, 637 "rcdi":{"/nam": "sha256-918VNJD12938SNCJ"} 638 } 640 An example of a "rcd" claims object that includes the "jcd" and also 641 contains a URI which requires the inclusion of an "rcdi" claim. 643 { 644 "orig": { "tn": "12025551000"}, 645 "dest": { "tn": ["12155551001"]}, 646 "iat": 1443208345, 647 "rcd": { 648 "nam": "Q Branch Spy Gadgets", 649 "jcd": ["vcard", 650 [ ["version",{},"text","4.0"], 651 ["fn",{},"text","Q Branch"], 652 ["org",{},"text","MI6;Q Branch Spy Gadgets"], 653 ["photo",{},"uri","https://example.com/photos/q-256x256.png"], 654 ["logo",{},"uri","https://example.com/logos/mi6-256x256.jpg"], 655 ["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg"] 656 ] ] 657 }, 658 "crn": "Rendezvous for Little Nellie", 659 "rcdi": { 660 "/nam": "sha256-918VNJD12938SNCJ", 661 "/jcd": "sha256-VNJDSNCJ12938918", 662 "/jcd/1/3/3": "sha256-12938918VNJDSNCJ", 663 "/jcd/1/4/3": "sha256-VNJDSNCJ12938918", 664 "/jcd/1/5/3": "sha256-4049852730SFLGHL" 665 } 666 } 668 In an example PASSporT, where a jCard is linked via HTTPS URL using 669 "jcl", a jCard file served at a particular URL. 671 An example jCard JSON file is shown as follows: 673 https://example.com/qbranch.json: 674 ["vcard", 675 [ ["version",{},"text","4.0"], 676 ["fn",{},"text","Q Branch"], 677 ["org",{},"text","MI6;Q Branch Spy Gadgets"], 678 ["photo",{},"uri","https://example.com/photos/q-256x256.png"], 679 ["logo",{},"uri","https://example.com/logos/mi6-256x256.jpg"], 680 ["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg"] 681 ] 682 ] 684 If that jCard is hosted at the example address of 685 "https://example.com/qbranch.json", the corresponding PASSporT claims 686 object would be as follows: 688 { 689 "orig": {"tn": "12025551000"}, 690 "dest": {"tn": ["12155551001"]}, 691 "iat": 1443208345, 692 "rcd": { 693 "nam": "Q Branch Spy Gadgets", 694 "jcl": "https://example.com/qbranch.json" 695 }, 696 "crn": "Rendezvous for Little Nellie", 697 "rcdi": { 698 "/nam": "sha256-918VNJD12938SNCJ", 699 "/jcl": "sha256-VNJDSNCJ12938918", 700 "/jcl/1/3/3": "sha256-12938918VNJDSNCJ", 701 "/jcl/1/4/3": "sha256-VNJDSNCJ12938918", 702 "/jcl/1/5/3": "sha256-4049852730SFLGHL" 703 } 704 } 706 10. Compact form of "rcd" PASSporT 708 10.1. Compact form of the "rcd" PASSporT claim 710 Compact form of an "rcd" PASSporT claim has some restrictions but 711 mainly follows standard PASSporT compact form procedures. For re- 712 construction of the "nam" claim the string for the display-name in 713 the From header field. For re-construction of the "jcl", the Call- 714 Info header as with purpose "jcard" defined in 715 [I-D.ietf-sipcore-callinfo-rcd] MUST be used. "jcd" claim MAY NOT be 716 used as part of compact form. 718 10.2. Compact form of the "rcdi" PASSporT claim 720 Compact form of an "rcdi" PASSporT claim is not supported, so if 721 "rcdi" is required compact form should not be used. 723 10.3. Compact form of the "crn" PASSporT claim 725 Compact form of a "crn" PASSporT claim shall be re-constructed using 726 the "call-reason" parameter of a Call-Info header as defined by 727 [I-D.ietf-sipcore-callinfo-rcd]. 729 11. Further Information Associated with Callers 731 Beyond naming information and the information that can be contained 732 in a jCard [RFC7095] object, there may be additional human-readable 733 information about the calling party that should be rendered to the 734 end user in order to help the called party decide whether or not to 735 pick up the phone. This is not limited to information about the 736 caller, but includes information about the call itself, which may 737 derive from analytics that determine based on call patterns or 738 similar data if the call is likely to be one the called party wants 739 to receive. Such data could include: 741 o information related to the location of the caller, or 743 o any organizations or institutions that the caller is associated 744 with, or even categories of institutions (is this a government 745 agency, or a bank, or what have you), or 747 o hyperlinks to images, such as logos or pictures of faces, or to 748 similar external profile information, or 750 o information processed by an application before rendering it to a 751 user, like social networking data that shows that an unknown 752 caller is a friend-of-a-friend, or reputation scores derived from 753 crowdsourcing, or confidence scores based on broader analytics 754 about the caller and callee. 756 All of these data elements would benefit from the secure attestations 757 provided by the STIR and PASSporT frameworks. A new IANA registry 758 has been defined to hold potential values of the "rcd" array; see 759 Section 17.3. Specific extensions to the "rcd" PASSporT claim are 760 left for future specification. 762 There is a few ways RCD can be extended in the future, jCard is an 763 extensible object and the key/values in the RCD claim object can also 764 be extended. General guidance for future extensibility that were 765 followed by the authors is that jCard generally should refer to data 766 that references the caller as an individual or entity, where other 767 claims, such as "crn" refer to data regarding the specific call. 768 There may be other considerations discovered in the future, but this 769 logical grouping of data to the extent possible should be followed 770 for future extensibility. 772 12. Third-Party Uses 774 While rich data about the call can be provided by an originating 775 authentication service, an intermediary in the call path could also 776 acquire rich call data by querying a third-party service. Such a 777 service effectively acts as a STIR Authentication Service, generating 778 its own PASSporT, and that PASSporT could be attached to a SIP call 779 by either the originating or terminating side. This third-party 780 PASSporT attests information about the calling number, rather than 781 the call or caller itself, and as such its RCD MUST NOT be used when 782 a call lacks a first-party PASSporT that assures verification 783 services that the calling party number is not spoofed. It is 784 intended to be used in cases when the originating side does not 785 supply a display-name for the caller, so instead some entity in the 786 call path invokes a third-party service to provide rich caller data 787 for a call. 789 In telephone operations today, a third-party information service is 790 commonly queried with the calling party's number in order to learn 791 the name of the calling party, and potentially other helpful 792 information could also be passed over that interface. The value of 793 using a PASSporT to convey this information from third parties lies 794 largely in the preservation of the third party's signature over the 795 data, and the potential for the PASSporT to be conveyed from 796 intermediaries to endpoint devices. Effectively, these use cases 797 form a sub-case of out-of-band [I-D.ietf-stir-oob] use cases. The 798 manner in which third-party services are discovered is outside the 799 scope of this document. 801 An intermediary use case might look as follows: a SIP INVITE carries 802 a display name in its From header field value and an initial PASSporT 803 object without the "rcd" claim. When a terminating verification 804 service implemented at a SIP proxy server receives this request, and 805 determines that the signature is valid, it might query a third-party 806 service that maps telephone numbers to calling party names. Upon 807 receiving the PASSport in a response from that third-party service, 808 the terminating side could add a new Identity header field to the 809 request for the "rcd" PASSporT object provided by the third-party 810 service. It would then forward the INVITE to the terminating user 811 agent. If the display name in the "rcd" PASSporT object matches the 812 display name in the INVITE, then the name would presumably be 813 rendered to the end user by the terminating user agent. 815 A very similar flow could be followed by an intermediary closer to 816 the origination of the call. Presumably such a service could be 817 implemented at an originating network in order to decouple the 818 systems that sign for calling party numbers from the systems that 819 provide rich data about calls. 821 In an alternative use case, the terminating user agent might query a 822 third-party service. In this case, no new Identity header field 823 would be generated, though the terminating user agent might receive a 824 PASSporT object in return from the third-party service, and use the 825 "rcd" field in the object as a calling name to render to users while 826 alerting. 828 While in the traditional telephone network, the business relationship 829 between calling customers and their telephone service providers is 830 the ultimate root of information about a calling party's name, some 831 other forms of data like crowdsourced reputation scores might derive 832 from third parties. When those elements are present, they MUST be in 833 a third-party "rcd" PASSporT using "iss" claim described in the next 834 section. 836 12.1. Signing as a Third Party 838 A third-party PASSporT contains an "iss" element to distinguish its 839 PASSporTs from first-party PASSporTs. Third-party "rcd" PASSporTs 840 are signed with credentials that do not have authority over the 841 identity that appears in the "orig" element of the PASSporT claims. 842 The presence of "iss" signifies that a different category of 843 credential is being used to sign a PASSporT than the [RFC8226] 844 certificates used to sign STIR calls; it is instead a certificate 845 that identifies the source of the "rcd" data. How those credentials 846 are issued and managed is outside the scope of this specification; 847 the value of "iss" however MUST reflect the Subject Name field of the 848 certificate used to sign a third-party PASSporT. The explicit 849 mechanism for reflecting the Subject Name field of the certificate is 850 out of scope of this document and left to the certificate governance 851 policies that define how to map the "iss" value in the PASSporT to 852 the Subject Name field in the certificate. Relying parties in STIR 853 have always been left to make their own authorization decisions about 854 whether to trust the signers of PASSporTs, and in the third-party 855 case, where an entity has explicitly queried a service to acquire the 856 PASSporT object, it may be some external trust or business 857 relationship that induces the relying party to trust a PASSporT. 859 An example of a Third Party issued PASSporT claims object is as 860 follows. 862 { "orig":{"tn":"12025551000"}, 863 "dest":{"tn":["12025551001"]}, 864 "iat":1443208345, 865 "iss":"Zorin Industries", 866 "rcd":{"nam":"James St. John Smythe"} } 868 13. Levels of Assurance 870 As "rcd" can be provided by either first or third parties, relying 871 parties could benefit from an additional claim that indicates the 872 relationship of the attesting party to the caller. Even in first 873 party cases, this admits of some complexity: the Communications 874 Service Provider (CSP) to which a number was assigned might in turn 875 delegate the number to a reseller, who would then sell the number to 876 an enterprise, in which case the CSP might have little insight into 877 the caller's name. In third party cases, a caller's name could 878 derive from any number of data sources, on a spectrum between public 879 data scraped from web searches to a direct business relationship to 880 the caller. As multiple PASSporTs can be associated with the same 881 call, potentially a verification service could receive attestations 882 of the caller name from multiple sources, which have different levels 883 of granularity or accuracy. Therefore, third-party PASSporTs that 884 carry "rcd" data MUST also carry an indication of the relationship of 885 the generator of the PASSporT to the caller in the form of the "iss" 886 claim. As stated in the previous section, the use of "iss" MUST 887 reflect the Subject Name of the certificate used to sign a third- 888 party PASSporT to represent that relationship. 890 14. Using "rcd" in SIP 892 This section specifies SIP-specific usage for the "rcd" claim in 893 PASSporT, and in the SIP Identity header field value. Other using 894 protocols of PASSporT may define their own usages for the "rcd" 895 claim. 897 14.1. Authentication Service Behavior 899 An authentication service creating a PASSporT containing a "rcd" 900 claim MAY include a "ppt" for "rcd" or not. Third-party 901 authentication services following the behavior in Section 12.1 MUST 902 include a "ppt" of "rcd". If "ppt" does contain a "rcd", then any 903 SIP authentication services MUST add a "ppt" parameter to the 904 Identity header containing that PASSporT with a value of "rcd". The 905 resulting Identity header might look as follows: 907 Identity: sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9 908 dlxkWzoeU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgt 909 w0Lu5csIppPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=; 910 info=;alg=ES256; 911 ppt="rcd" 913 This specification assumes that by default, a SIP authentication 914 service derives the value of "rcd", specifically only for the "nam" 915 key value, from the display-name component of the From header field 916 value of the request, alternatively for some calls this may come from 917 the P-Asserted-ID header. It is however a matter of authentication 918 service policy to decide how it populates the value of "nam" key, 919 which MAY also derive from other fields in the request, from customer 920 profile data, or from access to external services. If the 921 authentication service generates a "rcd" claim containing "nam" with 922 a value that is not equivalent to the From header field display-name 923 value, it MUST use the full form of the PASSporT object in SIP. 925 14.2. Verification Service Behavior 927 [RFC8224] Section 6.2 Step 5 requires that specifications defining 928 "ppt" values describe any additional verifier behavior. The behavior 929 specified for the "ppt" values of "rcd" is as follows. If the 930 PASSporT is in compact form, then the verification service SHOULD 931 extract the display-name from the From header field value, if any, 932 and use that as the value for the "nam" key when it recomputes the 933 header and claims of the PASSporT object. Optionally, if there 934 exists a Call-Info header field as defined in 935 [I-D.ietf-sipcore-callinfo-rcd], the "jcard" value can be derived to 936 determine the "jcd" key when it recomputes the header and claims of 937 the PASSporT object. If the signature validates over the recomputed 938 object, then the verification should be considered successful. 940 However, if the PASSport is in full form with a "ppt" value of "rcd", 941 then the verification service MUST extract the value associated with 942 the "rcd" "nam" key in the object. If the signature validates, then 943 the verification service can use the value of the "rcd" "nam" key as 944 the display name of calling party, which would in turn be rendered to 945 alerted users or otherwise leveraged in accordance with local policy. 946 This allows SIP networks that convey the display name through a field 947 other than the From header field to interoperate with this 948 specification. Similarly, the "jcd" or linked "jcl" jcard 949 information and "crn" can be optionally, based on local policy for 950 devices that support it, used to populate a Call-Info header field 951 following the format of [I-D.ietf-sipcore-callinfo-rcd]. 953 The third-party "rcd" PASSporT cases presents some new challenges, as 954 an attacker could attempt to cut-and-paste such a third-party 955 PASSporT into a SIP request in an effort to get the terminating user 956 agent to render the display name or confidence values it contains to 957 a call that should have no such assurance. A third-party "rcd" 958 PASSporT provides no assurance that the calling party number has not 959 been spoofed: if it is carried in a SIP request, for example, then 960 some other PASSporT in another Identity header field value would have 961 to carry a PASSporT attesting that. A verification service MUST 962 determine that the calling party number shown in the "orig" of the 963 "rcd" PASSporT corresponds to the calling party number of the call it 964 has received, and that the "iat" field of the "rcd" PASSporT is 965 within the date interval that the verification service would 966 ordinarily accept for a PASSporT. 968 Verification services may alter their authorization policies for the 969 credentials accepted to sign PASSporTs when third parties generate 970 PASSporT objects, per Section 12.1. This may include accepting a 971 valid signature over a PASSporT even if it is signed with a 972 credential that does not attest authority over the identity in the 973 "orig" claim of the PASSporT, provided that the verification service 974 has some other reason to trust the signer. No further guidance on 975 verification service authorization policy is given here. 977 The behavior of a SIP UAS upon receiving an INVITE containing a 978 PASSporT object with a "rcd" claim largely remains a matter of 979 implementation policy. In most cases, implementations would render 980 this calling party name information to the user while alerting. Any 981 user interface additions to express confidence in the veracity of 982 this information are outside the scope of this specification. 984 15. Using "rcd" as additional claims to other PASSporT extensions 986 Rich Call Data, including calling name information, for example, is 987 often data that is additive data to the personal communications 988 information defined in the core PASSporT data required to support the 989 security properties defined in [RFC8225]. For cases where the entity 990 that is originating the personal communications and additionally is 991 supporting the authentication service and also is the authority of 992 the Rich Call Data, rather than creating multiple identity headers 993 with multiple PASSporT extensions or defining multiple combinations 994 and permutations of PASSporT extension definitions, the 995 authentication service can alternatively directly add the "rcd" 996 claims to the PASSporT it is creating, whether it is constructed with 997 a PASSporT extension or not. 999 Note: There is one very important caveat to this capability, because 1000 generally if there is URI referenced content in an "rcd" PASSporT 1001 there is often the requirement to use "rcdi" and JWT Claims 1002 Constraints. So, it is important for the user of this specification 1003 to recognize that the certificates used must include the necessary 1004 JWT Claims Constraints for proper integrity and security of the 1005 values in the "rcd" claim incorporated into PASSporTs that are not 1006 "rcd". 1008 15.1. Procedures for applying "rcd" as claims only 1010 For a given PASSporT using some other extension than "rcd", the 1011 Authentication Service MAY additionally include the "rcd" claim as 1012 defined in this document. This would result in a set of claims that 1013 correspond to the original intended extension with the addition of 1014 the "rcd" claim. 1016 The Verification service that receives the PASSporT, if it supports 1017 this specification and chooses to, should interpret the "rcd" claim 1018 as simply just an additional claim intended to deliver and/or 1019 validate delivered Rich Call Data. 1021 15.2. Example for applying "rcd" as claims only 1023 In the case of [RFC8588] which is the PASSporT extension supporting 1024 the SHAKEN specification [ATIS-1000074], a common case for an 1025 Authentication service to co-exist in a CSP network along with the 1026 authority over the calling name used for the call. Rather than 1027 require two identity headers, the CSP Authentication Service can 1028 apply both the SHAKEN PASSporT claims and extension and simply add 1029 the "rcd" required claims defined in this document. 1031 For example, the PASSporT claims for the "shaken" PASSporT with "rcd" 1032 claims would be as follows: 1034 Protected Header 1035 { 1036 "alg":"ES256", 1037 "typ":"passport", 1038 "ppt":"shaken", 1039 "x5u":"https://cert.example.org/passport.cer" 1040 } 1041 Payload 1042 { 1043 "attest":"A", 1044 "dest":{"tn":["12025551001"]}, 1045 "iat":1443208345, 1046 "orig":{"tn":"12025551000"}, 1047 "origid":"123e4567-e89b-12d3-a456-426655440000", 1048 "rcd":{"nam":"James Bond"} 1049 } 1051 A Verification Service that supports "rcd" and "shaken" PASSporT 1052 extensions is able to receive the above PASSporT and interpret both 1053 the "shaken" claims as well as the "rcd" defined claim. 1055 If the Verification Service only understands the "shaken" extension 1056 claims but doesn't support "rcd", the "rcd" is ignored and 1057 disregarded. 1059 16. Acknowledgements 1061 We would like to thank David Hancock, Robert Sparks, Russ Housley, 1062 Eric Burger, Alec Fenichel, and Ben Campbell for helpful suggestions, 1063 review, and comments. 1065 17. IANA Considerations 1067 17.1. JSON Web Token Claim 1069 This specification requests that the IANA add three new claims to the 1070 JSON Web Token Claims registry as defined in [RFC7519]. 1072 Claim Name: "rcd" 1074 Claim Description: Rich Call Data Information 1076 Change Controller: IESG 1078 Specification Document(s): [RFCThis] 1080 Claim Name: "rcdi" 1082 Claim Description: Rich Call Data Integrity Information 1084 Change Controller: IESG 1086 Specification Document(s): [RFCThis] 1088 Claim Name: "crn" 1090 Claim Description: Call Reason 1092 Change Controller: IESG 1094 Specification Document(s): [RFCThis] 1096 17.2. PASSporT Types 1098 This specification requests that the IANA add a new entry to the 1099 PASSporT Types registry for the type "rcd" which is specified in 1100 [RFCThis]. 1102 17.3. PASSporT RCD Types 1104 This document requests that the IANA create a new registry for 1105 PASSporT RCD types. Registration of new PASSporT RCD types shall be 1106 under the Specification Required policy. 1108 This registry is to be initially populated with three values, "nam", 1109 "jcd", and "jcl", which are specified in [RFCThis]. 1111 18. Security Considerations 1113 Revealing information such as the name, location, and affiliation of 1114 a person necessarily entails certain privacy risks. Baseline 1115 PASSporT has no particular confidentiality requirement, as the 1116 information it signs over in a using protocol like SIP is all 1117 information that SIP carries in the clear anyway. Transport-level 1118 security can hide those SIP fields from eavesdroppers, and the same 1119 confidentiality mechanisms would protect any PASSporT(s) carried in 1120 SIP. 1122 Since computation of "rcdi" digests for URIs requires the loading of 1123 referenced content, it would be best practice to validate that 1124 content at the creation of the "rcdi" or corresponding JWT claim 1125 constraint value by checking for content that may cause issues for 1126 verification services or that doesn't follow the behavior defined in 1127 this document, e.g. unreasonably sized data, the inclusion of 1128 recursive URI references, etc. 1130 18.1. The use of JWT Claim Constraints in delegate certificates to 1131 exclude unauthorized claims 1133 While this can apply to any PASSporT that is signed with a STIR 1134 Delegate Certificates [I-D.ietf-stir-cert-delegation], it is 1135 important to note that when constraining PASSporTs to include 1136 specific claims or contents of claims, it is also important to 1137 consider potential attacks by non-authorized signers that may include 1138 other potential PASSporT claims that weren't originally vetted by the 1139 authorized entity providing the delegate certificate. The use of JWT 1140 claims constraints as defined in [I-D.housley-stir-enhance-rfc8226] 1141 for preventing the ability to include claims beyond the claims 1142 defined in this document may need to be considered. 1143 [I-D.housley-stir-enhance-rfc8226] in the security considerations 1144 also notes that the use of mustExclude for the "rcdi" when "rcd" is 1145 used is discouraged, otherwise it would prevent the proper integrity 1146 protection mechanism to be used. 1148 19. References 1150 19.1. Normative References 1152 [I-D.housley-stir-enhance-rfc8226] 1153 Housley, R., "Enhanced JWT Claim Constraints for STIR 1154 Certificates", draft-housley-stir-enhance-rfc8226-00 (work 1155 in progress), January 2021. 1157 [I-D.ietf-sipcore-callinfo-rcd] 1158 Wendt, C. and J. Peterson, "SIP Call-Info Parameters for 1159 Rich Call Data", draft-ietf-sipcore-callinfo-rcd-02 (work 1160 in progress), February 2021. 1162 [I-D.ietf-stir-cert-delegation] 1163 Peterson, J., "STIR Certificate Delegation", draft-ietf- 1164 stir-cert-delegation-04 (work in progress), February 2021. 1166 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1167 A., Peterson, J., Sparks, R., Handley, M., and E. 1168 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1169 DOI 10.17487/RFC3261, June 2002, 1170 . 1172 [RFC4627] Crockford, D., "The application/json Media Type for 1173 JavaScript Object Notation (JSON)", RFC 4627, 1174 DOI 10.17487/RFC4627, July 2006, 1175 . 1177 [RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., 1178 "JavaScript Object Notation (JSON) Pointer", RFC 6901, 1179 DOI 10.17487/RFC6901, April 2013, 1180 . 1182 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 1183 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 1184 DOI 10.17487/RFC6919, April 2013, 1185 . 1187 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, 1188 DOI 10.17487/RFC7095, January 2014, 1189 . 1191 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 1192 Telephone Identity Problem Statement and Requirements", 1193 RFC 7340, DOI 10.17487/RFC7340, September 2014, 1194 . 1196 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1197 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1198 . 1200 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 1201 "Authenticated Identity Management in the Session 1202 Initiation Protocol (SIP)", RFC 8224, 1203 DOI 10.17487/RFC8224, February 2018, 1204 . 1206 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 1207 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 1208 . 1210 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 1211 Credentials: Certificates", RFC 8226, 1212 DOI 10.17487/RFC8226, February 2018, 1213 . 1215 [RFC8588] Wendt, C. and M. Barnes, "Personal Assertion Token 1216 (PaSSporT) Extension for Signature-based Handling of 1217 Asserted information using toKENs (SHAKEN)", RFC 8588, 1218 DOI 10.17487/RFC8588, May 2019, 1219 . 1221 19.2. Informative References 1223 [ATIS-1000074] 1224 ATIS/SIP Forum NNI Task Group, "Signature-based Handling 1225 of Asserted information using toKENs (SHAKEN) 1226 ", January 2017. 1229 [I-D.ietf-stir-oob] 1230 Rescorla, E. and J. Peterson, "Secure Telephone Identity 1231 Revisited (STIR) Out-of-Band Architecture and Use Cases", 1232 draft-ietf-stir-oob-07 (work in progress), March 2020. 1234 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1235 Requirement Levels", BCP 14, RFC 2119, 1236 DOI 10.17487/RFC2119, March 1997, 1237 . 1239 Authors' Addresses 1241 Chris Wendt 1242 Comcast 1243 Comcast Technology Center 1244 Philadelphia, PA 19103 1245 USA 1247 Email: chris-ietf@chriswendt.net 1248 Jon Peterson 1249 Neustar Inc. 1250 1800 Sutter St Suite 570 1251 Concord, CA 94520 1252 US 1254 Email: jon.peterson@neustar.biz