idnits 2.17.1 draft-ietf-stir-passport-rcd-11.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 (March 29, 2021) is 1116 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 1100, but not defined -- Possible downref: Normative reference to a draft: ref. 'I-D.housley-stir-enhance-rfc8226' == Outdated reference: A later version (-10) exists of draft-ietf-sipcore-callinfo-rcd-01 == Outdated reference: A later version (-04) exists of draft-ietf-stir-cert-delegation-03 ** 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 Summary: 3 errors (**), 0 flaws (~~), 6 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: September 30, 2021 Neustar Inc. 6 March 29, 2021 8 PASSporT Extension for Rich Call Data 9 draft-ietf-stir-passport-rcd-11 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 users. This framework is intended to extend 18 caller and call specific information beyond human-readable display 19 name comparable to the "Caller ID" function common on the telephone 20 network. The JSON element defined for this purpose, Rich Call Data 21 (RCD), is an extensible object defined to either be used as part of 22 STIR or with SIP Call-Info to include related information about calls 23 that helps people decide whether to pick up the phone. This signing 24 of the RCD information is also enhanced with a integrity mechanism 25 that is designed to protect the authoring and transport of this 26 information between authoritative and non-authoritative parties 27 generating and signing the Rich Call Data for support of different 28 usage and content policies. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 30, 2021. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 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 extension 4 67 4. Overview of Rich Call Data Integrity . . . . . . . . . . . . 5 68 5. PASSporT Claim "rcd" Defintion and Usage . . . . . . . . . . 6 69 5.1. PASSporT "rcd" Claim . . . . . . . . . . . . . . . . . . 6 70 5.1.1. "nam" key . . . . . . . . . . . . . . . . . . . . . . 7 71 5.1.2. "jcd" key . . . . . . . . . . . . . . . . . . . . . . 7 72 5.1.3. "jcl" key . . . . . . . . . . . . . . . . . . . . . . 7 73 6. "rcdi" RCD Integrity Claim Definition and Usage . . . . . . . 8 74 6.1. Creation of the "rcd" element digests . . . . . . . . . . 9 75 6.2. JWT Claim Constraint for "rcd" claims only . . . . . . . 12 76 7. JWT Claim Constraint usage for "rcd" and "rcdi" claims . . . 12 77 8. PASSporT "crn" claim - Call Reason Defintion and Usage . . . 13 78 8.1. JWT Constraint for "crn" claim . . . . . . . . . . . . . 13 79 9. Rich Call Data Claims Usage Rules . . . . . . . . . . . . . . 13 80 9.1. Example "rcd" PASSporTs . . . . . . . . . . . . . . . . . 14 81 10. Compact form of "rcd" PASSporT . . . . . . . . . . . . . . . 16 82 10.1. Compact form of the "rcd" PASSporT claim . . . . . . . . 16 83 10.2. Compact form of the "rcdi" PASSporT claim . . . . . . . 16 84 10.3. Compact form of the "crn" PASSporT claim . . . . . . . . 16 85 11. Further Information Associated with Callers . . . . . . . . . 16 86 12. Third-Party Uses . . . . . . . . . . . . . . . . . . . . . . 17 87 12.1. Signing as a Third Party . . . . . . . . . . . . . . . . 19 88 13. Levels of Assurance . . . . . . . . . . . . . . . . . . . . . 19 89 14. Using "rcd" in SIP . . . . . . . . . . . . . . . . . . . . . 20 90 14.1. Authentication Service Behavior . . . . . . . . . . . . 20 91 14.2. Verification Service Behavior . . . . . . . . . . . . . 20 92 15. Using "rcd" as additional claims to other PASSporT extensions 22 93 15.1. Procedures for applying "rcd" as claims only . . . . . . 22 94 15.2. Example for applying "rcd" as claims only . . . . . . . 22 96 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 97 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 98 17.1. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 23 99 17.2. PASSporT Types . . . . . . . . . . . . . . . . . . . . . 24 100 17.3. PASSporT RCD Types . . . . . . . . . . . . . . . . . . . 24 101 18. Security Considerations . . . . . . . . . . . . . . . . . . . 24 102 18.1. The use of JWT Claim Constraints in delegate 103 certificates to exclude unauthorized Claims . . . . . . 25 104 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 105 19.1. Normative References . . . . . . . . . . . . . . . . . . 25 106 19.2. Informative References . . . . . . . . . . . . . . . . . 27 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 109 1. Introduction 111 PASSporT [RFC8225] is a token format based on JWT [RFC7519] for 112 conveying cryptographically-signed information about the parties 113 involved in personal communications; it is used to convey a signed 114 assertion of the identity of the participants in real-time 115 communications established via a protocol like SIP [RFC8224]. The 116 STIR problem statement [RFC7340] declared securing the display name 117 of callers outside of STIR's initial scope, so baseline STIR provides 118 no features for caller name. This specification documents an 119 optional mechanism for PASSporT and the associated STIR procedures 120 which extend PASSporT objects to protect additional elements 121 conveying richer information: information that is intended to be 122 rendered to an end user to assist a called party in determining 123 whether to accept or trust incoming communications. This includes 124 the name of the person on one side of a communications session, the 125 traditional "Caller ID" of the telephone network, along with related 126 display information that would be rendered to the called party during 127 alerting, or potentially used by an automaton to determine whether 128 and how to alert a called party. 130 Traditional telephone network signaling protocols have long supported 131 delivering a 'calling name' from the originating side, though in 132 practice, the terminating side is often left to derive a name from 133 the calling party number by consulting a local address book or an 134 external database. SIP similarly can carry this information in a 135 'display-name' in the From header field value from the originating to 136 terminating side, or alternatively in the Call-Info header field. 137 However, both are unsecured fields that really cannot be trusted in 138 most interconnected SIP deployments, and therefore is a good starting 139 point for a framework that utilizes STIR techniques and procedures 140 for protecting call related information including but not limited to 141 calling name. 143 As such, the baseline use-case for this document extends PASSporT to 144 provide cryptographic protection for the "display-name" field of SIP 145 requests as well as further "rich call data" (RCD) about the caller, 146 which includes the contents of the Call-Info header field or other 147 data structures that can be added to the PASSporT. This document 148 furthermore specifies a third-party profile that would allow external 149 authorities to convey rich information associated with a calling 150 number via a new type of PASSporT. Finally, this document describes 151 how to preserve the integrity of the RCD in scenarios where there may 152 be non-authoritative users initiating and signing RCD and therefore a 153 constraint on the RCD data that a PASSporT can attest via 154 certificate-level controls. 156 2. Terminology 158 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 159 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 160 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 161 described in [RFC2119] and [RFC6919]. 163 3. Overview of the use of the Rich Call Data PASSporT extension 165 The main intended use of the signing of Rich Call Data (RCD) using 166 STIR [RFC8224] and as a PASSporT extension [RFC8225] is for the 167 entity that originates a call, either directly the caller themselves, 168 if they are authoritative, or a service provider or third-party 169 service that may be authoritative over the rich call data on behalf 170 of the caller. 172 The RCD described in this document is of two main categories. The 173 first data is a more traditional set of info about a caller 174 associated with "display-name" in SIP [RFC3261], typically a textual 175 description of the caller. The second category is a set of RCD that 176 is defined as part of the jCard definitions or extensions to that 177 data. [I-D.ietf-sipcore-callinfo-rcd] describes the optional use of 178 jCard in Call-Info header field as RCD with the "jcard" Call-Info 179 purpose token. Either or both of these two types of data can be 180 incorporated into a "rcd" claim defined in this document. 182 Additionally, [I-D.ietf-sipcore-callinfo-rcd] also describes a "call- 183 reason" parameter intended for description of the intent or reason 184 for a particular call. A new PASSporT claim "crn", or call reason, 185 can contain the string or object that describes the intent of the 186 call. This claim is intentionally kept separate from the "rcd" claim 187 because it is envisioned that call reason is not the same as 188 information associated with the caller and may change on a more 189 frequent, per call, type of basis. 191 4. Overview of Rich Call Data Integrity 193 When incorporating call data that represents a user, even in 194 traditional calling name services today, often there is policy and 195 restrictions around what data is allowed to be used. Whether 196 preventing offensive language or icons or enforcing uniqueness, 197 potential trademark violations or other policy enforcement, there 198 should be the desire to pre-certify or "vet" the specific use of rich 199 call data. This document defines a mechanism that allows for a 200 direct or indirect party that controls the policy to approve or 201 certify the content, create a cryptographic digest that can be used 202 to validate that data and applies a constraint in the certificate to 203 allow the recipient and verifier to validate that the specific 204 content of the RCD is as intended at its creation and approval or 205 certification. 207 There are two mechanisms that are defined to accomplish that for two 208 distinct categories of purposes. The first of the mechanisms include 209 the definition of an integrity claim. The RCD integrity mechanism is 210 a process of generating a sufficiently strong cryptographic digest 211 for both the "rcd" claim contents (e.g. "nam", "jcd", "jcl") defined 212 below and the resources defined by one or more globally unique HTTPS 213 URLs referenced by the contents (e.g. an image file referenced by 214 "jcd" or a jCard referenced by "jcl"). This mechanism is inspired by 215 and based on the W3C Subresource Integrity specification 216 (http://www.w3.org/TR/SRI/). The second of the mechanisms uses the 217 capability called JWT Claim Constraints, defined in [RFC8226] and 218 extended in [I-D.housley-stir-enhance-rfc8226]. The JWT Claim 219 Constraints specifically guide the verifier within the certificate 220 used to sign the PASSporT for the inclusion (or exclusion) of 221 specific claims and their values, so that the content intended by the 222 signer can be verified to be accurate. 224 Both of these mechanisms, integrity digests and JWT Claims 225 Constraints, can be used together or separately depending on the 226 intended purpose. The first category of purpose is whether the rich 227 call data conveyed by the RCD passport is pass-by-value or passed-by- 228 reference; i.e., is the information contained in the passport claims 229 and therefor integrity protected by the passport signature, or is the 230 information contained in an external resource referenced by a URI in 231 the RCD PASSporT. The second category of purpose is whether the 232 signer is authoritative or has responsibility for the accuracy of the 233 RCD based on the policies of the eco-system the RCD PASSporTs are 234 being used. 236 The following table provides an overview of the framework for how 237 integrity should be used with RCD. (Auth represents authoritative in 238 this table) 239 +----------+---------------------+--------------------------------+ 240 | Modes | No external URIs | Includes URI refs | 241 +----------+---------------------+--------------------------------+ 242 | Auth | 1: No integrity req | 2: RDC Integrity | 243 +----------+---------------------+--------------------------------+ 244 | Non-Auth | 3: JWT Claim Const. | 4: RCD Integ./JWT Claim Const. | 245 +----------+---------------------+--------------------------------+ 247 The first and simplest mode is exclusively for when all RCD content 248 is directly included as part of the claims (i.e. no external 249 reference URIs are included in the content, for example, "photo" or 250 "logo" properties that aren't directly encoded into the JSON of the 251 jCard) and when the signer is authoritative over the content. In 252 this mode, integrity protection is not required and the set of claims 253 is simply protected by the signature of the standard PASSporT 254 [RFC8225] and SIP identity header [RFC8224] procedures. The second 255 mode is an extension of the first where the signer is authoritative 256 and a "rcd" claim contents include a URI identifying external 257 resources. In this mode, an RCD Integrity or "rcdi" claim MUST be 258 included. This integrity claim is defined later in this document and 259 provides a digest of the "rcd" claim content so that, particularly 260 for the case where there are URI references in the RCD, the content 261 of that RCD can be comprehensively validated that it was received as 262 intended by the signer of the 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 part of the overall "rcd" claim JSON 460 object. The following example illustrates a "jcl" version of the 461 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 constraint on inclusion of the 526 "rcd" claim as well as the contents of that claim. 528 The certificate JWT Claims Constraint MUST include the following: 530 o a "mustInclude" for the "rcd" claim and a "permittedValues" equal 531 to the created "rcd" claim value string. 533 The "permitedValues" for the "rcd" claim may contain multiple 534 entries, to support the case where the certificate holder is 535 authorized to use different sets of rich call data. 537 7. JWT Claim Constraint usage for "rcd" and "rcdi" claims 539 The integrity overview section of this document describes a fourth 540 mode where both "rcdi" and JWT Claim Constraints is used. The use of 541 this mode implies the signing of an "rcdi" claim is required to be 542 protected by the authoritative certificate creator using JWT Claims 543 Constraints in the certificate. The intension of the use of both of 544 these mechanisms is to constrain the signer to construct the "rcd" 545 and "rcdi" claims with the "rcd" jCard object including reference 546 external content via URI. Once both the contents of the "rcd" claim 547 and any linked content is certified by the party that is 548 authoritative for the certificate being created and the construction 549 of the "rcdi" claim is complete, the "rcdi" claim is linked to the 550 STIR certificate associated with the signature in the PASSporT via 551 JWT Claim Constraints as defined in [RFC8226] Section 8. It should 552 be recognized that the "rcdi" set of digests is intended to be unique 553 for only a specific combination of "rcd" content and URI referenced 554 external content, and therefore provides the integrity mechanism for 555 an authentication service being performed by a non-authoritative 556 party. 558 The certificate JWT Claims Constraint MUST include both of the 559 following: 561 o a "mustInclude" for the "rcd" claim, which simply constrains the 562 fact that an "rcd" should be included if there is a "rcdi" 564 o a "mustInclude" for the "rcdi" claim and a "permittedValues" equal 565 to the created "rcdi" claim value string. 567 The "permitedValues" for the "rcdi" claim may contain multiple 568 entries, to support the case where the certificate holder is 569 authorized to use different sets of rich call data. 571 8. PASSporT "crn" claim - Call Reason Defintion and Usage 573 This specification defines a new JSON Web Token claim for "crn", Call 574 Reason, the value of which is a single string or object that can 575 contains information as defined in [I-D.ietf-sipcore-callinfo-rcd] 576 corresponding to the "reason" parameter for the Call-Info header. 577 This claim is optional. 579 Example "crn" claim with "rcd": 580 "rcd": { "nam": "James Bond", 581 "jcl": "https://example.org/james_bond.json"}, 582 "crn" : "For your ears only" 584 8.1. JWT Constraint for "crn" claim 586 The integrity of the "crn" claim can optionally be protected by the 587 authoritative certificate creator using JWT Constraints in the 588 certificate. If this protection is used, a "mustInclude" for the 589 "crn" claim and a "permittedValues" equal to the "crn" claim value 590 string SHOULD be included. 592 9. Rich Call Data Claims Usage Rules 594 Either or both the "rcd" or "crn" claims may appear in any PASSporT 595 claims object as optional elements. The creator of a PASSporT MAY 596 also add a "ppt" value of "rcd" to the header of a PASSporT as well, 597 in which case the PASSporT claims MUST contain either a "rcd" or 598 "crn" claim, and any entities verifying the PASSporT object are 599 required to understand the "ppt" extension in order to process the 600 PASSporT in question. An example PASSporT header with the "ppt" 601 included is shown as follows: 603 { "typ":"passport", 604 "ppt":"rcd", 605 "alg":"ES256", 606 "x5u":"https://www.example.com/cert.cer" } 608 The PASSporT claims object contains the "rcd" key with its 609 corresponding value. The value of "rcd" is an array of JSON objects, 610 of which one, the "nam" object, is mandatory. The key syntax of 611 "nam" follows the display-name ABNF given in [RFC3261]. 613 After the header and claims PASSporT objects have been constructed, 614 their signature is generated normally per the guidance in [RFC8225]. 616 9.1. Example "rcd" PASSporTs 618 An example of a "nam" only PASSporT claims object is shown next (with 619 line breaks for readability only). 621 { "orig":{"tn":"12025551000"}, 622 "dest":{"tn":["12025551001"]}, 623 "iat":1443208345, 624 "rcd":{"nam":"James Bond"} } 626 An example of a "nam" only PASSporT claims object with an "rcdi" 627 claim is shown next (with line breaks for readability only). 629 { "orig":{"tn":"12025551000"}, 630 "dest":{"tn":["12025551001"]}, 631 "iat":1443208345, 632 "rcd":{"nam":"James Bond"}, 633 "rcdi":{"/nam": "sha256-918VNJD12938SNCJ"} 634 } 636 An example of a "rcd" claims object that includes the "jcd" and also 637 contains a URI which requires the inclusion of an "rcdi" claim. 639 { 640 "orig": { "tn": "12025551000"}, 641 "dest": { "tn": ["12155551001"]}, 642 "iat": 1443208345, 643 "rcd": { 644 "nam": "Q Branch Spy Gadgets", 645 "jcd": ["vcard", 646 [ ["version",{},"text","4.0"], 647 ["fn",{},"text","Q Branch"], 648 ["org",{},"text","MI6;Q Branch Spy Gadgets"], 649 ["photo",{},"uri","https://example.com/photos/q-256x256.png"], 650 ["logo",{},"uri","https://example.com/logos/mi6-256x256.jpg"], 651 ["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg"] 652 ] ] 653 }, 654 "crn": "Rendezvous for Little Nellie", 655 "rcdi": { 656 "/nam": "sha256-918VNJD12938SNCJ", 657 "/jcd": "sha256-VNJDSNCJ12938918", 658 "/jcd/1/3/3": "sha256-12938918VNJDSNCJ", 659 "/jcd/1/4/3": "sha256-VNJDSNCJ12938918", 660 "/jcd/1/5/3": "sha256-4049852730SFLGHL" 661 } 662 } 664 In an example PASSporT, where a jCard is linked via HTTPS URL using 665 "jcl", a jCard file served at a particular URL. 667 An example jCard JSON file is shown as follows: 669 https://example.com/qbranch.json: 670 ["vcard", 671 [ ["version",{},"text","4.0"], 672 ["fn",{},"text","Q Branch"], 673 ["org",{},"text","MI6;Q Branch Spy Gadgets"], 674 ["photo",{},"uri","https://example.com/photos/q-256x256.png"], 675 ["logo",{},"uri","https://example.com/logos/mi6-256x256.jpg"], 676 ["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg"] 677 ] 678 ] 680 If that jCard is hosted at the example address of 681 "https://example.com/qbranch.json", the corresponding PASSporT claims 682 object would be as follows: 684 { 685 "orig": {"tn": "12025551000"}, 686 "dest": {"tn": ["12155551001"]}, 687 "iat": 1443208345, 688 "rcd": { 689 "nam": "Q Branch Spy Gadgets", 690 "jcl": "https://example.com/qbranch.json" 691 }, 692 "crn": "Rendezvous for Little Nellie", 693 "rcdi": { 694 "/nam": "sha256-918VNJD12938SNCJ", 695 "/jcl": "sha256-VNJDSNCJ12938918", 696 "/jcl/1/3/3": "sha256-12938918VNJDSNCJ", 697 "/jcl/1/4/3": "sha256-VNJDSNCJ12938918", 698 "/jcl/1/5/3": "sha256-4049852730SFLGHL" 699 } 700 } 702 10. Compact form of "rcd" PASSporT 704 10.1. Compact form of the "rcd" PASSporT claim 706 Compact form of an "rcd" PASSporT claim has some restrictions but 707 mainly follows standard PASSporT compact form procedures. For re- 708 construction of the "nam" claim the string for the display-name in 709 the From header field. For re-construction of the "jcl", the Call- 710 Info header as with purpose "jcard" defined in 711 [I-D.ietf-sipcore-callinfo-rcd] MUST be used. "jcd" claim MAY NOT be 712 used as part of compact form. 714 10.2. Compact form of the "rcdi" PASSporT claim 716 Compact form of an "rcdi" PASSPorT claim is not supported, so if 717 "rcdi" is required compact form should not be used. 719 10.3. Compact form of the "crn" PASSporT claim 721 Compact form of a "crn" PASSporT claim shall be re-constructed using 722 the "call-reason" parameter of a Call-Info header as defined by 723 [I-D.ietf-sipcore-callinfo-rcd]. 725 11. Further Information Associated with Callers 727 Beyond naming information and the information that can be contained 728 in a jCard [RFC7095] object, there may be additional human-readable 729 information about the calling party that should be rendered to the 730 end user in order to help the called party decide whether or not to 731 pick up the phone. This is not limited to information about the 732 caller, but includes information about the call itself, which may 733 derive from analytics that determine based on call patterns or 734 similar data if the call is likely to be one the called party wants 735 to receive. Such data could include: 737 o information related to the location of the caller, or 739 o any organizations or institutions that the caller is associated 740 with, or even categories of institutions (is this a government 741 agency, or a bank, or what have you), or 743 o hyperlinks to images, such as logos or pictures of faces, or to 744 similar external profile information, or 746 o information processed by an application before rendering it to a 747 user, like social networking data that shows that an unknown 748 caller is a friend-of-a-friend, or reputation scores derived from 749 crowdsourcing, or confidence scores based on broader analytics 750 about the caller and callee. 752 All of these data elements would benefit from the secure attestations 753 provided by the STIR and PASSporT frameworks. A new IANA registry 754 has been defined to hold potential values of the "rcd" array; see 755 Section 17.3. Specific extensions to the "rcd" PASSporT claim are 756 left for future specification. 758 There is a few ways RCD can be extended in the future, jCard is an 759 extensible object and the key/values in the RCD claim object can also 760 be extended. General guidance for future extensibility that were 761 followed by the authors is that jCard generally should refer to data 762 that references the caller as an individual or entity, where other 763 claims, such as "crn" refer to data regarding the specific call. 764 There may be other considerations discovered in the future, but this 765 logical grouping of data to the extent possible should be followed 766 for future extensibility. 768 12. Third-Party Uses 770 While rich data about the call can be provided by an originating 771 authentication service, an intermediary in the call path could also 772 acquire rich call data by querying a third-party service. Such a 773 service effectively acts as a STIR Authentication Service, generating 774 its own PASSporT, and that PASSporT could be attached to a SIP call 775 by either the originating or terminating side. This third-party 776 PASSporT attests information about the calling number, rather than 777 the call or caller itself, and as such its RCD MUST NOT be used when 778 a call lacks a first-party PASSporT that assures verification 779 services that the calling party number is not spoofed. It is 780 intended to be used in cases when the originating side does not 781 supply a display-name for the caller, so instead some entity in the 782 call path invokes a third-party service to provide rich caller data 783 for a call. 785 In telephone operations today, a third-party information service is 786 commonly queried with the calling party's number in order to learn 787 the name of the calling party, and potentially other helpful 788 information could also be passed over that interface. The value of 789 using a PASSporT to convey this information from third parties lies 790 largely in the preservation of the third party's signature over the 791 data, and the potential for the PASSporT to be conveyed from 792 intermediaries to endpoint devices. Effectively, these use cases 793 form a sub-case of out-of-band [I-D.ietf-stir-oob] use cases. The 794 manner in which third-party services are discovered is outside the 795 scope of this document. 797 An intermediary use case might look as follows: a SIP INVITE carries 798 a display name in its From header field value and an initial PASSporT 799 object without the "rcd" claim. When a terminating verification 800 service implemented at a SIP proxy server receives this request, and 801 determines that the signature is valid, it might query a third-party 802 service that maps telephone numbers to calling party names. Upon 803 receiving the PASSport in a response from that third-party service, 804 the terminating side could add a new Identity header field to the 805 request for the "rcd" PASSporT object provided by the third-party 806 service. It would then forward the INVITE to the terminating user 807 agent. If the display name in the "rcd" PASSporT object matches the 808 display name in the INVITE, then the name would presumably be 809 rendered to the end user by the terminating user agent. 811 A very similar flow could be followed by an intermediary closer to 812 the origination of the call. Presumably such a service could be 813 implemented at an originating network in order to decouple the 814 systems that sign for calling party numbers from the systems that 815 provide rich data about calls. 817 In an alternative use case, the terminating user agent might query a 818 third-party service. In this case, no new Identity header field 819 would be generated, though the terminating user agent might receive a 820 PASSporT object in return from the third-party service, and use the 821 "rcd" field in the object as a calling name to render to users while 822 alerting. 824 While in the traditional telephone network, the business relationship 825 between calling customers and their telephone service providers is 826 the ultimate root of information about a calling party's name, some 827 other forms of data like crowdsourced reputation scores might derive 828 from third parties. When those elements are present, they MUST be in 829 a third-party "rcd" PASSporT using "iss" claim described in the next 830 section. 832 12.1. Signing as a Third Party 834 A third-party PASSporT contains an "iss" element to distinguish its 835 PASSporTs from first-party PASSporTs. Third-party "rcd" PASSporTs 836 are signed with credentials that do not have authority over the 837 identity that appears in the "orig" element of the PASSporT claims. 838 The presence of "iss" signifies that a different category of 839 credential is being used to sign a PASSporT than the [RFC8226] 840 certificates used to sign STIR calls; it is instead a certificate 841 that identifies the source of the "rcd" data. How those credentials 842 are issued and managed is outside the scope of this specification; 843 the value of "iss" however MUST reflect the Subject Name field of the 844 certificate used to sign a third-party PASSporT. Relying parties in 845 STIR have always been left to make their own authorization decisions 846 about whether to trust the signers of PASSporTs, and in the third- 847 party case, where an entity has explicitly queried a service to 848 acquire the PASSporT object, it may be some external trust or 849 business relationship that induces the relying party to trust a 850 PASSporT. 852 An example of a Third Party issued PASSporT claims object is as 853 follows. 855 { "orig":{"tn":"12025551000"}, 856 "dest":{"tn":["12025551001"]}, 857 "iat":1443208345, 858 "iss":"Zorin Industries", 859 "rcd":{"nam":"James St. John Smythe"} } 861 13. Levels of Assurance 863 As "rcd" can be provided by either first or third parties, relying 864 parties could benefit from an additional claim that indicates the 865 relationship of the attesting party to the caller. Even in first 866 party cases, this admits of some complexity: the Communications 867 Service Provider (CSP) to which a number was assigned might in turn 868 delegate the number to a reseller, who would then sell the number to 869 an enterprise, in which case the CSP might have little insight into 870 the caller's name. In third party cases, a caller's name could 871 derive from any number of data sources, on a spectrum between public 872 data scraped from web searches to a direct business relationship to 873 the caller. As multiple PASSporTs can be associated with the same 874 call, potentially a verification service could receive attestations 875 of the caller name from multiple sources, which have different levels 876 of granularity or accuracy. Therefore, PASSporTs that carry "rcd" 877 data MUST also carry an indication of the relationship of the 878 generator of the PASSporT to the caller in the form of the "iss" 879 claim. As stated in the previous section, the use of "iss" MUST 880 reflect the Subject Name of the certificate used to sign a third- 881 party PASSporT to represent that relationship. 883 14. Using "rcd" in SIP 885 This section specifies SIP-specific usage for the "rcd" claim in 886 PASSporT, and in the SIP Identity header field value. Other using 887 protocols of PASSporT may define their own usages for the "rcd" 888 claim. 890 14.1. Authentication Service Behavior 892 An authentication service creating a PASSporT containing a "rcd" 893 claim MAY include a "ppt" for "rcd" or not. Third-party 894 authentication services following the behavior in Section 12.1 MUST 895 include a "ppt" of "rcd". If "ppt" does contain a "rcd", then any 896 SIP authentication services MUST add a "ppt" parameter to the 897 Identity header containing that PASSporT with a value of "rcd". The 898 resulting Identity header might look as follows: 900 Identity: sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9 901 dlxkWzoeU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgt 902 w0Lu5csIppPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=; \ 903 info=;alg=ES256;ppt=rcd 905 This specification assumes that by default, a SIP authentication 906 service derives the value of "rcd", specifically only for the "nam" 907 key value, from the display-name component of the From header field 908 value of the request, alternatively for some calls this may come from 909 the P-Asserted-ID header. It is however a matter of authentication 910 service policy to decide how it populates the value of "nam" key, 911 which MAY also derive from other fields in the request, from customer 912 profile data, or from access to external services. If the 913 authentication service generates a "rcd" claim containing "nam" with 914 a value that is not equivalent to the From header field display-name 915 value, it MUST use the full form of the PASSporT object in SIP. 917 14.2. Verification Service Behavior 919 [RFC8224] Section 6.2 Step 5 requires that specifications defining 920 "ppt" values describe any additional verifier behavior. The behavior 921 specified for the "ppt" values of "rcd" is as follows. If the 922 PASSporT is in compact form, then the verification service SHOULD 923 extract the display-name from the From header field value, if any, 924 and use that as the value for the "nam" key when it recomputes the 925 header and claims of the PASSporT object. Optionally, if there 926 exists a Call-Info header field as defined in 927 [I-D.ietf-sipcore-callinfo-rcd], the "jcard" value can be derived to 928 determine the "jcd" key when it recomputes the header and claims of 929 the PASSporT object. If the signature validates over the recomputed 930 object, then the verification should be considered successful. 932 However, if the PASSport is in full form with a "ppt" value of "rcd", 933 then the verification service MUST extract the value associated with 934 the "rcd" "nam" key in the object. If the signature validates, then 935 the verification service can use the value of the "rcd" "nam" key as 936 the display name of calling party, which would in turn be rendered to 937 alerted users or otherwise leveraged in accordance with local policy. 938 This allows SIP networks that convey the display name through a field 939 other than the From header field to interoperate with this 940 specification. Similarly, the "jcd" or linked "jcl" jcard 941 information and "crn" can be optionally, based on local policy for 942 devices that support it, used to populate a Call-Info header field 943 following the format of [I-D.ietf-sipcore-callinfo-rcd]. 945 The third-party "rcd" PASSporT cases presents some new challenges, as 946 an attacker could attempt to cut-and-paste such a third-party 947 PASSporT into a SIP request in an effort to get the terminating user 948 agent to render the display name or confidence values it contains to 949 a call that should have no such assurance. A third-party "rcd" 950 PASSporT provides no assurance that the calling party number has not 951 been spoofed: if it is carried in a SIP request, for example, then 952 some other PASSporT in another Identity header field value would have 953 to carry a PASSporT attesting that. A verification service MUST 954 determine that the calling party number shown in the "orig" of the 955 "rcd" PASSporT corresponds to the calling party number of the call it 956 has received, and that the "iat" field of the "rcd" PASSporT is 957 within the date interval that the verification service would 958 ordinarily accept for a PASSporT. 960 Verification services may alter their authorization policies for the 961 credentials accepted to sign PASSporTs when third parties generate 962 PASSporT objects, per Section 12.1. This may include accepting a 963 valid signature over a PASSporT even if it is signed with a 964 credential that does not attest authority over the identity in the 965 "orig" claim of the PASSporT, provided that the verification service 966 has some other reason to trust the signer. No further guidance on 967 verification service authorization policy is given here. 969 The behavior of a SIP UAS upon receiving an INVITE containing a 970 PASSporT object with a "rcd" claim largely remains a matter of 971 implementation policy. In most cases, implementations would render 972 this calling party name information to the user while alerting. Any 973 user interface additions to express confidence in the veracity of 974 this information are outside the scope of this specification. 976 15. Using "rcd" as additional claims to other PASSporT extensions 978 Rich Call Data, including calling name information, for example, is 979 often data that is additive data to the personal communications 980 information defined in the core PASSporT data required to support the 981 security properties defined in [RFC8225]. For cases where the entity 982 that is originating the personal communications and additionally is 983 supporting the authentication service and also is the authority of 984 the Rich Call Data, rather than creating multiple identity headers 985 with multiple PASSporT extensions or defining multiple combinations 986 and permutations of PASSporT extension definitions, the 987 authentication service can alternatively directly add the "rcd" 988 claims to the PASSporT it is creating, whether it is constructed with 989 a PASSporT extension or not. 991 Note: There is one very important caveat to this capability, because 992 generally if there is URI referenced content in an "rcd" PASSporT 993 there is often the requirement to use "rcdi" and JWT Claims 994 Constraints. So, it is important for the user of this specification 995 to recognize that the certificates used must include the necessary 996 JWT Claims Constraints for proper integrity and security of the 997 values in the "rcd" claim incorporated into PASSporTs that are not 998 "rcd". 1000 15.1. Procedures for applying "rcd" as claims only 1002 For a given PASSporT using some other extension than "rcd", the 1003 Authentication Service MAY additionally include the "rcd" claim as 1004 defined in this document. This would result in a set of claims that 1005 correspond to the original intended extension with the addition of 1006 the "rcd" claim. 1008 The Verification service that receives the PASSporT, if it supports 1009 this specification and chooses to, should interpret the "rcd" claim 1010 as simply just an additional claim intended to deliver and/or 1011 validate delivered Rich Call Data. 1013 15.2. Example for applying "rcd" as claims only 1015 In the case of [RFC8588] which is the PASSporT extension supporting 1016 the SHAKEN specification [ATIS-1000074], a common case for an 1017 Authentication service to co-exist in a CSP network along with the 1018 authority over the calling name used for the call. Rather than 1019 require two identity headers, the CSP Authentication Service can 1020 apply both the SHAKEN PASSporT claims and extension and simply add 1021 the "rcd" required claims defined in this document. 1023 For example, the PASSporT claims for the "shaken" PASSporT with "rcd" 1024 claims would be as follows: 1026 Protected Header 1027 { 1028 "alg":"ES256", 1029 "typ":"passport", 1030 "ppt":"shaken", 1031 "x5u":"https://cert.example.org/passport.cer" 1032 } 1033 Payload 1034 { 1035 "attest":"A", 1036 "dest":{"tn":["12025551001"]}, 1037 "iat":1443208345, 1038 "orig":{"tn":"12025551000"}, 1039 "origid":"123e4567-e89b-12d3-a456-426655440000", 1040 "rcd":{"nam":"James Bond"} 1041 } 1043 A Verification Service that supports "rcd" and "shaken" PASSporT 1044 extensions is able to receive the above PASSporT and interpret both 1045 the "shaken" claims as well as the "rcd" defined claim. 1047 If the Verification Service only understands the "shaken" extension 1048 claims but doesn't support "rcd", the "rcd" is ignored and 1049 disregarded. 1051 16. Acknowledgements 1053 We would like to thank David Hancock, Robert Sparks, Russ Housley, 1054 Eric Burger, Alec Fenichel, and Ben Campbell for helpful suggestions, 1055 review, and comments. 1057 17. IANA Considerations 1059 17.1. JSON Web Token Claim 1061 This specification requests that the IANA add three new claims to the 1062 JSON Web Token Claims registry as defined in [RFC7519]. 1064 Claim Name: "rcd" 1066 Claim Description: Rich Call Data Information 1067 Change Controller: IESG 1069 Specification Document(s): [RFCThis] 1071 Claim Name: "rcdi" 1073 Claim Description: Rich Call Data Integrity Information 1075 Change Controller: IESG 1077 Specification Document(s): [RFCThis] 1079 Claim Name: "crn" 1081 Claim Description: Call Reason 1083 Change Controller: IESG 1085 Specification Document(s): [RFCThis] 1087 17.2. PASSporT Types 1089 This specification requests that the IANA add a new entry to the 1090 PASSporT Types registry for the type "rcd" which is specified in 1091 [RFCThis]. 1093 17.3. PASSporT RCD Types 1095 This document requests that the IANA create a new registry for 1096 PASSporT RCD types. Registration of new PASSporT RCD types shall be 1097 under the Specification Required policy. 1099 This registry is to be initially populated with three values, "nam", 1100 "jcd", and "jcl", which are specified in [RFCThis]. 1102 18. Security Considerations 1104 Revealing information such as the name, location, and affiliation of 1105 a person necessarily entails certain privacy risks. Baseline 1106 PASSporT has no particular confidentiality requirement, as the 1107 information it signs over in a using protocol like SIP is all 1108 information that SIP carries in the clear anyway. Transport-level 1109 security can hide those SIP fields from eavesdroppers, and the same 1110 confidentiality mechanisms would protect any PASSporT(s) carried in 1111 SIP. 1113 Since computation of "rcdi" digests for URIs requires the loading of 1114 referenced content, it would be best practice to validate that 1115 content at the creation of the "rcdi" or corresponding JWT claim 1116 constraint value by checking for content that may cause issues for 1117 verification services or that doesn't follow the behavior defined in 1118 this document, e.g. unreasonably sized data, the inclusion of 1119 recursive URI references, etc. 1121 18.1. The use of JWT Claim Constraints in delegate certificates to 1122 exclude unauthorized Claims 1124 While this can apply to any PASSporT that is signed with a STIR 1125 Delegate Certificates [I-D.ietf-stir-cert-delegation], it is 1126 important to note that when constraining PASSporTs to include 1127 specific claims or contents of claims, it is also important to 1128 consider potential attacks by non-authorized signers that may include 1129 other potential PASSporT claims that weren't originally vetted by the 1130 authorized entity providing the delegate certificate. The use of JWT 1131 claims constraints as defined in [I-D.housley-stir-enhance-rfc8226] 1132 for preventing the ability to include claims beyond the claims 1133 defined in this document may need to be considered. 1134 [I-D.housley-stir-enhance-rfc8226] in the security considerations 1135 also notes that the use of mustExclude for the "rcdi" when "rcd" is 1136 used is discouraged, otherwise it would prevent the proper integrity 1137 protection mechanism to be used. 1139 19. References 1141 19.1. Normative References 1143 [I-D.housley-stir-enhance-rfc8226] 1144 Housley, R., "Enhanced JWT Claim Constraints for STIR 1145 Certificates", draft-housley-stir-enhance-rfc8226-00 (work 1146 in progress), January 2021. 1148 [I-D.ietf-sipcore-callinfo-rcd] 1149 Wendt, C. and J. Peterson, "SIP Call-Info Parameters for 1150 Rich Call Data", draft-ietf-sipcore-callinfo-rcd-01 (work 1151 in progress), November 2020. 1153 [I-D.ietf-stir-cert-delegation] 1154 Peterson, J., "STIR Certificate Delegation", draft-ietf- 1155 stir-cert-delegation-03 (work in progress), July 2020. 1157 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1158 A., Peterson, J., Sparks, R., Handley, M., and E. 1159 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1160 DOI 10.17487/RFC3261, June 2002, 1161 . 1163 [RFC4627] Crockford, D., "The application/json Media Type for 1164 JavaScript Object Notation (JSON)", RFC 4627, 1165 DOI 10.17487/RFC4627, July 2006, 1166 . 1168 [RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., 1169 "JavaScript Object Notation (JSON) Pointer", RFC 6901, 1170 DOI 10.17487/RFC6901, April 2013, 1171 . 1173 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 1174 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 1175 DOI 10.17487/RFC6919, April 2013, 1176 . 1178 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, 1179 DOI 10.17487/RFC7095, January 2014, 1180 . 1182 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 1183 Telephone Identity Problem Statement and Requirements", 1184 RFC 7340, DOI 10.17487/RFC7340, September 2014, 1185 . 1187 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1188 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1189 . 1191 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 1192 "Authenticated Identity Management in the Session 1193 Initiation Protocol (SIP)", RFC 8224, 1194 DOI 10.17487/RFC8224, February 2018, 1195 . 1197 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 1198 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 1199 . 1201 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 1202 Credentials: Certificates", RFC 8226, 1203 DOI 10.17487/RFC8226, February 2018, 1204 . 1206 [RFC8588] Wendt, C. and M. Barnes, "Personal Assertion Token 1207 (PaSSporT) Extension for Signature-based Handling of 1208 Asserted information using toKENs (SHAKEN)", RFC 8588, 1209 DOI 10.17487/RFC8588, May 2019, 1210 . 1212 19.2. Informative References 1214 [ATIS-1000074] 1215 ATIS/SIP Forum NNI Task Group, "Signature-based Handling 1216 of Asserted information using toKENs (SHAKEN) 1217 ", January 2017. 1220 [I-D.ietf-stir-oob] 1221 Rescorla, E. and J. Peterson, "STIR Out-of-Band 1222 Architecture and Use Cases", draft-ietf-stir-oob-07 (work 1223 in progress), March 2020. 1225 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1226 Requirement Levels", BCP 14, RFC 2119, 1227 DOI 10.17487/RFC2119, March 1997, 1228 . 1230 Authors' Addresses 1232 Chris Wendt 1233 Comcast 1234 Comcast Technology Center 1235 Philadelphia, PA 19103 1236 USA 1238 Email: chris-ietf@chriswendt.net 1240 Jon Peterson 1241 Neustar Inc. 1242 1800 Sutter St Suite 570 1243 Concord, CA 94520 1244 US 1246 Email: jon.peterson@neustar.biz