draft-ietf-stir-passport-rcd-06.txt   draft-ietf-stir-passport-rcd-07.txt 
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft Neustar Inc. Internet-Draft Neustar Inc.
Intended status: Standards Track C. Wendt Intended status: Standards Track C. Wendt
Expires: September 10, 2020 Comcast Expires: May 6, 2021 Comcast
March 09, 2020 November 02, 2020
PASSporT Extension for Rich Call Data PASSporT Extension for Rich Call Data
draft-ietf-stir-passport-rcd-06 draft-ietf-stir-passport-rcd-07
Abstract Abstract
This document extends PASSporT, a token for conveying This document extends PASSporT, a token for conveying
cryptographically-signed call information about personal cryptographically-signed call information about personal
communications, to include rich data that can be transmitted and communications, to include rich meta-data about a call and caller
subsequently rendered to users, extending identifying information that can be signed and integrity protected, transmitted, and
beyond human-readable display name comparable to the "Caller ID" subsequently rendered to users. This framework is intended to extend
function common on the telephone network. The element defined for caller and call specific information beyond human-readable display
this purpose, Rich Call Data (RCD), is an extensible object defined name comparable to the "Caller ID" function common on the telephone
to either be used as part of STIR or with SIP Call-Info to include network. The JSON element defined for this purpose, Rich Call Data
related information about calls that helps people decide whether to (RCD), is an extensible object defined to either be used as part of
pick up the phone. This signing of the RCD information is also STIR or with SIP Call-Info to include related information about calls
enhanced with an integrity mechanism to optionally protect the that helps people decide whether to pick up the phone. This signing
handling of this information between authoritative and non- of the RCD information is also enhanced with a integrity mechanism
authoritative parties authoring and signing the Rich Call Data for that is designed to protect the authoring and transport of this
support of different usage and content policies. information between authoritative and non-authoritative parties
authoring and signing the Rich Call Data for support of different
usage and content policies.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2020. This Internet-Draft will expire on May 6, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 26 skipping to change at page 2, line 26
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of the use of the Rich Call Data PASSporT extension 4 3. Overview of the use of the Rich Call Data PASSporT extension 4
4. Overview of Rich Call Data integrity . . . . . . . . . . . . 5 4. Overview of Rich Call Data integrity . . . . . . . . . . . . 5
5. PASSporT Claims . . . . . . . . . . . . . . . . . . . . . . . 5 5. PASSporT Claims . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. PASSporT "rcd" Claim . . . . . . . . . . . . . . . . . . 5 5.1. PASSporT "rcd" Claim . . . . . . . . . . . . . . . . . . 6
5.1.1. "nam" key . . . . . . . . . . . . . . . . . . . . . . 6 5.1.1. "nam" key . . . . . . . . . . . . . . . . . . . . . . 6
5.1.2. "jcd" key . . . . . . . . . . . . . . . . . . . . . . 6 5.1.2. "jcd" key . . . . . . . . . . . . . . . . . . . . . . 6
5.1.3. "jcl" key . . . . . . . . . . . . . . . . . . . . . . 6 5.1.3. "jcl" key . . . . . . . . . . . . . . . . . . . . . . 6
5.1.4. "rcdi" RCD integrity Claim . . . . . . . . . . . . . 6 5.1.4. "rcdi" RCD integrity Claim . . . . . . . . . . . . . 7
5.1.5. Creation of the "rcd" digest . . . . . . . . . . . . 7 5.1.5. Creation of the "rcd" digest . . . . . . . . . . . . 7
5.1.6. JWT Constraint for "rcdi" claim . . . . . . . . . . . 8 5.1.6. JWT Constraint for "rcdi" claim . . . . . . . . . . . 9
5.2. PASSporT "crn" claim - Call Reason . . . . . . . . . . . 9 5.2. PASSporT "crn" claim - Call Reason . . . . . . . . . . . 9
5.2.1. JWT Constraint for "cdn" claim . . . . . . . . . . . 9
6. "rcd" and "crn" Claims Usage . . . . . . . . . . . . . . . . 9 6. "rcd" and "crn" Claims Usage . . . . . . . . . . . . . . . . 9
6.1. Example "rcd" PASSporTs . . . . . . . . . . . . . . . . . 9 6.1. Example "rcd" PASSporTs . . . . . . . . . . . . . . . . . 10
7. Compact form of "rcd" PASSporT . . . . . . . . . . . . . . . 11 7. Compact form of "rcd" PASSporT . . . . . . . . . . . . . . . 12
7.1. Compact form of the "rcd" PASSporT claim . . . . . . . . 11 7.1. Compact form of the "rcd" PASSporT claim . . . . . . . . 12
7.2. Compact form of the "rcdi" PASSporT claim . . . . . . . . 12 7.2. Compact form of the "rcdi" PASSporT claim . . . . . . . . 12
7.3. Compact form of the "crn" PASSporT claim . . . . . . . . 12 7.3. Compact form of the "crn" PASSporT claim . . . . . . . . 12
8. Further Information Associated with Callers . . . . . . . . . 12 8. Further Information Associated with Callers . . . . . . . . . 13
9. Third-Party Uses . . . . . . . . . . . . . . . . . . . . . . 13 9. Third-Party Uses . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Signing as a Third Party . . . . . . . . . . . . . . . . 14 9.1. Signing as a Third Party . . . . . . . . . . . . . . . . 15
10. Levels of Assurance . . . . . . . . . . . . . . . . . . . . . 15 10. Levels of Assurance . . . . . . . . . . . . . . . . . . . . . 15
11. Using "rcd" in SIP . . . . . . . . . . . . . . . . . . . . . 15 11. Using "rcd" in SIP . . . . . . . . . . . . . . . . . . . . . 16
11.1. Authentication Service Behavior . . . . . . . . . . . . 15 11.1. Authentication Service Behavior . . . . . . . . . . . . 16
11.2. Verification Service Behavior . . . . . . . . . . . . . 16 11.2. Verification Service Behavior . . . . . . . . . . . . . 16
12. Using "rcd" as additional claims to other PASSporT extensions 17 12. Using "rcd" as additional claims to other PASSporT extensions 18
12.1. Procedures for applying "rcd" as claims only . . . . . . 17 12.1. Procedures for applying "rcd" as claims only . . . . . . 18
12.2. Example for applying "rcd" as claims only . . . . . . . 17 12.2. Example for applying "rcd" as claims only . . . . . . . 18
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
14.1. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 18 14.1. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 19
14.2. PASSporT Types . . . . . . . . . . . . . . . . . . . . . 19 14.2. PASSporT Types . . . . . . . . . . . . . . . . . . . . . 20
14.3. PASSporT RCD Types . . . . . . . . . . . . . . . . . . . 19 14.3. PASSporT RCD Types . . . . . . . . . . . . . . . . . . . 20
15. Security Considerations . . . . . . . . . . . . . . . . . . . 19 15. Security Considerations . . . . . . . . . . . . . . . . . . . 20
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
16.1. Normative References . . . . . . . . . . . . . . . . . . 20 16.1. Normative References . . . . . . . . . . . . . . . . . . 20
16.2. Informative References . . . . . . . . . . . . . . . . . 21 16.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
PASSporT [RFC8225] is a token format based on JWT [RFC7519] for PASSporT [RFC8225] is a token format based on JWT [RFC7519] for
conveying cryptographically-signed information about the people conveying cryptographically-signed information about the people
involved in personal communications; it is used to convey a signed involved in personal communications; it is used to convey a signed
assertion of the identity of the participants in real-time assertion of the identity of the participants in real-time
communications established via a protocol like SIP [RFC8224]. The communications established via a protocol like SIP [RFC8224]. The
STIR problem statement [RFC7340] declared securing the display name STIR problem statement [RFC7340] declared securing the display name
of callers outside of STIR's initial scope, so baseline STIR provides of callers outside of STIR's initial scope, so baseline STIR provides
no features for caller name. This specification documents an no features for caller name. This specification documents an
optional mechanism for PASSporT and the associated STIR mechanisms optional mechanism for PASSporT and the associated STIR procedures
which extends PASSporT to carry additional elements conveying richer which extend PASSporT objects to carry additional elements conveying
information: information that is intended to be rendered to an end richer information: information that is intended to be rendered to an
user to assist a called party in determining whether to accept or end user to assist a called party in determining whether to accept or
trust incoming communications. This includes the name of the person trust incoming communications. This includes the name of the person
on one side of a communications session, the traditional "Caller ID" on one side of a communications session, the traditional "Caller ID"
of the telephone network, along with related display information that of the telephone network, along with related display information that
would be rendered to the called party during alerting, or potentially would be rendered to the called party during alerting, or potentially
used by an automaton to determine whether and how to alert a called used by an automaton to determine whether and how to alert a called
party. party.
Traditional telephone network signaling protocols have long supported Traditional telephone network signaling protocols have long supported
delivering a 'calling name' from the originating side, though in delivering a 'calling name' from the originating side, though in
practice, the terminating side is often left to derive a name from practice, the terminating side is often left to derive a name from
the calling party number by consulting a local address book or an the calling party number by consulting a local address book or an
external database. SIP similarly can carry a 'display-name' in the external database. SIP similarly can carry this information in a
From header field value from the originating to terminating side, 'display-name' in the From header field value from the originating to
though it is an unsecured field that is not commonly trusted. The terminating side, or alternatively in the Call-Info header field.
same is true of information in the Call-Info header field. However, both are unsecured fields that really can not be trusted in
most interconnected SIP deployments, and therefore is a good starting
point for a framework that utilizes STIR techniques and procedures
for protecting call related information including but not limited to
calling name.
The baseline use case for this document will be extending PASSporT to As such, the baseline use-case for this document will be extending
provide cryptographic protection for the "display-name" field of SIP PASSporT to provide cryptographic protection for the "display-name"
requests as well as further "rich call data" (RCD) about the caller, field of SIP requests as well as further "rich call data" (RCD) about
which includes the contents of the Call-Info header field or other the caller, which includes the contents of the Call-Info header field
data structures that can be added to the PASSporT. This document or other data structures that can be added to the PASSporT. This
furthermore specifies a third-party profile that would allow external document furthermore specifies a third-party profile that would allow
authorities to convey rich information associated with a calling external authorities to convey rich information associated with a
number via a new type of PASSporT. Finally, this document describes calling number via a new type of PASSporT. Finally, this document
how to preserve the integrity of the RCD in scenarios where there may describes how to preserve the integrity of the RCD in scenarios where
be non-authoritative users that may be initiating and signing RCD and there may be non-authoritative users that may be initiating and
therefore a constraint on the RCD data that a PASSporT can attest via signing RCD and therefore a constraint on the RCD data that a
certificate-level controls. PASSporT can attest via certificate-level controls.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in [RFC2119] and [RFC6919]. described in [RFC2119] and [RFC6919].
3. Overview of the use of the Rich Call Data PASSporT extension 3. Overview of the use of the Rich Call Data PASSporT extension
The main intended use of the signing of Rich Call Data (RCD) using The main intended use of the signing of Rich Call Data (RCD) using
STIR [RFC8224] and as a PASSporT extension [RFC8225] is from an STIR [RFC8224] and as a PASSporT extension [RFC8225] is from an
entity that is associated with the originated with the call. Either entity that is associated with the origination of a call. Either
the caller themselves if they are authoritative, or a service directly the caller themselves, if they are authoritative, or a
provider, or a third-party service may be authoritative over the rich service provider or third-party service that may be authoritative
call data on behalf of the caller or service provider representing over the rich call data on behalf of the caller.
the caller.
The RCD described in this document is of two main categories. The The RCD described in this document is of two main categories. The
first data is a more traditional set of info about a caller first data is a more traditional set of info about a caller
associated with "display-name" in SIP [RFC3261] and typically is the associated with "display-name" in SIP [RFC3261] and typically is the
calling name that is a textual description of the caller. The second calling name that is a textual description of the caller. The second
data is a set of RCD that is defined as part of the jCard definitions data is a set of RCD that is defined as part of the jCard definitions
or extensions to that data. [I-D.wendt-sipcore-callinfo-rcd] or extensions to that data. [I-D.ietf-sipcore-callinfo-rcd]
describes the use of jCard as RCD with the "jcard" Call-Info purpose describes the optional use of jCard in Call-Info header field as RCD
token. Either or both of these two types of data can be incorporated with the "jcard" Call-Info purpose token. Either or both of these
into a "rcd" claim defined in this document. two types of data can be incorporated into a "rcd" claim defined in
this document.
Additionally, [I-D.wendt-sipcore-callinfo-rcd] also describes a Additionally, [I-D.ietf-sipcore-callinfo-rcd] also describes a
"reason" parameter intended for description of the intent or reason "reason" parameter intended for description of the intent or reason
for a particular call. A new claim "crn" for call reason can contain for a particular call. A new claim "crn", or call reason, can
the string or object that describes the intent of the call. This contain the string or object that describes the intent of the call.
claim is intentionally kept separate from the "rcd" claim because it This claim is intentionally kept separate from the "rcd" claim
is envisioned that reason will often change on a more frequent, per because it is envisioned that call reason is not the same as
call, type of basis and would not fit the "rcdi" claim and other information associated with the caller and may change on a more
integrity methods tied to the certificate and identity of the caller. frequent, per call, type of basis.
In addition to the type of RCD that can be signed, there are three In addition to the type of RCD that can be signed, there are three
normative modes of use of the signing of Rich Call Data (RCD). The modes of use of the signing of Rich Call Data (RCD). The first and
first and simplest mode is exclusively for when RCD content is simplest mode is exclusively for when all RCD content is directly
directly included as part of the claims (i.e. no URIs are included in included as part of the claims (i.e. no URIs are included in the
the content). In this mode the set of claims is signed via standard content). In this mode the set of claims is signed via standard
PASSporT [RFC8225] and SIP identity header [RFC8224] procedures. The PASSporT [RFC8225] and SIP identity header [RFC8224] procedures. The
second mode is an extension of the first where a "rcd" claim is second mode is an extension of the first where a "rcd" claim is
included and the content MAY or MAY NOT include a URI identifying included and the content includes a URI identifying external
external resources. In this mode, a "rcdi" integrity claim MUST be resources. In this mode, a "rcdi" integrity claim MUST be included.
included. This integrity claim is defined in this document and This integrity claim is defined later in this document and provides a
provides a digest of the content so that, particularly for the case digest of the content so that, particularly for the case where there
where there is URI references in the RCD, the content of that RCD can is URI references in the RCD, the content of that RCD can be
be comprehensively validated that it was received as intended by the comprehensively validated that it was received as intended by the
signer of the PASSporT. The third mode is an extension to both the signer of the PASSporT. The third mode is an extension to both the
first and second modes and incorporates the ability to include the first and second modes and incorporates the ability to include the
digest of the integrity claim as a required value in the certificate digest of the integrity claim as a required value, using JWT
used to create the PASSporT digital signature. This mode allows for Constraints as defined in [RFC8226], in the certificate used to
cases where there is a different authoritative entity responsible for create the PASSporT digital signature. This mode allows for cases
the content of the RCD, separate from the signer of the PASSporT where there is a different authoritative entity responsible for the
itself allowing the ability to have policy around the content and content of the RCD, separate from the signer of the PASSporT itself
potential review or pre-determination of allowed RCD content. allowing the ability to have policy around the content and potential
review or pre-determination of allowed RCD content.
More generally, either of the claims defined in this or future
specifications content can be protected by the authoritative
certificate creators by inclusion in the [RFC8226] defined
certificate's JWT Constraints.
4. Overview of Rich Call Data integrity 4. Overview of Rich Call Data integrity
When incorporating call data that represents a user, even in When incorporating call data that represents a user, even in
traditional calling name services today, often there is policy and traditional calling name services today, often there is policy and
restrictions around what data is allowed to be used. Whether restrictions around what data is allowed to be used. Whether
preventing offensive language or icons or enforcing uniqueness or preventing offensive language or icons or enforcing uniqueness,
whatever potential policy either via regulatory rules, a customer potential copyright violations or other policy enforcement, there
service agreements, or an enterprise brand consistency there may be will likely be the desire to pre-certify the specific use of rich
the desire to pre-certify the specific use of rich data. This call data. This document defines a mechanism that allows for an
document defines a mechanism that allows for an indirect party that indirect party that controls the policy to approve or certify the
controls the policy to approve or certify the content, create a content, create a cryptographic digest that can be used to validate
cryptographic digest that can be used to validate that data and that data and applies a constraint in the certificate to allow the
applies a constraint in the certificate to allow the recipient and recipient and verifier to validate that the specific content of the
verifier to validate that the specific content of the RCD is as RCD is as intended at its creation and approval or certification.
intended at its creation and approval or certification.
The integrity mechanism is a process of generating a sufficiently The integrity mechanism is a process of generating a sufficiently
strong cryptographic digest for both the "rcd" claim contents (e.g. strong cryptographic digest for both the "rcd" claim contents (e.g.
"nam" and "jcd") defined below and the resources defined by one or "nam" and "jcd") defined below and the resources defined by one or
more globally unique HTTPS URLs referenced by the contents (e.g. an more globally unique HTTPS URLs referenced by the contents (e.g. an
image file referenced by "jcd"). This mechanism is inspired and image file referenced by "jcd"). This mechanism is inspired and
based on the W3C Subresource Integrity specification based on the W3C Subresource Integrity specification
(http://www.w3.org/TR/SRI/). This mechanism additionally defines the (http://www.w3.org/TR/SRI/). This mechanism additionally defines the
ability to constrain the digest and RCD integrity mechanism to be ability to constrain the digest and RCD integrity mechanism to be
mandatory without modification using JWT Constraints defined in mandatory without modification using JWT Constraints defined in
skipping to change at page 6, line 22 skipping to change at page 6, line 31
request, or a similar field in other PASSporT using protocols. This request, or a similar field in other PASSporT using protocols. This
key MUST be included once and MUST be included as part of the "rcd" key MUST be included once and MUST be included as part of the "rcd"
claim value JSON object. If there is no string associated with a claim value JSON object. If there is no string associated with a
display name, the claim value SHOULD then be an empty string. display name, the claim value SHOULD then be an empty string.
5.1.2. "jcd" key 5.1.2. "jcd" key
The "jcd" key value is defined to contain a value of a jCard The "jcd" key value is defined to contain a value of a jCard
[RFC7095] JSON object. This jCard object is intended to represent [RFC7095] JSON object. This jCard object is intended to represent
and derives from the Call-Info header field value defined in and derives from the Call-Info header field value defined in
[I-D.wendt-sipcore-callinfo-rcd] with a type of "jcard". As also [I-D.ietf-sipcore-callinfo-rcd] with a type of "jcard". As also
defined in [I-D.wendt-sipcore-callinfo-rcd], format of the jCard and defined in [I-D.ietf-sipcore-callinfo-rcd], format of the jCard and
properties used should follow the normative usage and formatting properties used should follow the normative usage and formatting
rules and procedures. It is an extensible object where the calling rules and procedures. It is an extensible object where the calling
party can provide both the standard types of information defined in party can provide both the standard types of information defined in
jCard or can use the built-in extensibility of the jCard jCard or can use the built-in extensibility of the jCard
specification to add additional information. The "jcd" is optional. specification to add additional information. The "jcd" is optional.
If included, this key MUST only be included once in the "rcd" JSON If included, this key MUST only be included once in the "rcd" JSON
object and SHOULD NOT be included if there is a "jcl" key included. object and SHOULD NOT be included if there is a "jcl" key included.
The "jcd" and "jcl" keys should be mutually exclusive. The "jcd" and "jcl" keys should be mutually exclusive.
Note: even though we refer to [I-D.ietf-sipcore-callinfo-rcd] as the
definition of the jcard properties for usage in a "rcd" PASSporT,
other protocols can be adapted for use of "jcd" (or similarly "jcl"
below) key beyond SIP and Call-Info.
5.1.3. "jcl" key 5.1.3. "jcl" key
The "jcl" key value is defined to contain a HTTPS URL that refers the The "jcl" key value is defined to contain a HTTPS URL that refers the
recipient to a jCard [RFC7095] JSON object hosted on a HTTPS enabled recipient to a jCard [RFC7095] JSON object hosted on a HTTPS enabled
web server. This link may derive from the Call-Info header field web server. This link may derive from the Call-Info header field
value defined in [I-D.wendt-sipcore-callinfo-rcd] with a type of value defined in [I-D.ietf-sipcore-callinfo-rcd] with a type of
"jcard". As also defined in [I-D.wendt-sipcore-callinfo-rcd], format "jcard". As also defined in [I-D.ietf-sipcore-callinfo-rcd], format
of the jCard and properties used should follow the normative usage of the jCard and properties used should follow the normative usage
and formatting rules and procedures. The "jcl" key is optional. If and formatting rules and procedures. The "jcl" key is optional. If
included, this key MUST only be included once in the "rcd" JSON included, this key MUST only be included once in the "rcd" JSON
object and SHOULD NOT be included if there is a "jcd" key included. object and MUST NOT be included if there is a "jcd" key included.
The "jcd" and "jcl" keys should be mutually exclusive. The "jcd" and "jcl" keys MUST be used mutually exclusively.
5.1.4. "rcdi" RCD integrity Claim 5.1.4. "rcdi" RCD integrity Claim
The "rcdi" claim is an optional claim that SHOULD be included if the The "rcdi" claim is an optional claim that SHOULD be included if the
application requires integrity to be applied to the content of the application requires integrity to be applied to the content of the
"rcd" claim and if included MUST be included only once with a "rcd" claim and if included MUST be included only once with a
corresponding "rcd" claim. The value of the "rcdi" key pair should corresponding "rcd" claim. The value of the "rcdi" key pair should
contain a string that is defined as follows. contain a string that is defined as follows.
The first part of the string should define the crypto algorithm used The first part of the string should define the crypto algorithm used
skipping to change at page 7, line 22 skipping to change at page 7, line 35
additional algorithms, but MUST NOT support known weak algorithms additional algorithms, but MUST NOT support known weak algorithms
such as MD5 or SHA-1. In the future, the list of algorithms may re- such as MD5 or SHA-1. In the future, the list of algorithms may re-
evaluated based on security best practices. The algorithms MUST be evaluated based on security best practices. The algorithms MUST be
represented in the text by "sha256", "sha384", or "sha512". The represented in the text by "sha256", "sha384", or "sha512". The
character following the algorithm string MUST be a minus character, character following the algorithm string MUST be a minus character,
"-". The subsequent characters MUST be the base64 encoded digest of "-". The subsequent characters MUST be the base64 encoded digest of
a canonicalized and concatenated string based on the "rcd" claim and a canonicalized and concatenated string based on the "rcd" claim and
the URLs contained in the claim. The details of the creation of this the URLs contained in the claim. The details of the creation of this
string are defined in the next section. string are defined in the next section.
Example: Example:
"rcdi" : "sha256-H8BRh8j48O9oYatfu5AZzq6A9RINQZngK7T62em8MUt1FLm52t+eX6xO" "rcdi" : "sha256-H8BRh8j48O9oYatfu5AZzq6A9RINQZngK7T62em8MUt1FLm52"
5.1.5. Creation of the "rcd" digest 5.1.5. Creation of the "rcd" digest
In order to facilitate proper verification of the digest and whether In order to facilitate proper verification of the digest and whether
the "rcd" content was modified, the input to the digest must be the "rcd" content was modified, the input to the digest must be
completely deterministic at three points in the process. First, at completely deterministic at three points in the process. First, at
the certification point where the content is evaluated to conform to the certification point where the content is evaluated to conform to
the application policy and the JWT Claim Constraints is applied to the application policy and the JWT Claim Constraints is applied to
the certificate containing the digest. Second, when the call is the certificate containing the digest. Second, when the call is
signed at the Authentication Service, there may be a local policy to signed at the Authentication Service, there may be a local policy to
skipping to change at page 9, line 13 skipping to change at page 9, line 28
to the created "rcdi" claim value string. to the created "rcdi" claim value string.
The "permitedValues" for the "rcdi" claim may contain multiple The "permitedValues" for the "rcdi" claim may contain multiple
entries, to support the case where the certificate holder is entries, to support the case where the certificate holder is
authorized to use different sets of rich call data. authorized to use different sets of rich call data.
5.2. PASSporT "crn" claim - Call Reason 5.2. PASSporT "crn" claim - Call Reason
This specification defines a new JSON Web Token claim for "crn", Call This specification defines a new JSON Web Token claim for "crn", Call
Reason, the value of which is a single string or object that can Reason, the value of which is a single string or object that can
contains information as defined in [I-D.wendt-sipcore-callinfo-rcd] contains information as defined in [I-D.ietf-sipcore-callinfo-rcd]
corresponding to the "reason" parameter for the Call-Info header. corresponding to the "reason" parameter for the Call-Info header.
This claim is optional. This claim is optional.
Example "crn" claim with "rcd": Example "crn" claim with "rcd":
"rcd": { "nam" : "James Bond", "rcd": { "nam" : "James Bond",
"jcl" : "https://example.org/james_bond.json" "jcl" : "https://example.org/james_bond.json"
}, },
"crn" : "For your ears only" "crn" : "For your ears only"
5.2.1. JWT Constraint for "cdn" claim
The integrity of the "crn" claim can optionally be protected by the
authoritative certificate creator using JWT Constraints in the
certificate.
6. "rcd" and "crn" Claims Usage 6. "rcd" and "crn" Claims Usage
Either the "rcd" or "crn" claim may appear in any PASSporT claims Either the "rcd" or "crn" claim may appear in any PASSporT claims
object as an optional element. The creator of a PASSporT MAY also object as an optional element. The creator of a PASSporT MAY also
add a "ppt" value of "rcd" to the header of a PASSporT as well, in add a "ppt" value of "rcd" to the header of a PASSporT as well, in
which case the PASSporT claims MUST contain either a "rcd" or "crn" which case the PASSporT claims MUST contain either a "rcd" or "crn"
claim, and any entities verifying the PASSporT object will be claim, and any entities verifying the PASSporT object will be
required to understand the "ppt" extension in order to process the required to understand the "ppt" extension in order to process the
PASSporT in question. A PASSporT header with the "ppt" included will PASSporT in question. A PASSporT header with the "ppt" included will
look as follows: look as follows:
skipping to change at page 10, line 13 skipping to change at page 10, line 33
line breaks for readability only). line breaks for readability only).
{ "orig":{"tn":"12025551000"}, { "orig":{"tn":"12025551000"},
"dest":{"tn":"12025551001"}, "dest":{"tn":"12025551001"},
"iat":1443208345, "iat":1443208345,
"rcd":{"nam":"James Bond"} } "rcd":{"nam":"James Bond"} }
An example of a "nam" only PASSporT claims object with an "rcdi" An example of a "nam" only PASSporT claims object with an "rcdi"
claim is shown next (with line breaks for readability only). claim is shown next (with line breaks for readability only).
{ "orig":{"tn":"12025551000"}, { "orig":{"tn":"12025551000"},
"dest":{"tn":"12025551001"}, "dest":{"tn":"12025551001"},
"iat":1443208345, "iat":1443208345,
"rcd":{"nam":"James Bond"} "rcd":{"nam":"James Bond"}
"rcdi":"sha256-H8BRh8j48O9oYatfu5AZzq6A9R6dQZngK7T62em8MUt1FLm52t+eX6xO" "rcdi":"sha256-H8BRh8j48O9oYatfu5AZzq6A9R6dQZngK7T62em8MUt1FLm52"
} }
An example of a PASSporT claims object that includes the "jcd" which An example of a PASSporT claims object that includes the "jcd" which
is optional, but will also include the mandatory "nam" object is is optional, but will also include the mandatory "nam" object is
shown next (with line breaks for readability only). shown next (with line breaks for readability only).
{ "orig":{"tn":"12025551000"}, { "orig":{"tn":"12025551000"},
"dest":{"tn":"12155551001"}, "dest":{"tn":"12155551001"},
"iat":1443208345, "iat":1443208345,
"rcd":{"nam":"James Bond","jcd":["vcard",[["version",{},"text","4.0"], "rcd":{"nam":"James Bond","jcd":["vcard",[["version",{},"text",
["fn",{},"text", "James Bond"], "4.0"],
["n",{},"text",["Bond","James","","","Mr."]], ["fn",{},"text", "James Bond"],
["adr",{"type":"work"},"text", ["n",{},"text",["Bond","James","","","Mr."]],
["","","3100 Massachusetts Avenue NW","Washington","DC","20008","USA"] ["adr",{"type":"work"},"text",
], ["","","3100 Massachusetts Avenue NW","Washington","DC",
["email",{},"text","007@mi6-hq.com"], "20008","USA"]
["tel",{"type":["voice","text","cell"],"pref":"1"},"uri", ],
"tel:+1-202-555-1000"], ["email",{},"text","007@mi6-hq.com"],
["tel",{"type":["fax"]},"uri","tel:+1-202-555-1001"], ["tel",{"type":["voice","text","cell"],"pref":"1"},"uri",
["bday",{},"date","19241116"], "tel:+1-202-555-1000"],
["logo",{},"uri", ["tel",{"type":["fax"]},"uri","tel:+1-202-555-1001"],
"https://upload.wikimedia.org/wikipedia/en/c/c5/Fleming007impression.jpg" ["bday",{},"date","19241116"],
]]]}} ["logo",{},"uri",
"https://upload.wikimedia.org/wikipedia/en/c/c5
/Fleming007impression.jpg"
]]]}}
In an example PASSporT where a jCard is linked via HTTPS URL and In an example PASSporT where a jCard is linked via HTTPS URL and
"jcl" a jCard file served at a particular URL will be created. "jcl" a jCard file served at a particular URL will be created.
An example jCard JSON file is shown as follows: An example jCard JSON file is shown as follows:
["vcard", ["vcard",
[ [
["version", {}, "text", "4.0"], ["version", {}, "text", "4.0"],
["fn", {}, "text", "James Bond"], ["fn", {}, "text", "James Bond"],
["n", {}, "text", ["Bond", "James", "", "", "Mr."]], ["n", {}, "text", ["Bond", "James", "", "", "Mr."]],
["adr", {"type":"work"}, "text", ["adr", {"type":"work"}, "text",
["", "", "3100 Massachusetts Avenue NW", "Washington", "DC", "20008", ["", "", "3100 Massachusetts Avenue NW", "Washington", "DC",
"USA"] "20008", "USA"]
], ],
["email", {}, "text", "007@mi6-hq.com"], ["email", {}, "text", "007@mi6-hq.com"],
["tel", { "type": ["voice", "text", "cell"], "pref": "1" }, "uri", ["tel", { "type": ["voice", "text", "cell"], "pref": "1" },
"tel:+1-202-555-1000"], "uri", "tel:+1-202-555-1000"],
["tel", { "type": ["fax"] }, "uri", "tel:+1-202-555-1001"], ["tel", { "type": ["fax"] }, "uri", "tel:+1-202-555-1001"],
["bday", {}, "date", "19241116"] ["bday", {}, "date", "19241116"]
["logo", {}, "uri", ["logo", {}, "uri",
"https://upload.wikimedia.org/wikipedia/en/c/c5/Fleming007impression.jpg"] "https://upload.wikimedia.org/wikipedia/en/c/c5
] /Fleming007impression.jpg"]
] ]
]
If that jCard is hosted at the example address of If that jCard is hosted at the example address of
"https://example.org/james_bond.json", the corresponding PASSporT "https://example.org/james_bond.json", the corresponding PASSporT
claims object would be as follows (with line breaks for readability claims object would be as follows (with line breaks for readability
only): only):
{ "orig":{"tn":"12025551000"}, { "orig":{"tn":"12025551000"},
"dest":{"tn":"12155551001"}, "dest":{"tn":"12155551001"},
"iat":1443208345, "iat":1443208345,
"rcd":{"nam":"James Bond","jcl":"https://example.org/james_bond.json"} "rcd":{"nam":"James Bond","jcl":"https://example.org/jb.json"}
} }
If we were to add a "rcdi" integrity claim to the last example, the If we were to add a "rcdi" integrity claim to the last example, the
corresponding PASSporT claims object would be as follows (with line corresponding PASSporT claims object would be as follows (with line
breaks for readability only): breaks for readability only):
{ "orig":{"tn":"12025551000"}, { "orig":{"tn":"12025551000"},
"dest":{"tn":"12155551001"}, "dest":{"tn":"12155551001"},
"iat":1443208345, "iat":1443208345,
"rcd":{"nam":"James Bond","jcl":"https://example.org/james_bond.json"} "rcd":{"nam":"James Bond","jcl":"https://example.org/jb.json"}
"rcdi":"sha256-H8BRh8j48O9oYatfu5AZzq6A9R6dQZngK7T62em8MUt1FLm52t+eX6xO" "rcdi":"sha256-H8BRh8j48O9oYatfu5AZzq6A9R6dQZngK7T62em8MUt1FLm"
} }
7. Compact form of "rcd" PASSporT 7. Compact form of "rcd" PASSporT
7.1. Compact form of the "rcd" PASSporT claim 7.1. Compact form of the "rcd" PASSporT claim
Compact form of an "rcd" PASSporT claim has some restrictions but Compact form of an "rcd" PASSporT claim has some restrictions but
mainly follows standard PASSporT compact form procedures. For re- mainly follows standard PASSporT compact form procedures. For re-
construction of the "nam" claim the string for the display-name in construction of the "nam" claim the string for the display-name in
the From header field. For re-construction of the "jcl", the Call- the From header field. For re-construction of the "jcl", the Call-
Info header as with purpose "jcard" defined in Info header as with purpose "jcard" defined in
[I-D.wendt-sipcore-callinfo-rcd] MUST be used. "jcd" claim MAY NOT be [I-D.ietf-sipcore-callinfo-rcd] MUST be used. "jcd" claim MAY NOT be
used as part of compact form. used as part of compact form.
7.2. Compact form of the "rcdi" PASSporT claim 7.2. Compact form of the "rcdi" PASSporT claim
Compact form of an "rcdi" PASSPorT claim shall be re-constructed Compact form of an "rcdi" PASSPorT claim shall be re-constructed
following the same "rcdi" defined digest procedures in this document following the same "rcdi" defined digest procedures in this document
of all of the content and referenced URI content once downloaded. of all of the content and referenced URI content once downloaded.
7.3. Compact form of the "crn" PASSporT claim 7.3. Compact form of the "crn" PASSporT claim
Compact form of a "crn" PASSporT claim shall be re-constructed using Compact form of a "crn" PASSporT claim shall be re-constructed using
the "reason" parameter of a Call-Info header as defined by the "reason" parameter of a Call-Info header as defined by
[I-D.wendt-sipcore-callinfo-rcd]. [I-D.ietf-sipcore-callinfo-rcd].
8. Further Information Associated with Callers 8. Further Information Associated with Callers
Beyond naming information and the information that can be contained Beyond naming information and the information that can be contained
in a jCard [RFC7095] object, there may be additional human-readable in a jCard [RFC7095] object, there may be additional human-readable
information about the calling party that should be rendered to the information about the calling party that should be rendered to the
end user in order to help the called party decide whether or not to end user in order to help the called party decide whether or not to
pick up the phone. This is not limited to information about the pick up the phone. This is not limited to information about the
caller, but includes information about the call itself, which may caller, but includes information about the call itself, which may
derive from analytics that determine based on call patterns or derive from analytics that determine based on call patterns or
skipping to change at page 13, line 17 skipping to change at page 13, line 48
While in the traditional telephone network, the business relationship While in the traditional telephone network, the business relationship
between calling customers and their telephone service providers is between calling customers and their telephone service providers is
the ultimate root of information about a calling party's name, some the ultimate root of information about a calling party's name, some
other forms of data like crowdsourced reputation scores might derive other forms of data like crowdsourced reputation scores might derive
from third parties. It is more likely that when those elements are from third parties. It is more likely that when those elements are
present, they will be in a third-party "rcd" PASSporT. present, they will be in a third-party "rcd" PASSporT.
9. Third-Party Uses 9. Third-Party Uses
While rich data about the call can be provided by an originating While rich data about the call can be provided by an originating
authentication service, the terminating side or an intermediary in authentication service, an intermediary in the call path could also
the call path could also acquire rich call data by querying a third- acquire rich call data by querying a third-party service. Such a
party service. Such a service effectively acts as a STIR service effectively acts as a STIR Authentication Service, generating
Authentication Service, generating its own PASSporT, and that its own PASSporT, and that PASSporT could be attached to a SIP call
PASSporT could be attached to a SIP call by either the originating or by either the originating or terminating side. This third-party
terminating side. This third-party PASSporT attests information PASSporT attests information about the calling number, rather than
about the calling number, rather than the call or caller itself, and the call or caller itself, and as such its RCD MUST NOT be used when
as such its RCD MUST NOT be used when a call lacks a first-party a call lacks a first-party PASSporT that assures verification
PASSporT that assures verification services that the calling party services that the calling party number is not spoofed. It is
number is not spoofed. It is intended to be used in cases when the intended to be used in cases when the originating side does not
originating side does not supply a display-name for the caller, so supply a display-name for the caller, so instead some entity in the
instead some entity in the call path invokes a third-party service to call path invokes a third-party service to provide rich caller data
provide rich caller data for a call. for a call.
In telephone operations today, a third-party information service is In telephone operations today, a third-party information service is
commonly queried with the calling party's number in order to learn commonly queried with the calling party's number in order to learn
the name of the calling party, and potentially other helpful the name of the calling party, and potentially other helpful
information could also be passed over that interface. The value of information could also be passed over that interface. The value of
using a PASSporT to convey this information from third parties lies using a PASSporT to convey this information from third parties lies
largely in the preservation of the original authority's signature largely in the preservation of the original authority's signature
over the data, and the potential for the PASSporT to be conveyed from over the data, and the potential for the PASSporT to be conveyed from
intermediaries to endpoint devices. Effectively, these use cases intermediaries to endpoint devices. Effectively, these use cases
form a sub-case of out-of-band [I-D.ietf-stir-oob] use cases. The form a sub-case of out-of-band [I-D.ietf-stir-oob] use cases. The
skipping to change at page 14, line 32 skipping to change at page 15, line 15
9.1. Signing as a Third Party 9.1. Signing as a Third Party
A third-party PASSporT, which contains such an "iss" element, will A third-party PASSporT, which contains such an "iss" element, will
necessarily be signed with credentials that do not have authority necessarily be signed with credentials that do not have authority
over the identity that appears in the "orig" element of the PASSporT over the identity that appears in the "orig" element of the PASSporT
claims. The presence of "iss" signifies that a different category of claims. The presence of "iss" signifies that a different category of
credential is being used to sign a PASSporT than the [RFC8226] credential is being used to sign a PASSporT than the [RFC8226]
certificates used to sign STIR calls; it is instead a certificate certificates used to sign STIR calls; it is instead a certificate
that identifies the source of the "rcd" data. How those credentials that identifies the source of the "rcd" data. How those credentials
are issued and managed is outside the scope of this specification; are issued and managed is outside the scope of this specification;
the value of "iss" however MUST reflect the Organization (O) field of the value of "iss" however MUST reflect the Subject Name field of the
the certificate used to sign a third-party PASSporT. Relying parties certificate used to sign a third-party PASSporT. Relying parties in
in STIR have always been left to make their own authorization STIR have always been left to make their own authorization decisions
decisions about whether or not the trust the signers of PASSporTs, about whether or not the trust the signers of PASSporTs, and in the
and in the third-party case, where an entity has explicitly queried a third-party case, where an entity has explicitly queried a service to
service to acquire the PASSporT object, it may be some external trust acquire the PASSporT object, it may be some external trust or
or business relationship that induces the relying party to trust a business relationship that induces the relying party to trust a
PASSporT. PASSporT.
An example of a Third Party issued PASSporT claims object is as An example of a Third Party issued PASSporT claims object is as
follows. follows.
{ "orig":{"tn":"12025551000"}, { "orig":{"tn":"12025551000"},
"dest":{"tn":"12025551001"}, "dest":{"tn":"12025551001"},
"iat":1443208345, "iat":1443208345,
"iss":"Example, Inc.", "iss":"Example, Inc.",
"rcd":{"nam":"James Bond"} } "rcd":{"nam":"James Bond"} }
skipping to change at page 15, line 20 skipping to change at page 15, line 48
party cases, this admits of some complexity: the Communications party cases, this admits of some complexity: the Communications
Service Provider (CSP) to which a number was assigned might in turn Service Provider (CSP) to which a number was assigned might in turn
delegate the number to a reseller, who would then sell the number to delegate the number to a reseller, who would then sell the number to
an enterprise, in which case the CSP might have little insight into an enterprise, in which case the CSP might have little insight into
the caller's name. In third party cases, a caller's name could the caller's name. In third party cases, a caller's name could
derive from any number of data sources, on a spectrum between public derive from any number of data sources, on a spectrum between public
data scraped from web searches to a direct business relationship to data scraped from web searches to a direct business relationship to
the caller. As multiple PASSporTs can be associated with the same the caller. As multiple PASSporTs can be associated with the same
call, potentially a verification service could receive attestations call, potentially a verification service could receive attestations
of the caller name from multiple sources, which have different levels of the caller name from multiple sources, which have different levels
of granularity or accuracy. of granularity or accuracy. Therefore, PASSporTs that carry "rcd"
data SHOULD also carry an indication of the relationship of the
Therefore PASSporTs that carry "rcd" data SHOULD also carry an generator of the PASSporT to the caller. As stated in the previous
indication of the relationship of the generator of the PASSporT to section, the use of "iss" MUST reflect the Organization (O) field of
the caller. [TBD claim - take from SHAKEN?] the certificate used to sign a third-party PASSporT to represent that
relationship.
11. Using "rcd" in SIP 11. Using "rcd" in SIP
This section specifies SIP-specific usage for the "rcd" claim in This section specifies SIP-specific usage for the "rcd" claim in
PASSporT, and in the SIP Identity header field value. Other using PASSporT, and in the SIP Identity header field value. Other using
protocols of PASSporT may define their own usages for the "rcd" protocols of PASSporT may define their own usages for the "rcd"
claim. claim.
11.1. Authentication Service Behavior 11.1. Authentication Service Behavior
An authentication service creating a PASSporT containing a "rcd" An authentication service creating a PASSporT containing a "rcd"
claim MAY include a "ppt" for "rcd" or not. Third-party claim MAY include a "ppt" for "rcd" or not. Third-party
authentication services following the behavior in Section 9.1 MUST authentication services following the behavior in Section 9.1 MUST
include a "ppt" of "rcd". If "ppt" does contain a "rcd", then any include a "ppt" of "rcd". If "ppt" does contain a "rcd", then any
SIP authentication services MUST add a "ppt" parameter to the SIP authentication services MUST add a "ppt" parameter to the
Identity header containing that PASSporT with a value of "rcd". The Identity header containing that PASSporT with a value of "rcd". The
resulting Identity header might look as follows: resulting Identity header might look as follows:
Identity: "sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo Identity: "sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9
eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp dlxkWzoeU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0
pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs="; \ Lu5csIppPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs="; \
info=<https://biloxi.example.org/biloxi.cer>;alg=ES256;ppt="rcd" info=<https://biloxi.example.org/biloxi.cer>;alg=ES256;ppt="rcd"
This specification assumes that by default, a SIP authentication This specification assumes that by default, a SIP authentication
service will derive the value of "rcd", specifically only for the service will derive the value of "rcd", specifically only for the
"nam" key value, from the display-name component of the From header "nam" key value, from the display-name component of the From header
field value of the request, alternatively for some calls this may field value of the request, alternatively for some calls this may
come from the P-Asserted-ID header. It is however a matter of come from the P-Asserted-ID header. It is however a matter of
authentication service policy to decide how it populates the value of authentication service policy to decide how it populates the value of
"rcd" and "nam" key, which MAY also derive from other fields in the "rcd" and "nam" key, which MAY also derive from other fields in the
request, from customer profile data, or from access to external request, from customer profile data, or from access to external
services. If the authentication service generates a PASSporT object services. If the authentication service generates a PASSporT object
skipping to change at page 16, line 19 skipping to change at page 16, line 49
header field display-name value, it MUST use the full form of the header field display-name value, it MUST use the full form of the
PASSporT object in SIP. PASSporT object in SIP.
11.2. Verification Service Behavior 11.2. Verification Service Behavior
[RFC8224] Section 6.2 Step 5 requires that specifications defining [RFC8224] Section 6.2 Step 5 requires that specifications defining
"ppt" values describe any additional verifier behavior. The behavior "ppt" values describe any additional verifier behavior. The behavior
specified for the "ppt" values of "rcd" is as follows. If the specified for the "ppt" values of "rcd" is as follows. If the
PASSporT is in compact form, then the verification service SHOULD PASSporT is in compact form, then the verification service SHOULD
extract the display-name from the From header field value, if any, extract the display-name from the From header field value, if any,
and use that as the value for the "rcd" key when it recomputes the and use that as the value for the "nam" key when it recomputes the
header and claims of the PASSporT object. If the signature validates header and claims of the PASSporT object. Optionally, if there
over the recomputed object, then the verification should be exists a Call-Info header field as defined in
considered successful.
[I-D.ietf-sipcore-callinfo-rcd], the "jcard" value can be derived to
determine the "jcd" key when it recomputes the header and claims of
the PASSporT object. If the signature validates over the recomputed
object, then the verification should be considered successful.
However, if the PASSport is in full form with a "ppt" value of "rcd", However, if the PASSport is in full form with a "ppt" value of "rcd",
then the verification service MUST extract the value associated with then the verification service MUST extract the value associated with
the "rcd" "nam" key in the object. If the signature validates, then the "rcd" "nam" key in the object. If the signature validates, then
the verification service can use the value of the "rcd" "nam" key as the verification service can use the value of the "rcd" "nam" key as
the display name of calling party, which would in turn be rendered to the display name of calling party, which would in turn be rendered to
alerted users or otherwise leveraged in accordance with local policy. alerted users or otherwise leveraged in accordance with local policy.
This will allow SIP networks that convey the display name through a This will allow SIP networks that convey the display name through a
field other than the From header field to interoperate with this field other than the From header field to interoperate with this
specification. specification. Similarly, the "jcd" or linked "jcl" jcard
information and "crn" can be optionally, based on local policy for
devices that support it, used to populate a Call-Info header field
following the format of [I-D.ietf-sipcore-callinfo-rcd].
The third-party "rcd" PASSporT cases presents some new challenges, as The third-party "rcd" PASSporT cases presents some new challenges, as
an attacker could attempt to cut-and-paste such a third-party an attacker could attempt to cut-and-paste such a third-party
PASSporT into a SIP request in an effort to get the terminating user PASSporT into a SIP request in an effort to get the terminating user
agent to render the display name or confidence values it contains to agent to render the display name or confidence values it contains to
a call that should have no such assurance. A third-party "rcd" a call that should have no such assurance. A third-party "rcd"
PASSporT provides no assurance that the calling party number has not PASSporT provides no assurance that the calling party number has not
been spoofed: if it is carried in a SIP request, for example, then been spoofed: if it is carried in a SIP request, for example, then
some other PASSporT in another Identity header field value would have some other PASSporT in another Identity header field value would have
to carry a PASSporT attesting that. A verification service MUST to carry a PASSporT attesting that. A verification service MUST
skipping to change at page 17, line 19 skipping to change at page 18, line 7
The behavior of a SIP UAS upon receiving an INVITE containing a The behavior of a SIP UAS upon receiving an INVITE containing a
PASSporT object with a "rcd" claim will largely remain a matter of PASSporT object with a "rcd" claim will largely remain a matter of
implementation policy. In most cases, implementations would render implementation policy. In most cases, implementations would render
this calling party name information to the user while alerting. Any this calling party name information to the user while alerting. Any
user interface additions to express confidence in the veracity of user interface additions to express confidence in the veracity of
this information are outside the scope of this specification. this information are outside the scope of this specification.
12. Using "rcd" as additional claims to other PASSporT extensions 12. Using "rcd" as additional claims to other PASSporT extensions
Rich Call Data, including, for example, calling name information, is Rich Call Data, including calling name information, for example, is
often data that is additive data to the personal communications often data that is additive data to the personal communications
information defined in the core PASSporT data required to support the information defined in the core PASSporT data required to support the
security properties defined in [RFC8225]. For cases where the entity security properties defined in [RFC8225]. For cases where the entity
that is originating the personal communications and additionally is that is originating the personal communications and additionally is
supporting the authentication service and also is the authority of supporting the authentication service and also is the authority of
the Rich Call Data, rather than creating multiple identity headers the Rich Call Data, rather than creating multiple identity headers
with multiple PASSporT extensions or defining multiple combinations with multiple PASSporT extensions or defining multiple combinations
and permutations of PASSporT extension definitions, the and permutations of PASSporT extension definitions, the
authentication service can alternatively directly add the "rcd" authentication service can alternatively directly add the "rcd"
claims to the PASSporT it is creating, whether it is constructed with claims to the PASSporT it is creating, whether it is constructed with
skipping to change at page 20, line 9 skipping to change at page 20, line 46
information it signs over in a using protocol like SIP is all information it signs over in a using protocol like SIP is all
information that SIP carries in the clear anyway. Transport-level information that SIP carries in the clear anyway. Transport-level
security can hide those SIP fields from eavesdroppers, and the same security can hide those SIP fields from eavesdroppers, and the same
confidentiality mechanisms would protect any PASSporT(s) carried in confidentiality mechanisms would protect any PASSporT(s) carried in
SIP. SIP.
16. References 16. References
16.1. Normative References 16.1. Normative References
[I-D.ietf-sipcore-callinfo-rcd]
Wendt, C. and J. Peterson, "SIP Call-Info Parameters for
Rich Call Data", draft-ietf-sipcore-callinfo-rcd-00 (work
in progress), November 2020.
[I-D.ietf-stir-oob] [I-D.ietf-stir-oob]
Rescorla, E. and J. Peterson, "STIR Out-of-Band Rescorla, E. and J. Peterson, "STIR Out-of-Band
Architecture and Use Cases", draft-ietf-stir-oob-07 (work Architecture and Use Cases", draft-ietf-stir-oob-07 (work
in progress), March 2020. in progress), March 2020.
[I-D.wendt-sipcore-callinfo-rcd]
Wendt, C. and J. Peterson, "SIP Call-Info Parameters for
Rich Call Data", draft-wendt-sipcore-callinfo-rcd-00 (work
in progress), November 2019.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words
for Use in RFCs to Indicate Requirement Levels", RFC 6919, for Use in RFCs to Indicate Requirement Levels", RFC 6919,
DOI 10.17487/RFC6919, April 2013, DOI 10.17487/RFC6919, April 2013,
<https://www.rfc-editor.org/info/rfc6919>. <https://www.rfc-editor.org/info/rfc6919>.
 End of changes. 48 change blocks. 
203 lines changed or deleted 238 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/