idnits 2.17.1 draft-ietf-stir-passport-rcd-10.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: [I-D.ietf-sipcore-callinfo-rcd] MUST be used. "jcd" claim MAY NOT be used as part of compact form. -- The document date (February 22, 2021) is 1159 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 1071, 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: August 26, 2021 Neustar Inc. 6 February 22, 2021 8 PASSporT Extension for Rich Call Data 9 draft-ietf-stir-passport-rcd-10 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 August 26, 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 Claims . . . . . . . . . . . . . . . . . . . . . . . 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 5.2. "rcdi" RCD Integrity Claim . . . . . . . . . . . . . . . 8 74 5.2.1. Creation of the "rcd" element digests . . . . . . . . 9 75 5.2.2. JWT Claim Constraint for "rcd" claims only . . . . . 12 76 5.2.3. JWT Claim Constraint for "rcd" and "rcdi" claims . . 12 77 5.3. PASSporT "crn" claim - Call Reason . . . . . . . . . . . 13 78 5.3.1. JWT Constraint for "crn" claim . . . . . . . . . . . 13 79 6. "rcd" and "crn" Claims Usage . . . . . . . . . . . . . . . . 13 80 6.1. Example "rcd" PASSporTs . . . . . . . . . . . . . . . . . 14 81 7. Compact form of "rcd" PASSporT . . . . . . . . . . . . . . . 15 82 7.1. Compact form of the "rcd" PASSporT claim . . . . . . . . 15 83 7.2. Compact form of the "rcdi" PASSporT claim . . . . . . . . 16 84 7.3. Compact form of the "crn" PASSporT claim . . . . . . . . 16 85 8. Further Information Associated with Callers . . . . . . . . . 16 86 9. Third-Party Uses . . . . . . . . . . . . . . . . . . . . . . 17 87 9.1. Signing as a Third Party . . . . . . . . . . . . . . . . 18 88 10. Levels of Assurance . . . . . . . . . . . . . . . . . . . . . 19 89 11. Using "rcd" in SIP . . . . . . . . . . . . . . . . . . . . . 19 90 11.1. Authentication Service Behavior . . . . . . . . . . . . 19 91 11.2. Verification Service Behavior . . . . . . . . . . . . . 20 92 12. Using "rcd" as additional claims to other PASSporT extensions 21 93 12.1. Procedures for applying "rcd" as claims only . . . . . . 22 94 12.2. Example for applying "rcd" as claims only . . . . . . . 22 96 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 97 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 98 14.1. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 23 99 14.2. PASSporT Types . . . . . . . . . . . . . . . . . . . . . 23 100 14.3. PASSporT RCD Types . . . . . . . . . . . . . . . . . . . 24 101 15. Security Considerations . . . . . . . . . . . . . . . . . . . 24 102 15.1. The use of JWT Claim Constraints in delegate 103 certificates to exclude unauthorized Claims . . . . . . 24 104 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 105 16.1. Normative References . . . . . . . . . . . . . . . . . . 24 106 16.2. Informative References . . . . . . . . . . . . . . . . . 26 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 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 will be extending 144 PASSporT to provide cryptographic protection for the "display-name" 145 field of SIP requests as well as further "rich call data" (RCD) about 146 the caller, which includes the contents of the Call-Info header field 147 or other data structures that can be added to the PASSporT. This 148 document furthermore specifies a third-party profile that would allow 149 external authorities to convey rich information associated with a 150 calling number via a new type of PASSporT. Finally, this document 151 describes how to preserve the integrity of the RCD in scenarios where 152 there may be non-authoritative users initiating and signing RCD and 153 therefore a 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 copyright violations or other policy enforcement, there 198 will likely be the desire to pre-certify or "vet" the specific use of 199 rich 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 will be defined to accomplish that for 208 two distinct categories of purposes. The first of the mechanisms 209 include the definition of an integrity claim. The RCD integrity 210 mechanism is a process of generating a sufficiently strong 211 cryptographic digest for both the "rcd" claim contents (e.g. "nam", 212 "jcd", "jcl") defined below and the resources defined by one or more 213 globally unique HTTPS URLs referenced by the contents (e.g. an image 214 file referenced by "jcd" or a jCard referenced by "jcl"). This 215 mechanism is inspired by and based on the W3C Subresource Integrity 216 specification (http://www.w3.org/TR/SRI/). The second of the 217 mechanisms uses the capability called JWT Claim Constraints, defined 218 in [RFC8226] and extended in [I-D.housley-stir-enhance-rfc8226]. The 219 JWT Claim Constraints specifically guide the verifier within the 220 certificate used to sign the PASSporT for the inclusion (or 221 exclusion) of specific claims and their values, so that the content 222 intended by the 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 Claims 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 SHOULD NOT be included if there is a "jcl" key included. 310 The "jcd" and "jcl" keys should be mutually exclusive. 312 Note: even though we refer to [I-D.ietf-sipcore-callinfo-rcd] as the 313 definition of the jcard properties for usage in a "rcd" PASSporT, 314 other protocols can be adapted for use of "jcd" (or similarly "jcl" 315 below) key beyond SIP and Call-Info. 317 5.1.3. "jcl" key 319 The "jcl" key value is defined to contain a HTTPS URL that refers the 320 recipient to a jCard [RFC7095] JSON object hosted on a HTTPS enabled 321 web server. The web server MUST use the MIME media type for JSON 322 text as application/json with a default encoding of UTF-8 [RFC4627]. 323 This link may derive from the Call-Info header field value defined in 324 [I-D.ietf-sipcore-callinfo-rcd] with a type of "jcard". As also 325 defined in [I-D.ietf-sipcore-callinfo-rcd], format of the jCard and 326 properties used should follow the normative usage and formatting 327 rules and procedures. The "jcl" key is optional. If included, this 328 key MUST only be included once in the "rcd" JSON object and MUST NOT 329 be included if there is a "jcd" key included. The "jcd" and "jcl" 330 keys MUST be used mutually exclusively. 332 5.2. "rcdi" RCD Integrity Claim 334 The "rcdi" claim is claim that MUST be included for the second and 335 fourth modes described in integrity overview section of this 336 document. If this claim is present it MUST be only included once 337 with a corresponding single "rcd" claim. The value of the "rcdi" key 338 pair is a JSON object that is defined as follows. 340 The claim value of "rcdi" claim key is a JSON object with a set of 341 JSON key/value pairs. These objects will correspond to each of the 342 elements of the "rcd" claim object that require integrity protection 343 with an associated digest over the content referenced by the key 344 string. The individual digest of different elements of the "rcd" 345 claim data and external URI referenced content is kept specifically 346 separate to allow the ability to verify the integrity of only the 347 elements that are ultimately retrieved or downloaded or rendered to 348 the end-user. 350 The key value will reference a specific object within the "rcd" claim 351 value using a JSON pointer defined in [RFC6901] with a minor 352 additional rule to support external URI references that include JSON 353 objects themselves, in particular for the specific case of the use of 354 "jcl". JSON pointer syntax is the key value that specifies exactly 355 the part of JSON that should be used to generate the digest which 356 will be the resulting string that makes up the value for the 357 corresponding key. Detailed procedures are provided below, but an 358 example "rcdi" is provided here: 360 "rcdi" : { 361 "/jcd": "sha256-H8BRh8j48O9oAZzq6A9RINQZngK7T62em8MUt1FLm52", 362 "/jcd/1/2/3": "sha256-AZzq6A9RINQZngK7T62em8MUt1FLm52H8BRh8j48O9o" 363 } 365 The values of each key pair are a digest combined with a string that 366 defines the crypto algorithm used to generate the digest. For RCD, 367 implementations MUST support the following hash algorithms, "SHA256", 368 "SHA384", or "SHA512". The SHA-256, SHA-384, and SHA-512 are part of 369 the SHA-2 set of cryptographic hash functions defined by the NIST. 370 Implementations MAY support additional algorithms, but MUST NOT 371 support known weak algorithms such as MD5 or SHA-1. In the future, 372 the list of algorithms may be re-evaluated based on security best 373 practices. The algorithms MUST be represented in the text by 374 "sha256", "sha384", or "sha512". The character following the 375 algorithm string MUST be a minus character, "-". The subsequent 376 characters MUST be the base64 encoded digest of a canonicalized and 377 concatenated string based on the JSON pointer referenced elements of 378 "rcd" claim or the URI referenced content contained in the claim. 380 The details of the determination of the input string used to 381 determine the digest are defined in the next section. 383 5.2.1. Creation of the "rcd" element digests 385 "rcd" claim objects can contain "nam", "jcd", or "jcl" keys as part 386 of the "rcd" JSON object claim value. This specification defines the 387 use of JSON pointer [RFC6901] as a basic to reference specific 388 elements. 390 In the case of "nam", the only allowed value is a "string". In order 391 to reference the "nam" string value for a digest, the JSON pointer 392 string would be "/nam" and the digest string would be created using 393 only the string pointed to by that "/nam" following the rules of JSON 394 pointer. 396 In the case of "jcd", the value associated is a jCard JSON object, 397 which happens to be a JSON array with sub-arrays. JSON pointer 398 notation uses numeric indexes into elements of arrays, including when 399 those elements are arrays themselves. 401 As example, for the following "rcd" claim: 403 "rcd": { 404 "nam": "Q Branch Spy Gadgets", 405 "jcd": ["vcard", 406 [ ["version",{},"text","4.0"], 407 ["fn",{},"text","Q Branch"], 408 ["org",{},"text","MI6;Q Branch Spy Gadgets"], 409 ["photo",{},"uri", 410 "https://example.com/photos/quartermaster-256x256.png"], 411 ["logo",{},"uri", 412 "https://example.com/logos/mi6-256x256.jpg"], 413 ["logo",{},"uri", 414 "https://example.com/logos/mi6-64x64.jpg"] 415 ] 416 ] 417 } 419 In order to use JSON pointer to refer to the URIs, the following 420 example "rcdi" claim includes a digest for the entire "jcd" array 421 string as well as three additional digests for the URIs, where, as 422 defined in [RFC6901] zero-based array indexes are used to reference 423 the URI strings. 425 "rcdi": { 426 "/jcd": "sha256-30SFLGHL40498527", 427 "/jcd/1/3/3": "sha256-12938918VNJDSNCJ", 428 "/jcd/1/4/3": "sha256-VNJDSNCJ12938918", 429 "/jcd/1/5/3": "sha256-4049852730SFLGHL" 430 } 431 } 433 For the use of JSON pointer in "jcd" and because array indexes are 434 dependent on the order of the elements in the jCard, the digest for 435 the "/jcd" corresponding to the entire jCard array string MUST be 436 included to avoid any possibility of substitution or insertion 437 attacks that may be possible to avoid integrity detection, even 438 though unlikely. Each URI referenced in the jCard array string MUST 439 have a corresponding JSON pointer string key and digest value. 441 In the case of the use of a "jcl" URI reference to an external jCard, 442 the procedures are similar to "jcd" with the exception and the minor 443 modification to JSON pointer, where "/jcl" is used to refer to the 444 external jCard array string and any following numeric array indexes 445 added to the "jcl" (e.g. "/jcl/1/2/3") are treated as if the 446 externally referenced jCard was part of the overall "rcd" claim JSON 447 object. The following example illustrates a "jcl" version of the 448 above "jcd" example. 450 "rcd": { 451 "nam": "Q Branch Spy Gadgets", 452 "jcl": "https://example.com/qbranch.json" 453 }, 454 "rcdi": { 455 "/jcl": "sha256-30SFLGHL40498527", 456 "/jcl/1/3/3": "sha256-12938918VNJDSNCJ", 457 "/jcl/1/4/3": "sha256-VNJDSNCJ12938918", 458 "/jcl/1/5/3": "sha256-4049852730SFLGHL" 459 } 460 https://example.com/qbranch.json: 461 ["vcard", 462 [ ["version",{},"text","4.0"], 463 ["fn",{},"text","Q Branch"], 464 ["org",{},"text","MI6;Q Branch Spy Gadgets"] 465 ["photo",{},"uri", 466 "https://example.com/photos/quartermaster-256x256.png"] 467 ["logo",{},"uri", 468 "https://example.com/logos/mi6-256x256.jpg"] 469 ["logo",{},"uri", 470 "https://example.com/logos/mi6-64x64.jpg"] 471 ] 472 ] 474 In order to facilitate proper verification of the digest and whether 475 the "rcd" elements or content referenced by URIs were modified, the 476 input to the digest must be completely deterministic at three points 477 in the process. First, at the certification point where the content 478 is evaluated to conform to the application policy and the JWT Claim 479 Constraints is applied to the certificate containing the digest. 480 Second, when the call is signed at the Authentication Service, there 481 may be a local policy to verify that the provided "rcd" claim 482 corresponds to each digest. Third, when the "rcd" data is verified 483 at the Verification Service, it should verify each digest by 484 constructing the input digest string for the element being verified 485 and referenced by the JSON pointer string. 487 The procedure for the creation of each "rcd" element digest string 488 corresponding to a JSON pointer string key is as follows. 490 1. The JSON pointer will either refer to an element that is a part 491 or whole of a JSON object string or to a string that is a URI 492 referencing an external resource. 494 2. For a JSON formatted string, serialize the element JSON to remove 495 all white space and line breaks. The procedures of this 496 deterministic JSON serialization are defined in [RFC8225], 497 Section 9. The resulting string is used to create the digest. 499 3. For any URI referenced content, the content can either be a 500 string as in jCard JSON objects or binary content. For example, 501 image and audio files contain binary content. If the content is 502 binary format it should be Base64 encoded to create a string, 503 otherwise the direct string content of the file is used to create 504 the digest. 506 5.2.2. JWT Claim Constraint for "rcd" claims only 508 For the third mode described in the integrity overview section of 509 this document, where only JWT Claim Constraint for "rcd" claims, 510 without an "rcdi" claim, is required, the procedure should be, when 511 creating the certificate to include a constraint on inclusion of the 512 "rcd" claim as well as the contents of that claim. 514 The certificate JWT Claims Constraint MUST include the following: 516 o a "mustInclude" for the "rcd" claim and a "permittedValues" equal 517 to the created "rcd" claim value string. 519 The "permitedValues" for the "rcd" claim may contain multiple 520 entries, to support the case where the certificate holder is 521 authorized to use different sets of rich call data. 523 5.2.3. JWT Claim Constraint for "rcd" and "rcdi" claims 525 For the fourth mode described in the integrity overview section of 526 this document, if the signing of an "rcdi" claim is required to be 527 protected by the authoritative certificate creator using JWT 528 Constraints in the certificate, the procedure which is intended to 529 constrain the signer to construct the "rcd" and "rcdi" claims and 530 reference external content via URI in a pre-determined way. Once 531 both the contents of the "rcd" claim and any linked content is 532 certified and the construction of the "rcdi" claim is complete, the 533 "rcdi" claim is linked to the STIR certificate associated with the 534 signature in the PASSporT via JWT Claim Constraints as defined in 535 [RFC8226] Section 8. It should be recognized that the "rcdi" set of 536 digests is intended to be unique for only a specific combination of 537 "rcd" content and URI referenced external content. 539 The certificate JWT Claims Constraint MUST include both of the 540 following: 542 o a "mustInclude" for the "rcd" claim, which simply constrains the 543 fact that an "rcd" should be included if there is a "rcdi" 545 o a "mustInclude" for the "rcdi" claim and a "permittedValues" equal 546 to the created "rcdi" claim value string. 548 The "permitedValues" for the "rcdi" claim may contain multiple 549 entries, to support the case where the certificate holder is 550 authorized to use different sets of rich call data. 552 5.3. PASSporT "crn" claim - Call Reason 554 This specification defines a new JSON Web Token claim for "crn", Call 555 Reason, the value of which is a single string or object that can 556 contains information as defined in [I-D.ietf-sipcore-callinfo-rcd] 557 corresponding to the "reason" parameter for the Call-Info header. 558 This claim is optional. 560 Example "crn" claim with "rcd": 561 "rcd": { "nam": "James Bond", 562 "jcl": "https://example.org/james_bond.json"}, 563 "crn" : "For your ears only" 565 5.3.1. JWT Constraint for "crn" claim 567 The integrity of the "crn" claim can optionally be protected by the 568 authoritative certificate creator using JWT Constraints in the 569 certificate. If this protection is used, a "mustInclude" for the 570 "rcdi" claim and a "permittedValues" equal to the "crn" claim value 571 string SHOULD be included. 573 6. "rcd" and "crn" Claims Usage 575 Either the "rcd" or "crn" claim may appear in any PASSporT claims 576 object as an optional element. The creator of a PASSporT MAY also 577 add a "ppt" value of "rcd" to the header of a PASSporT as well, in 578 which case the PASSporT claims MUST contain either a "rcd" or "crn" 579 claim, and any entities verifying the PASSporT object will be 580 required to understand the "ppt" extension in order to process the 581 PASSporT in question. A PASSporT header with the "ppt" included will 582 look as follows: 584 { "typ":"passport", 585 "ppt":"rcd", 586 "alg":"ES256", 587 "x5u":"https://www.example.com/cert.cer" } 589 The PASSporT claims object will then contain the "rcd" key with its 590 corresponding value. The value of "rcd" is an array of JSON objects, 591 of which one, the "nam" object, is mandatory. The key syntax of 592 "nam" follows the display-name ABNF given in [RFC3261]. 594 After the header and claims PASSporT objects have been constructed, 595 their signature is generated normally per the guidance in [RFC8225]. 597 6.1. Example "rcd" PASSporTs 599 An example of a "nam" only PASSporT claims object is shown next (with 600 line breaks for readability only). 602 { "orig":{"tn":"12025551000"}, 603 "dest":{"tn":["12025551001"]}, 604 "iat":1443208345, 605 "rcd":{"nam":"James Bond"} } 607 An example of a "nam" only PASSporT claims object with an "rcdi" 608 claim is shown next (with line breaks for readability only). 610 { "orig":{"tn":"12025551000"}, 611 "dest":{"tn":["12025551001"]}, 612 "iat":1443208345, 613 "rcd":{"nam":"James Bond"}, 614 "rcdi":{"/nam": "sha256-918VNJD12938SNCJ"} 615 } 617 An example of a "rcd" claims object that includes the "jcd" and also 618 contains a URI which requires the inclusion of an "rcdi" claim. 620 { 621 "orig": { "tn": "12025551000"}, 622 "dest": { "tn": ["12155551001"]}, 623 "iat": 1443208345, 624 "rcd": { 625 "nam": "Q Branch Spy Gadgets", 626 "jcd": ["vcard", 627 [ ["version",{},"text","4.0"], 628 ["fn",{},"text","Q Branch"], 629 ["org",{},"text","MI6;Q Branch Spy Gadgets"], 630 ["photo",{},"uri","https://example.com/photos/q-256x256.png"], 631 ["logo",{},"uri","https://example.com/logos/mi6-256x256.jpg"], 632 ["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg"] 633 ] ] 634 }, 635 "crn": "Rendezvous for Little Nellie", 636 "rcdi": { 637 "/nam": "sha256-918VNJD12938SNCJ", 638 "/jcd": "sha256-VNJDSNCJ12938918", 639 "/jcd/1/3/3": "sha256-12938918VNJDSNCJ", 640 "/jcd/1/4/3": "sha256-VNJDSNCJ12938918", 641 "/jcd/1/5/3": "sha256-4049852730SFLGHL" 642 } 643 } 644 In an example PASSporT where a jCard is linked via HTTPS URL and 645 "jcl" a jCard file served at a particular URL will be created. 647 An example jCard JSON file is shown as follows: 649 https://example.com/qbranch.json: 650 ["vcard", 651 [ ["version",{},"text","4.0"], 652 ["fn",{},"text","Q Branch"], 653 ["org",{},"text","MI6;Q Branch Spy Gadgets"], 654 ["photo",{},"uri","https://example.com/photos/q-256x256.png"], 655 ["logo",{},"uri","https://example.com/logos/mi6-256x256.jpg"], 656 ["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg"] 657 ] 658 ] 660 If that jCard is hosted at the example address of 661 "https://example.com/qbranch.json", the corresponding PASSporT claims 662 object would be as follows: 664 { 665 "orig": {"tn": "12025551000"}, 666 "dest": {"tn": ["12155551001"]}, 667 "iat": 1443208345, 668 "rcd": { 669 "nam": "Q Branch Spy Gadgets", 670 "jcl": "https://example.com/qbranch.json" 671 }, 672 "crn": "Rendezvous for Little Nellie", 673 "rcdi": { 674 "/nam": "sha256-918VNJD12938SNCJ", 675 "/jcl": "sha256-VNJDSNCJ12938918", 676 "/jcl/1/3/3": "sha256-12938918VNJDSNCJ", 677 "/jcl/1/4/3": "sha256-VNJDSNCJ12938918", 678 "/jcl/1/5/3": "sha256-4049852730SFLGHL" 679 } 680 } 682 7. Compact form of "rcd" PASSporT 684 7.1. Compact form of the "rcd" PASSporT claim 686 Compact form of an "rcd" PASSporT claim has some restrictions but 687 mainly follows standard PASSporT compact form procedures. For re- 688 construction of the "nam" claim the string for the display-name in 689 the From header field. For re-construction of the "jcl", the Call- 690 Info header as with purpose "jcard" defined in 692 [I-D.ietf-sipcore-callinfo-rcd] MUST be used. "jcd" claim MAY NOT be 693 used as part of compact form. 695 7.2. Compact form of the "rcdi" PASSporT claim 697 Compact form of an "rcdi" PASSPorT claim is not supported, so if 698 "rcdi" is required compact form should not be used. 700 7.3. Compact form of the "crn" PASSporT claim 702 Compact form of a "crn" PASSporT claim shall be re-constructed using 703 the "call-reason" parameter of a Call-Info header as defined by 704 [I-D.ietf-sipcore-callinfo-rcd]. 706 8. Further Information Associated with Callers 708 Beyond naming information and the information that can be contained 709 in a jCard [RFC7095] object, there may be additional human-readable 710 information about the calling party that should be rendered to the 711 end user in order to help the called party decide whether or not to 712 pick up the phone. This is not limited to information about the 713 caller, but includes information about the call itself, which may 714 derive from analytics that determine based on call patterns or 715 similar data if the call is likely to be one the called party wants 716 to receive. Such data could include: 718 o information related to the location of the caller, or 720 o any organizations or institutions that the caller is associated 721 with, or even categories of institutions (is this a government 722 agency, or a bank, or what have you), or 724 o hyperlinks to images, such as logos or pictures of faces, or to 725 similar external profile information, or 727 o information that will be processed by an application before 728 rendering it to a user, like social networking data that shows 729 that an unknown caller is a friend-of-a-friend, or reputation 730 scores derived from crowdsourcing, or confidence scores based on 731 broader analytics about the caller and callee. 733 All of these data elements would benefit from the secure attestations 734 provided by the STIR and PASSporT frameworks. A new IANA registry 735 has been defined to hold potential values of the "rcd" array; see 736 Section 14.3. Specific extensions to the "rcd" PASSporT claim are 737 left for future specification. 739 While in the traditional telephone network, the business relationship 740 between calling customers and their telephone service providers is 741 the ultimate root of information about a calling party's name, some 742 other forms of data like crowdsourced reputation scores might derive 743 from third parties. It is more likely that when those elements are 744 present, they will be in a third-party "rcd" PASSporT. 746 9. Third-Party Uses 748 While rich data about the call can be provided by an originating 749 authentication service, an intermediary in the call path could also 750 acquire rich call data by querying a third-party service. Such a 751 service effectively acts as a STIR Authentication Service, generating 752 its own PASSporT, and that PASSporT could be attached to a SIP call 753 by either the originating or terminating side. This third-party 754 PASSporT attests information about the calling number, rather than 755 the call or caller itself, and as such its RCD MUST NOT be used when 756 a call lacks a first-party PASSporT that assures verification 757 services that the calling party number is not spoofed. It is 758 intended to be used in cases when the originating side does not 759 supply a display-name for the caller, so instead some entity in the 760 call path invokes a third-party service to provide rich caller data 761 for a call. 763 In telephone operations today, a third-party information service is 764 commonly queried with the calling party's number in order to learn 765 the name of the calling party, and potentially other helpful 766 information could also be passed over that interface. The value of 767 using a PASSporT to convey this information from third parties lies 768 largely in the preservation of the third party's signature over the 769 data, and the potential for the PASSporT to be conveyed from 770 intermediaries to endpoint devices. Effectively, these use cases 771 form a sub-case of out-of-band [I-D.ietf-stir-oob] use cases. The 772 manner in which third-party services are discovered is outside the 773 scope of this document. 775 An intermediary use case might look as follows: a SIP INVITE carries 776 a display name in its From header field value and an initial PASSporT 777 object without the "rcd" claim. When a terminating verification 778 service implemented at a SIP proxy server receives this request, and 779 determines that the signature is valid, it might query a third-party 780 service that maps telephone numbers to calling party names. Upon 781 receiving the PASSport in a response from that third-party service, 782 the terminating side could add a new Identity header field to the 783 request for the "rcd" PASSporT object provided by the third-party 784 service. It would then forward the INVITE to the terminating user 785 agent. If the display name in the "rcd" PASSporT object matches the 786 display name in the INVITE, then the name would presumably be 787 rendered to the end user by the terminating user agent. 789 A very similar flow could be followed by an intermediary closer to 790 the origination of the call. Presumably such a service could be 791 implemented at an originating network in order to decouple the 792 systems that sign for calling party numbers from the systems that 793 provide rich data about calls. 795 In an alternative use case, the terminating user agent might query a 796 third-party service. In this case, no new Identity header field 797 would be generated, though the terminating user agent might receive a 798 PASSporT object in return from the third-party service, and use the 799 "rcd" field in the object as a calling name to render to users while 800 alerting. 802 9.1. Signing as a Third Party 804 A third-party PASSporT contains an "iss" element to distinguish its 805 PASSporTs from first-party PASSporTs. Third-party "rcd" PASSporTs 806 will necessarily be signed with credentials that do not have 807 authority over the identity that appears in the "orig" element of the 808 PASSporT claims. The presence of "iss" signifies that a different 809 category of credential is being used to sign a PASSporT than the 810 [RFC8226] certificates used to sign STIR calls; it is instead a 811 certificate that identifies the source of the "rcd" data. How those 812 credentials are issued and managed is outside the scope of this 813 specification; the value of "iss" however MUST reflect the Subject 814 Name field of the certificate used to sign a third-party PASSporT. 815 Relying parties in STIR have always been left to make their own 816 authorization decisions about whether to trust the signers of 817 PASSporTs, and in the third-party case, where an entity has 818 explicitly queried a service to acquire the PASSporT object, it may 819 be some external trust or business relationship that induces the 820 relying party to trust a PASSporT. 822 An example of a Third Party issued PASSporT claims object is as 823 follows. 825 { "orig":{"tn":"12025551000"}, 826 "dest":{"tn":["12025551001"]}, 827 "iat":1443208345, 828 "iss":"Example, Inc.", 829 "rcd":{"nam":"James Bond"} } 831 10. Levels of Assurance 833 As "rcd" can be provided by either first or third parties, relying 834 parties could benefit from an additional claim that indicates the 835 relationship of the attesting party to the caller. Even in first 836 party cases, this admits of some complexity: the Communications 837 Service Provider (CSP) to which a number was assigned might in turn 838 delegate the number to a reseller, who would then sell the number to 839 an enterprise, in which case the CSP might have little insight into 840 the caller's name. In third party cases, a caller's name could 841 derive from any number of data sources, on a spectrum between public 842 data scraped from web searches to a direct business relationship to 843 the caller. As multiple PASSporTs can be associated with the same 844 call, potentially a verification service could receive attestations 845 of the caller name from multiple sources, which have different levels 846 of granularity or accuracy. Therefore, PASSporTs that carry "rcd" 847 data SHOULD also carry an indication of the relationship of the 848 generator of the PASSporT to the caller. As stated in the previous 849 section, the use of "iss" MUST reflect the Subject Name of the 850 certificate used to sign a third-party PASSporT to represent that 851 relationship. 853 11. Using "rcd" in SIP 855 This section specifies SIP-specific usage for the "rcd" claim in 856 PASSporT, and in the SIP Identity header field value. Other using 857 protocols of PASSporT may define their own usages for the "rcd" 858 claim. 860 11.1. Authentication Service Behavior 862 An authentication service creating a PASSporT containing a "rcd" 863 claim MAY include a "ppt" for "rcd" or not. Third-party 864 authentication services following the behavior in Section 9.1 MUST 865 include a "ppt" of "rcd". If "ppt" does contain a "rcd", then any 866 SIP authentication services MUST add a "ppt" parameter to the 867 Identity header containing that PASSporT with a value of "rcd". The 868 resulting Identity header might look as follows: 870 Identity: sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9 871 dlxkWzoeU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgt 872 w0Lu5csIppPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=; \ 873 info=;alg=ES256;ppt=rcd 875 This specification assumes that by default, a SIP authentication 876 service will derive the value of "rcd", specifically only for the 877 "nam" key value, from the display-name component of the From header 878 field value of the request, alternatively for some calls this may 879 come from the P-Asserted-ID header. It is however a matter of 880 authentication service policy to decide how it populates the value of 881 "rcd" and "nam" key, which MAY also derive from other fields in the 882 request, from customer profile data, or from access to external 883 services. If the authentication service generates a PASSporT object 884 containing "rcd" with a value that is not equivalent to the From 885 header field display-name value, it MUST use the full form of the 886 PASSporT object in SIP. 888 11.2. Verification Service Behavior 890 [RFC8224] Section 6.2 Step 5 requires that specifications defining 891 "ppt" values describe any additional verifier behavior. The behavior 892 specified for the "ppt" values of "rcd" is as follows. If the 893 PASSporT is in compact form, then the verification service SHOULD 894 extract the display-name from the From header field value, if any, 895 and use that as the value for the "nam" key when it recomputes the 896 header and claims of the PASSporT object. Optionally, if there 897 exists a Call-Info header field as defined in 898 [I-D.ietf-sipcore-callinfo-rcd], the "jcard" value can be derived to 899 determine the "jcd" key when it recomputes the header and claims of 900 the PASSporT object. If the signature validates over the recomputed 901 object, then the verification should be considered successful. 903 However, if the PASSport is in full form with a "ppt" value of "rcd", 904 then the verification service MUST extract the value associated with 905 the "rcd" "nam" key in the object. If the signature validates, then 906 the verification service can use the value of the "rcd" "nam" key as 907 the display name of calling party, which would in turn be rendered to 908 alerted users or otherwise leveraged in accordance with local policy. 909 This will allow SIP networks that convey the display name through a 910 field other than the From header field to interoperate with this 911 specification. Similarly, the "jcd" or linked "jcl" jcard 912 information and "crn" can be optionally, based on local policy for 913 devices that support it, used to populate a Call-Info header field 914 following the format of [I-D.ietf-sipcore-callinfo-rcd]. 916 The third-party "rcd" PASSporT cases presents some new challenges, as 917 an attacker could attempt to cut-and-paste such a third-party 918 PASSporT into a SIP request in an effort to get the terminating user 919 agent to render the display name or confidence values it contains to 920 a call that should have no such assurance. A third-party "rcd" 921 PASSporT provides no assurance that the calling party number has not 922 been spoofed: if it is carried in a SIP request, for example, then 923 some other PASSporT in another Identity header field value would have 924 to carry a PASSporT attesting that. A verification service MUST 925 determine that the calling party number shown in the "orig" of the 926 "rcd" PASSporT corresponds to the calling party number of the call it 927 has received, and that the "iat" field of the "rcd" PASSporT is 928 within the date interval that the verification service would 929 ordinarily accept for a PASSporT. 931 Verification services may alter their authorization policies for the 932 credentials accepted to sign PASSporTs when third parties generate 933 PASSporT objects, per Section 9.1. This may include accepting a 934 valid signature over a PASSporT even if it is signed with a 935 credential that does not attest authority over the identity in the 936 "orig" claim of the PASSporT, provided that the verification service 937 has some other reason to trust the signer. No further guidance on 938 verification service authorization policy is given here. 940 The behavior of a SIP UAS upon receiving an INVITE containing a 941 PASSporT object with a "rcd" claim will largely remain a matter of 942 implementation policy. In most cases, implementations would render 943 this calling party name information to the user while alerting. Any 944 user interface additions to express confidence in the veracity of 945 this information are outside the scope of this specification. 947 12. Using "rcd" as additional claims to other PASSporT extensions 949 Rich Call Data, including calling name information, for example, is 950 often data that is additive data to the personal communications 951 information defined in the core PASSporT data required to support the 952 security properties defined in [RFC8225]. For cases where the entity 953 that is originating the personal communications and additionally is 954 supporting the authentication service and also is the authority of 955 the Rich Call Data, rather than creating multiple identity headers 956 with multiple PASSporT extensions or defining multiple combinations 957 and permutations of PASSporT extension definitions, the 958 authentication service can alternatively directly add the "rcd" 959 claims to the PASSporT it is creating, whether it is constructed with 960 a PASSporT extension or not. 962 Note: There is one very important caveat to this capability, because 963 generally if there is URI referenced content in an "rcd" PASSporT 964 there is often the requirement to use "rcdi" and JWT Claims 965 Constraints. So, it is important for the user of this specification 966 to recognize that the certificates used must include the necessary 967 JWT Claims Constraints for proper integrity and security of the 968 values in the "rcd" claim incorporated into PASSporTs that are not 969 "rcd". 971 12.1. Procedures for applying "rcd" as claims only 973 For a given PASSporT using some other extension than "rcd", the 974 Authentication Service MAY additionally include the "rcd" claim as 975 defined in this document. This would result in a set of claims that 976 correspond to the original intended extension with the addition of 977 the "rcd" claim. 979 The Verification service that receives the PASSporT, if it supports 980 this specification and chooses to, should interpret the "rcd" claim 981 as simply just an additional claim intended to deliver and/or 982 validate delivered Rich Call Data. 984 12.2. Example for applying "rcd" as claims only 986 In the case of [RFC8588] which is the PASSporT extension supporting 987 the SHAKEN specification [ATIS-1000074], a common case for an 988 Authentication service to co-exist in a CSP network along with the 989 authority over the calling name used for the call. Rather than 990 require two identity headers, the CSP Authentication Service can 991 apply both the SHAKEN PASSporT claims and extension and simply add 992 the "rcd" required claims defined in this document. 994 For example, the PASSporT claims for the "shaken" PASSporT with "rcd" 995 claims would be as follows: 997 Protected Header 998 { 999 "alg":"ES256", 1000 "typ":"passport", 1001 "ppt":"shaken", 1002 "x5u":"https://cert.example.org/passport.cer" 1003 } 1004 Payload 1005 { 1006 "attest":"A", 1007 "dest":{"tn":["12025551001"]}, 1008 "iat":1443208345, 1009 "orig":{"tn":"12025551000"}, 1010 "origid":"123e4567-e89b-12d3-a456-426655440000", 1011 "rcd":{"nam":"James Bond"} 1012 } 1014 A Verification Service that supports "rcd" and "shaken" PASSporT 1015 extensions will be able to receive the above PASSporT and interpret 1016 both the "shaken" claims as well as the "rcd" defined claim. 1018 If the Verification Service only understands the "shaken" extension 1019 claims but doesn't support "rcd", the "rcd" can simply be ignored and 1020 disregarded. 1022 13. Acknowledgements 1024 We would like to thank David Hancock, Robert Sparks, Russ Housley, 1025 Eric Burger, and Alec Fenichel for helpful suggestions and comments. 1027 14. IANA Considerations 1029 14.1. JSON Web Token Claim 1031 This specification requests that the IANA add three new claims to the 1032 JSON Web Token Claims registry as defined in [RFC7519]. 1034 Claim Name: "rcd" 1036 Claim Description: Rich Call Data Information 1038 Change Controller: IESG 1040 Specification Document(s): [RFCThis] 1042 Claim Name: "rcdi" 1044 Claim Description: Rich Call Data Integrity Information 1046 Change Controller: IESG 1048 Specification Document(s): [RFCThis] 1050 Claim Name: "crn" 1052 Claim Description: Call Reason 1054 Change Controller: IESG 1056 Specification Document(s): [RFCThis] 1058 14.2. PASSporT Types 1060 This specification requests that the IANA add a new entry to the 1061 PASSporT Types registry for the type "rcd" which is specified in 1062 [RFCThis]. 1064 14.3. PASSporT RCD Types 1066 This document requests that the IANA create a new registry for 1067 PASSporT RCD types. Registration of new PASSporT RCD types shall be 1068 under the Specification Required policy. 1070 This registry is to be initially populated with three values, "nam", 1071 "jcd", and "jcl", which are specified in [RFCThis]. 1073 15. Security Considerations 1075 Revealing information such as the name, location, and affiliation of 1076 a person necessarily entails certain privacy risks. Baseline 1077 PASSporT has no particular confidentiality requirement, as the 1078 information it signs over in a using protocol like SIP is all 1079 information that SIP carries in the clear anyway. Transport-level 1080 security can hide those SIP fields from eavesdroppers, and the same 1081 confidentiality mechanisms would protect any PASSporT(s) carried in 1082 SIP. 1084 15.1. The use of JWT Claim Constraints in delegate certificates to 1085 exclude unauthorized Claims 1087 While this can apply to any PASSporT that is signed with a STIR 1088 Delegate Certificates [I-D.ietf-stir-cert-delegation], it is 1089 important to note that when constraining PASSporTs to include 1090 specific claims or contents of claims, it is also important to 1091 consider potential attacks by non-authorized signers that may include 1092 other potential PASSporT claims that weren't originally vetted by the 1093 authorized entity providing the delegate certificate. The use of JWT 1094 claims constraints as defined in [I-D.housley-stir-enhance-rfc8226] 1095 for preventing the ability to include claims beyond the claims 1096 defined in this document may need to be considered. 1098 16. References 1100 16.1. Normative References 1102 [I-D.housley-stir-enhance-rfc8226] 1103 Housley, R., "Enhanced JWT Claim Constraints for STIR 1104 Certificates", draft-housley-stir-enhance-rfc8226-00 (work 1105 in progress), January 2021. 1107 [I-D.ietf-sipcore-callinfo-rcd] 1108 Wendt, C. and J. Peterson, "SIP Call-Info Parameters for 1109 Rich Call Data", draft-ietf-sipcore-callinfo-rcd-01 (work 1110 in progress), November 2020. 1112 [I-D.ietf-stir-cert-delegation] 1113 Peterson, J., "STIR Certificate Delegation", draft-ietf- 1114 stir-cert-delegation-03 (work in progress), July 2020. 1116 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1117 A., Peterson, J., Sparks, R., Handley, M., and E. 1118 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1119 DOI 10.17487/RFC3261, June 2002, 1120 . 1122 [RFC4627] Crockford, D., "The application/json Media Type for 1123 JavaScript Object Notation (JSON)", RFC 4627, 1124 DOI 10.17487/RFC4627, July 2006, 1125 . 1127 [RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., 1128 "JavaScript Object Notation (JSON) Pointer", RFC 6901, 1129 DOI 10.17487/RFC6901, April 2013, 1130 . 1132 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 1133 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 1134 DOI 10.17487/RFC6919, April 2013, 1135 . 1137 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, 1138 DOI 10.17487/RFC7095, January 2014, 1139 . 1141 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 1142 Telephone Identity Problem Statement and Requirements", 1143 RFC 7340, DOI 10.17487/RFC7340, September 2014, 1144 . 1146 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1147 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1148 . 1150 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 1151 "Authenticated Identity Management in the Session 1152 Initiation Protocol (SIP)", RFC 8224, 1153 DOI 10.17487/RFC8224, February 2018, 1154 . 1156 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 1157 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 1158 . 1160 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 1161 Credentials: Certificates", RFC 8226, 1162 DOI 10.17487/RFC8226, February 2018, 1163 . 1165 [RFC8588] Wendt, C. and M. Barnes, "Personal Assertion Token 1166 (PaSSporT) Extension for Signature-based Handling of 1167 Asserted information using toKENs (SHAKEN)", RFC 8588, 1168 DOI 10.17487/RFC8588, May 2019, 1169 . 1171 16.2. Informative References 1173 [ATIS-1000074] 1174 ATIS/SIP Forum NNI Task Group, "Signature-based Handling 1175 of Asserted information using toKENs (SHAKEN) 1176 ", January 2017. 1179 [I-D.ietf-stir-oob] 1180 Rescorla, E. and J. Peterson, "STIR Out-of-Band 1181 Architecture and Use Cases", draft-ietf-stir-oob-07 (work 1182 in progress), March 2020. 1184 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1185 Requirement Levels", BCP 14, RFC 2119, 1186 DOI 10.17487/RFC2119, March 1997, 1187 . 1189 Authors' Addresses 1191 Chris Wendt 1192 Comcast 1193 Comcast Technology Center 1194 Philadelphia, PA 19103 1195 USA 1197 Email: chris-ietf@chriswendt.net 1199 Jon Peterson 1200 Neustar Inc. 1201 1800 Sutter St Suite 570 1202 Concord, CA 94520 1203 US 1205 Email: jon.peterson@neustar.biz