< draft-ietf-stir-passport-rcd-14.txt   draft-ietf-stir-passport-rcd-15.txt >
Network Working Group C. Wendt Network Working Group C. Wendt
Internet-Draft Comcast Internet-Draft Somos Inc.
Intended status: Standards Track J. Peterson Intended status: Standards Track J. Peterson
Expires: 28 April 2022 Neustar Inc. Expires: 8 September 2022 Neustar Inc.
25 October 2021 7 March 2022
PASSporT Extension for Rich Call Data PASSporT Extension for Rich Call Data
draft-ietf-stir-passport-rcd-14 draft-ietf-stir-passport-rcd-15
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 meta-data about a call and caller communications, to include rich meta-data about a call and caller
that can be signed and integrity protected, transmitted, and that can be signed and integrity protected, transmitted, and
subsequently rendered to the called party. This framework is subsequently rendered to the called party. This framework is
intended to include and extend caller and call specific information intended to include and extend caller and call specific information
beyond human-readable display name comparable to the "Caller ID" beyond human-readable display name comparable to the "Caller ID"
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 28 April 2022. This Internet-Draft will expire on 8 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised 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 3. Overview of the use of the Rich Call Data PASSporT
extension . . . . . . . . . . . . . . . . . . . . . . . . 4 extension . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview of Rich Call Data Integrity . . . . . . . . . . . . 5 4. Overview of Rich Call Data Integrity . . . . . . . . . . . . 5
5. PASSporT Claim "rcd" Defintion and Usage . . . . . . . . . . 7 5. PASSporT Claim "rcd" Definition and Usage . . . . . . . . . . 7
5.1. PASSporT "rcd" Claim . . . . . . . . . . . . . . . . . . 7 5.1. PASSporT "rcd" Claim . . . . . . . . . . . . . . . . . . 7
5.1.1. "nam" key . . . . . . . . . . . . . . . . . . . . . . 7 5.1.1. "nam" key . . . . . . . . . . . . . . . . . . . . . . 7
5.1.2. "apn" key . . . . . . . . . . . . . . . . . . . . . . 8 5.1.2. "apn" key . . . . . . . . . . . . . . . . . . . . . . 7
5.1.3. "jcd" key . . . . . . . . . . . . . . . . . . . . . . 8 5.1.3. "icn" key . . . . . . . . . . . . . . . . . . . . . . 8
5.1.4. "jcl" key . . . . . . . . . . . . . . . . . . . . . . 9 5.1.4. "jcd" key . . . . . . . . . . . . . . . . . . . . . . 9
6. "rcdi" RCD Integrity Claim Definition and Usage . . . . . . . 9 5.1.5. "jcl" key . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Creation of the "rcd" element digests . . . . . . . . . . 10 6. "rcdi" RCD Integrity Claim Definition and Usage . . . . . . . 10
6.2. JWT Claim Constraints for "rcd" claims only . . . . . . . 13 6.1. Creation of the "rcd" element digests . . . . . . . . . . 11
7. JWT Claim Constraints usage for "rcd" and "rcdi" claims . . . 14 6.1.1. "nam" and "apn" elements . . . . . . . . . . . . . . 11
8. PASSporT "crn" claim - Call Reason Defintion and Usage . . . 15 6.1.2. "icn" elements . . . . . . . . . . . . . . . . . . . 11
8.1. JWT Constraint for "crn" claim . . . . . . . . . . . . . 15 6.1.3. "jcd" elements . . . . . . . . . . . . . . . . . . . 12
9. Rich Call Data Claims Usage Rules . . . . . . . . . . . . . . 15 6.1.4. "jcl" elements . . . . . . . . . . . . . . . . . . . 13
9.1. Verification rules . . . . . . . . . . . . . . . . . . . 16 6.2. JWT Claim Constraints for "rcd" claims only . . . . . . . 14
9.2. Example "rcd" PASSporTs . . . . . . . . . . . . . . . . . 16 7. JWT Claim Constraints usage for "rcd" and "rcdi" claims . . . 15
10. Compact form of "rcd" PASSporT . . . . . . . . . . . . . . . 18 8. PASSporT "crn" claim - Call Reason Definition and Usage . . . 16
10.1. Compact form of the "rcd" PASSporT claim . . . . . . . . 18 8.1. JWT Constraint for "crn" claim . . . . . . . . . . . . . 16
10.2. Compact form of the "rcdi" PASSporT claim . . . . . . . 19 9. Rich Call Data Claims Usage Rules . . . . . . . . . . . . . . 16
10.3. Compact form of the "crn" PASSporT claim . . . . . . . . 19 9.1. "rcd" PASSporT Verification . . . . . . . . . . . . . . . 17
11. Further Information Associated with Callers . . . . . . . . . 19 9.2. "rcdi" Integrity Verification . . . . . . . . . . . . . . 17
12. Third-Party Uses . . . . . . . . . . . . . . . . . . . . . . 20 9.3. Example "rcd" PASSporTs . . . . . . . . . . . . . . . . . 18
12.1. Signing as a Third Party . . . . . . . . . . . . . . . . 21 10. Compact form of "rcd" PASSporT . . . . . . . . . . . . . . . 20
13. Levels of Assurance . . . . . . . . . . . . . . . . . . . . . 22 10.1. Compact form of the "rcd" PASSporT claim . . . . . . . . 20
14. Using "rcd" in SIP . . . . . . . . . . . . . . . . . . . . . 22 10.2. Compact form of the "rcdi" PASSporT claim . . . . . . . 20
14.1. Authentication Service Behavior . . . . . . . . . . . . 22 10.3. Compact form of the "crn" PASSporT claim . . . . . . . . 20
14.2. Verification Service Behavior . . . . . . . . . . . . . 23 11. Further Information Associated with Callers . . . . . . . . . 21
12. Third-Party Uses . . . . . . . . . . . . . . . . . . . . . . 22
15. Using "rcd" as additional claims to other PASSporT 12.1. Signing as a Third Party . . . . . . . . . . . . . . . . 23
extensions . . . . . . . . . . . . . . . . . . . . . . . 24 13. Levels of Assurance . . . . . . . . . . . . . . . . . . . . . 24
15.1. Procedures for applying "rcd" as claims only . . . . . . 25 14. Using "rcd" in SIP . . . . . . . . . . . . . . . . . . . . . 24
15.2. Example for applying "rcd" as claims only . . . . . . . 25 14.1. Authentication Service Behavior . . . . . . . . . . . . 24
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 14.2. Verification Service Behavior . . . . . . . . . . . . . 25
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 15. Using "rcd" and "rcdi" as additional claims to other PASSporT
17.1. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 26 extensions . . . . . . . . . . . . . . . . . . . . . . . 26
17.2. PASSporT Types . . . . . . . . . . . . . . . . . . . . . 27 15.1. Procedures for applying "rcd" as claims only . . . . . . 27
17.3. PASSporT RCD Types . . . . . . . . . . . . . . . . . . . 27 15.2. Example for applying "rcd" as claims only . . . . . . . 27
18. Security Considerations . . . . . . . . . . . . . . . . . . . 27 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
17.1. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 28
17.2. PASSporT Types . . . . . . . . . . . . . . . . . . . . . 29
17.3. PASSporT RCD Types . . . . . . . . . . . . . . . . . . . 29
18. Security Considerations . . . . . . . . . . . . . . . . . . . 29
18.1. The use of JWT Claim Constraints in delegate certificates 18.1. The use of JWT Claim Constraints in delegate certificates
to exclude unauthorized claims . . . . . . . . . . . . . 28 to exclude unauthorized claims . . . . . . . . . . . . . 30
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
19.1. Normative References . . . . . . . . . . . . . . . . . . 28 19.1. Normative References . . . . . . . . . . . . . . . . . . 30
19.2. Informative References . . . . . . . . . . . . . . . . . 30 19.2. Informative References . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
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 parties conveying cryptographically-signed information about the parties
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
skipping to change at page 5, line 4 skipping to change at page 5, line 10
[RFC8225] is for the entity that originates a call, either directly [RFC8225] is for the entity that originates a call, either directly
the caller themselves, if they are authoritative, or a service the caller themselves, if they are authoritative, or a service
provider or third-party service that may be authoritative over the provider or third-party service that may be authoritative over the
rich call data on behalf of the caller. rich call data on behalf of the caller.
The RCD associated with the identity of the calling party described The RCD associated with the identity of the calling party described
in this document is of two main categories. The first data is a more in this document is of two main categories. The first data is a more
traditional set of info about a caller associated with "display-name" traditional set of info about a caller associated with "display-name"
in SIP [RFC3261], typically a textual description of the caller, or in SIP [RFC3261], typically a textual description of the caller, or
alternate presentation numbers often used in From Header field alternate presentation numbers often used in From Header field
[RFC3261] or P-Asserted-ID [RFC3325]. The second category is a set [RFC3261] or P-Asserted-ID [RFC3325]. The second category is a set
of RCD that is defined as part of the jCard definitions or extensions of RCD that is defined as part of the jCard definitions or extensions
to that data. [I-D.ietf-sipcore-callinfo-rcd] describes the optional to that data. [I-D.ietf-sipcore-callinfo-rcd] describes the optional
use of jCard in Call-Info header field as RCD with the "jcard" Call- use of jCard in Call-Info header field as RCD with the "jcard" Call-
Info purpose token. Either or both of these two types of data can be Info purpose token. Either or both of these two types of data can be
incorporated into a "rcd" claim defined in this document. incorporated into an "rcd" claim defined in this document.
Additionally, in relation to the description of the specific Additionally, in relation to the description of the specific
communications event itself (versus the identity description in communications event itself (versus the identity description in
previous paragraph), [I-D.ietf-sipcore-callinfo-rcd] also describes a previous paragraph), [I-D.ietf-sipcore-callinfo-rcd] also describes a
"call-reason" parameter intended for description of the intent or "call-reason" parameter intended for description of the intent or
reason for a particular call. A new PASSporT claim "crn", or call reason for a particular call. A new PASSporT claim "crn", or call
reason, can contain the string or object that describes the intent of reason, can contain the string or object that describes the intent of
the call. This claim is intentionally kept separate from the "rcd" the call. This claim is intentionally kept separate from the "rcd"
claim because it is envisioned that call reason is not the same as claim because it is envisioned that call reason is not the same as
information associated with the caller and may change on a more information associated with the caller and may change on a more
skipping to change at page 6, line 9 skipping to change at page 5, line 48
to approve or certify the content, create a cryptographic digest that to approve or certify the content, create a cryptographic digest that
can be used to validate that data and applies a constraint in the can be used to validate that data and applies a constraint in the
certificate to allow the recipient and verifier to validate that the certificate to allow the recipient and verifier to validate that the
specific content of the RCD is as intended at its creation and specific content of the RCD is as intended at its creation and
approval or certification. approval or certification.
There are two mechanisms that are defined to accomplish that for two There are two mechanisms that are defined to accomplish that for two
distinct categories of purposes. The first of the mechanisms include distinct categories of purposes. The first of the mechanisms include
the definition of an integrity claim. The RCD integrity mechanism is the definition of an integrity claim. The RCD integrity mechanism is
a process of generating a sufficiently strong cryptographic digest a process of generating a sufficiently strong cryptographic digest
for both the "rcd" claim contents (e.g. "nam", "jcd", "jcl") defined for each resource referenced as a claim value or as a value within a
below and the resources defined by one or more globally unique HTTPS claim value by one or more globally unique URIs (e.g., an image file
URLs referenced by the contents (e.g. an image file referenced by referenced by "jcd" or a jCard referenced by "jcl"). This mechanism
"jcd" or a jCard referenced by "jcl"). This mechanism is inspired by is inspired by and based on the W3C Subresource Integrity
and based on the W3C Subresource Integrity specification specification (http://www.w3.org/TR/SRI/). The second of the
(http://www.w3.org/TR/SRI/). The second of the mechanisms uses the mechanisms uses the capability called JWT Claim Constraints, defined
capability called JWT Claim Constraints, defined in [RFC8226] and in [RFC8226] and extended in [I-D.ietf-stir-enhance-rfc8226]. The
extended in [I-D.ietf-stir-enhance-rfc8226]. The JWT Claim JWT Claim Constraints specifically guide the verifier within the
Constraints specifically guide the verifier within the certificate certificate used to sign the PASSporT for the inclusion (or
used to sign the PASSporT for the inclusion (or exclusion) of exclusion) of specific claims and their values, so that the content
specific claims and their values, so that the content intended by the intended by the signer can be verified to be accurate.
signer can be verified to be accurate.
Both of these mechanisms, integrity digests and JWT Claims Both of these mechanisms, integrity digests and JWT Claims
Constraints, can be used together or separately depending on the Constraints, can be used together or separately depending on the
intended purpose. The first category of purpose is whether the rich intended purpose. The first category of purpose is whether the rich
call data conveyed by the RCD passport is pass-by-value or passed-by- call data conveyed by the RCD passport is pass-by-value or passed-by-
reference; i.e., is the information contained in the passport claims reference; i.e., is the information contained in the passport claims
and therefore integrity protected by the passport signature, or is and therefore integrity protected by the passport signature, or is
the information contained in an external resource referenced by a URI the information contained in an external resource referenced by a URI
in the RCD PASSporT. The second category of purpose is whether the in the RCD PASSporT. The second category of purpose is whether the
signer is authoritative or has responsibility for the accuracy of the signer is authoritative or has responsibility for the accuracy of the
skipping to change at page 7, line 4 skipping to change at page 6, line 42
| Non-Auth | 3: JWT Claim Const. | 4: RCD Integ./JWT Claim Const. | | Non-Auth | 3: JWT Claim Const. | 4: RCD Integ./JWT Claim Const. |
+----------+---------------------+--------------------------------+ +----------+---------------------+--------------------------------+
The first and simplest mode is exclusively for when all RCD content The first and simplest mode is exclusively for when all RCD content
is directly included as part of the claims (i.e. no external is directly included as part of the claims (i.e. no external
reference URIs are included in the content) and when the signer is reference URIs are included in the content) and when the signer is
authoritative over the content. In this mode, integrity protection authoritative over the content. In this mode, integrity protection
is not required and the set of claims is simply protected by the is not required and the set of claims is simply protected by the
signature of the standard PASSporT [RFC8225] and SIP identity header signature of the standard PASSporT [RFC8225] and SIP identity header
[RFC8224] procedures. The second mode is an extension of the first [RFC8224] procedures. The second mode is an extension of the first
where the signer is authoritative and a "rcd" claim contents include where the signer is authoritative and an "rcd" claim contents include
a URI identifying external resources. In this mode, an RCD Integrity a URI identifying external resources. In this mode, an RCD Integrity
or "rcdi" claim MUST be included. This integrity claim is defined or "rcdi" claim MUST be included. This integrity claim is defined
later in this document and provides a digest of the "rcd" claim later in this document and provides a digest of the "rcd" claim
content so that, particularly for the case where there are URI content so that, particularly for the case where there are URI
references in the RCD, the content of that RCD can be comprehensively references in the RCD, the content of that RCD can be comprehensively
validated that it was received as intended by the signer of the validated that it was received as intended by the signer of the
PASSporT. PASSporT.
The third and fourth mode cover cases where there is a different The third and fourth mode cover cases where there is a different
authoritative entity responsible for the content of the RCD, separate authoritative entity responsible for the content of the RCD, separate
from the signer of the PASSporT itself, allowing the ability to have from the signer of the PASSporT itself, allowing the ability to have
forward control at the time of the creation of the certificate of the forward control at the time of the creation of the certificate of the
allowed or vetted content included in or referenced by the RCD claim allowed or vetted content included in or referenced by the RCD claim
contents. The primary framework for allowing the separation of contents. The primary framework for allowing the separation of
authority and the signing of PASSporTs by non-authorized entities is authority and the signing of PASSporTs by non-authorized entities is
detailed in [I-D.ietf-stir-cert-delegation] although other cases may detailed in [I-D.ietf-stir-cert-delegation] although other cases may
apply. As with the first and second modes, the third and fourth apply. As with the first and second modes, the third and fourth
modes differ with the absence or inclusion of externally referenced modes differ with the absence or inclusion of externally referenced
content using URIs. content using URIs.
5. PASSporT Claim "rcd" Defintion and Usage 5. PASSporT Claim "rcd" Definition and Usage
5.1. PASSporT "rcd" Claim 5.1. PASSporT "rcd" Claim
This specification defines a new JSON Web Token claim for "rcd", Rich This specification defines a new JSON Web Token claim for "rcd", Rich
Call Data, the value of which is a JSON object that can contain one Call Data, the value of which is a JSON object that can contain one
or more key value pairs. This document defines a default set of key or more key value pairs. This document defines a default set of key
values. values.
5.1.1. "nam" key 5.1.1. "nam" key
skipping to change at page 8, line 37 skipping to change at page 8, line 20
the alternate presentation number should follow the same level of the alternate presentation number should follow the same level of
vetting as telephone identities or any other information contained in vetting as telephone identities or any other information contained in
an RCD PASSporT. This usage is intended as an alternative to an RCD PASSporT. This usage is intended as an alternative to
conveying the presentation number in the "tel" key value of a jCard, conveying the presentation number in the "tel" key value of a jCard,
in situations where no other rich jCard data needs to be conveyed in situations where no other rich jCard data needs to be conveyed
with the call. Only one "apn" key may be present. "apn" MUST be used with the call. Only one "apn" key may be present. "apn" MUST be used
when it is the intent of the caller or signer to display the when it is the intent of the caller or signer to display the
alternate presentation number even if "jcd" or "jcl" keys are present alternate presentation number even if "jcd" or "jcl" keys are present
in a PASSporT with a "tel" key value. in a PASSporT with a "tel" key value.
5.1.3. "jcd" key 5.1.3. "icn" key
The "icn" key value is an optional URI reference to an image that can
be used to pictorially represent the originator of personal
communications. This icon key value should be used as a base or
default method of associating an image with a calling party.
When being used for SIP [RFC3261] this claim key value used to
protect the call-info header field with a purpose parameter value of
"icon" as described in Section 20.9 [RFC3261]. Example as follows:
Call-Info: <http://wwww.example.com/alice/photo.jpg>;
purpose=icon
Note that [I-D.ietf-sipcore-callinfo-rcd] extends the specific usage
of "icon" in SIP in the context of the larger rich call data
framework with specific guidance on referencing images and image
types, sizes and formats.
It should be also noted that with jCard, as described in the
following "jcd" and "jcl" key value sections and in
[I-D.ietf-sipcore-callinfo-rcd], there are alternative ways of
including photos and logos as URI references. The "icn" key should
be then considered a base or default image and jCard usage should be
considered for profiles and extensions that provide more direct
guidance on the usage of specific defined usage of what each image
type represents for the proper rendering to end users.
5.1.4. "jcd" key
The "jcd" key value is defined to contain a jCard [RFC7095] JSON The "jcd" key value is defined to contain a jCard [RFC7095] JSON
object. This jCard object is intended to represent and derives from object. This jCard object is intended to represent and derives from
the Call-Info header field value defined in the Call-Info header field value defined in
[I-D.ietf-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.ietf-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
skipping to change at page 9, line 13 skipping to change at page 9, line 29
included. The use of "jcd" and "jcl" keys are mutually exclusive. included. The use of "jcd" and "jcl" keys are mutually exclusive.
The jCard object value for "jcd" MUST only have referenced content The jCard object value for "jcd" MUST only have referenced content
for URI values that do not further reference URIs. Future for URI values that do not further reference URIs. Future
specifications may extend this capability, but as stated in specifications may extend this capability, but as stated in
[I-D.ietf-sipcore-callinfo-rcd] it constrains the security properties [I-D.ietf-sipcore-callinfo-rcd] it constrains the security properties
of RCD information and the integrity of the content referenced by of RCD information and the integrity of the content referenced by
URIs. URIs.
Note: even though we refer to [I-D.ietf-sipcore-callinfo-rcd] as the 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, definition of the jcard properties for usage in an "rcd" PASSporT,
other protocols can be adapted for use of "jcd" (or similarly "jcl" other future specifications and protocols are encouraged to be
below) key beyond SIP and Call-Info. adapted for use of "jcd" (or similarly "jcl" below) key beyond SIP
and Call-Info.
5.1.4. "jcl" key 5.1.5. "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 URI 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. The web server MUST use the MIME media type for JSON web server. The web server MUST use the MIME media type for JSON
text as application/json with a default encoding of UTF-8 [RFC4627]. text as application/json with a default encoding of UTF-8 [RFC4627].
This link may derive from the Call-Info header field value defined in This link may derive from the Call-Info header field value defined in
[I-D.ietf-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.ietf-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. The "jcl" key is optional. If included, this rules and procedures. The "jcl" key is optional. If included, this
key MUST only be included once in the "rcd" JSON object and MUST NOT key MUST only be included once in the "rcd" JSON object and MUST NOT
be included if there is a "jcd" key included. The use of "jcd" and be included if there is a "jcd" key included. The use of "jcd" and
skipping to change at page 9, line 42 skipping to change at page 10, line 15
The jCard object referenced by the URI value for "jcl" MUST only have The jCard object referenced by the URI value for "jcl" MUST only have
referenced content for URI values that do not further reference URIs. referenced content for URI values that do not further reference URIs.
Future specifications may extend this capability, but as stated in Future specifications may extend this capability, but as stated in
[I-D.ietf-sipcore-callinfo-rcd] it constrains the security properties [I-D.ietf-sipcore-callinfo-rcd] it constrains the security properties
of RCD information and the integrity of the content referenced by of RCD information and the integrity of the content referenced by
URIs. URIs.
6. "rcdi" RCD Integrity Claim Definition and Usage 6. "rcdi" RCD Integrity Claim Definition and Usage
The "rcdi" claim is included for the second and fourth modes The "rcdi" claim is included for the second and fourth modes
described in integrity overview section of this document. If this described in the integrity overview Section 4 of this document. If
claim is present it MUST be only included once with the corresponding this claim is present it MUST be included only once with the
single "rcd" claim. The value of the "rcdi" claim is a JSON object corresponding single "rcd" claim. The value of the "rcdi" claim is a
that is defined as follows. JSON object that is defined as follows.
The claim value of "rcdi" claim key is a JSON object with a set of The claim value of "rcdi" claim key is a JSON object with a set of
JSON key/value pairs. These objects correspond to each of the JSON key/value pairs. These objects correspond to each of the
elements of the "rcd" claim object that require integrity protection elements of the "rcd" claim object that require integrity protection
with an associated digest over the content referenced by the key with an associated digest over the content referenced by the key
string. The individual digest of different elements of the "rcd" string. The individual digest of different elements of the "rcd"
claim data and external URI referenced content is kept specifically claim data and external URI referenced content is kept specifically
separate to allow the ability to verify the integrity of only the separate to allow the ability to verify the integrity of only the
elements that are ultimately retrieved or downloaded or rendered to elements that are ultimately retrieved or downloaded or rendered to
the end-user. the end-user.
skipping to change at page 10, line 19 skipping to change at page 10, line 41
value using a JSON pointer defined in [RFC6901] with a minor value using a JSON pointer defined in [RFC6901] with a minor
additional rule to support external URI references that include JSON additional rule to support external URI references that include JSON
objects themselves, for the specific case of the use of "jcl". JSON objects themselves, for the specific case of the use of "jcl". JSON
pointer syntax is the key value that specifies exactly the part of pointer syntax is the key value that specifies exactly the part of
JSON that is used to generate the digest which produce the resulting JSON that is used to generate the digest which produce the resulting
string that makes up the value for the corresponding key. Detailed string that makes up the value for the corresponding key. Detailed
procedures are provided below, but an example "rcdi" is provided procedures are provided below, but an example "rcdi" is provided
here: here:
"rcdi" : { "rcdi" : {
"/jcd": "sha256-7kdCBZqH0nqMSPsmABvsKlHPhZEStgjojhdSJGRr3rk", "/jcl": "sha256-7kdCBZqH0nqMSPsmABvsKlHPhZEStgjojhdSJGRr3rk",
"/jcd/1/2/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI" "/jcl/1/2/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI"
} }
The values of each key pair are a digest combined with a string that The values of each key/value pair consists of a digest across either
defines the crypto algorithm used to generate the digest. RCD the direct values or indirectly referenced resources, combined with a
implementations MUST support the following hash algorithms, "SHA256", string that defines the crypto algorithm used to generate the digest.
"SHA384", and "SHA512". The SHA-256, SHA-384, and SHA-512 are part RCD implementations MUST support the following hash algorithms,
of the SHA-2 set of cryptographic hash functions defined by the "SHA256", "SHA384", and "SHA512". The SHA-256, SHA-384, and SHA-512
National Institute of Standards and Technologies (NIST). are part of the SHA-2 set of cryptographic hash functions defined by
the National Institute of Standards and Technologies (NIST).
Implementations MAY support additional algorithms, but MUST NOT Implementations MAY support additional algorithms, but MUST NOT
support known weak algorithms such as MD5 or SHA-1. In the future, support known weak algorithms such as MD5 or SHA-1. In the future,
the list of algorithms may be re-evaluated based on security best the list of algorithms may be re-evaluated based on security best
practices. The algorithms are represented in the text by "sha256", practices. The algorithms are represented in the text by "sha256",
"sha384", or "sha512". The character following the algorithm string "sha384", or "sha512". The character following the algorithm string
MUST be a minus character, "-". The subsequent characters are the MUST be a minus character, "-". The subsequent characters are the
base64 encoded [RFC4648] digest of a canonicalized and concatenated base64 encoded [RFC4648] digest of a canonicalized and concatenated
string or binary data based on the JSON pointer referenced elements string or binary data based on the JSON pointer referenced elements
of "rcd" claim or the URI referenced content contained in the claim. of "rcd" claim or the URI referenced content contained in the claim.
The details of the determination of the input string used to The details of the determination of the input string used to
determine the digest are defined in the next section. determine the digest are defined in the next section.
6.1. Creation of the "rcd" element digests 6.1. Creation of the "rcd" element digests
"rcd" claim objects can contain "nam", "apn", "jcd", or "jcl" keys as "rcd" claim objects can contain "nam", "apn", "icn", "jcd", or "jcl"
part of the "rcd" JSON object claim value. This specification keys as part of the "rcd" JSON object claim value. This
defines the use of JSON pointer [RFC6901] as a mechanism to reference specification defines the use of JSON pointer [RFC6901] as a
specific "rcd" claim elements. mechanism to reference specific "rcd" claim elements.
In the case of "nam", the only allowed value is a "string". In order 6.1.1. "nam" and "apn" elements
to reference the "nam" string value for a digest, the JSON pointer
string would be "/nam" and the digest string would be created using
only the string pointed to by that "/nam" following the rules of JSON
pointer.
In the case of "apn", the only allowed value is a "string". In order In the case of "nam" and "apn", the only allowed value is a string.
to reference the "apn" string value for a digest, the JSON pointer For both of these key values an "rcdi" JSON pointer or integrity
string would be "/apn" and the digest string would be created using digest is optional because the direct value is protected by the
only the string pointed to by that "/apn" following the rules of JSON signature and can be constrained directly with JWTClaimConstraints.
pointer. If used, the JSON key value referenced by the JSON pointer is the
string includes the quotes, so quotes MUST be included to compute the
digest.
6.1.2. "icn" elements
In the case of "icn", the only allowed value is a URI value. If the
URI references externally linked content there would need to be a
JSON pointer and digest entry for this value. In order to reference
the "icn" value for a digest, the JSON pointer string would be "/icn"
and the digest string would be created using only the string pointed
to by that "/apn" following the rules of JSON pointer. Even though
this is probably not the typical case, an "rcdi" JSON pointer or
integrity digest is optional if the image value is directly included
via a data URI. However, even though the direct value can be
protected by the signature and can be constrained directly with
JWTClaimConstraints, since the length of the image data is likely
much larger than the integrity digest, this specification would
recommend the use of the "rcdi" JSON pointer and integrity digest as
the constraint value in JWTClaimConstraints over the image data.
6.1.3. "jcd" elements
In the case of "jcd", the value associated is a jCard JSON object, In the case of "jcd", the value associated is a jCard JSON object,
which happens to be a JSON array with sub-arrays. JSON pointer which happens to be a JSON array with sub-arrays. JSON pointer
notation uses numeric indexes into elements of arrays, including when notation uses numeric indexes into elements of arrays, including when
those elements are arrays themselves. those elements are arrays themselves.
As example, for the following "rcd" claim: As example, for the following "rcd" claim:
"rcd": { "rcd": {
"nam": "Q Branch Spy Gadgets",
"jcd": ["vcard", "jcd": ["vcard",
[ ["version",{},"text","4.0"], [ ["version",{},"text","4.0"],
[“fn",{},"text","Q Branch"], [“fn",{},"text","Q Branch"],
[“org",{},"text","MI6;Q Branch Spy Gadgets"], [“org",{},"text","MI6;Q Branch Spy Gadgets"],
["photo",{},"uri", ["photo",{},"uri",
"https://example.com/photos/quartermaster-256x256.png"], "https://example.com/photos/quartermaster-256x256.png"],
["logo",{},"uri", ["logo",{},"uri",
"https://example.com/logos/mi6-256x256.jpg"], "https://example.com/logos/mi6-256x256.jpg"],
["logo",{},"uri", ["logo",{},"uri",
"https://example.com/logos/mi6-64x64.jpg"] "https://example.com/logos/mi6-64x64.jpg"]
] ]
] ],
"nam": "Q Branch Spy Gadgets"
} }
In order to use JSON pointer to refer to the URIs, the following In order to use JSON pointer to refer to the URIs, the following
example "rcdi" claim includes a digest for the entire "jcd" array example "rcdi" claim includes a digest for the entire "jcd" array
string as well as three additional digests for the URIs, where, as string as well as three additional digests for the URIs, where, as
defined in [RFC6901] zero-based array indexes are used to reference defined in [RFC6901] zero-based array indexes are used to reference
the URI strings. the URI strings.
"rcdi": { "rcdi": {
"/jcd": "sha256-7kdCBZqH0nqMSPsmABvsKlHPhZEStgjojhdSJGRr3rk",
"/jcd/1/3/3": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4", "/jcd/1/3/3": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4",
"/jcd/1/4/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI", "/jcd/1/4/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI",
"/jcd/1/5/3": "sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo" "/jcd/1/5/3": "sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo"
} }
} }
For the use of JSON pointer in "jcd" and because array indexes are
dependent on the order of the elements in the jCard, the digest for The use of a JSON pointer and integrity digest for the "jcd" claim
the "/jcd" corresponding to the entire jCard array string MUST be key and value is optional. The "jcd" value is the directly included
included to avoid any possibility of substitution or insertion jCard array and can be protected by the signature and can be
attacks that may be possible to avoid integrity detection. Each URI constrained directly with JWTClaimConstraints. However, for data
referenced in the jCard array string MUST have a corresponding JSON length reasons (as with "icn" above) or more importantly for
pointer string key and digest value. potential privacy and/or security considerations with a publically
accessible certificate this specification would recommend the use of
the "rcdi" JSON pointer and integrity digest as the contraint value
in JWTClaimConstraints over the jCare data.
It is important to remember the array indexes for JSON Pointer are
dependent on the order of the elements in the jCard. The use of
digest for the "/jcd" corresponding to the entire jCard array string
can be included as a redundant mechanism to avoid any possibility of
substitution, insertion attacks, or other potential techniques that
may be possible to avoid integrity detection.
Each URI referenced in the jCard array string MUST have a
corresponding JSON pointer string key and digest value.
6.1.4. "jcl" elements
In the case of the use of a "jcl" URI reference to an external jCard, In the case of the use of a "jcl" URI reference to an external jCard,
the procedures are similar to "jcd" with the exception and the minor the procedures are similar to "jcd" with the exception and the minor
modification to JSON pointer, where "/jcl" is used to refer to the modification to JSON pointer, where "/jcl" is used to refer to the
external jCard array string and any following numeric array indexes external jCard array string and any following numeric array indexes
added to the "jcl" (e.g. "/jcl/1/2/3") are treated as if the added to the "jcl" (e.g., "/jcl/1/2/3") are treated as if the
externally referenced jCard was directly part of the overall "rcd" externally referenced jCard was directly part of the overall "rcd"
claim JSON object. The following example illustrates a "jcl" version claim JSON object. The following example illustrates a "jcl" version
of the above "jcd" example. of the above "jcd" example.
"rcd": { "rcd": {
"nam": "Q Branch Spy Gadgets", "jcl": "https://example.com/qbranch.json",
"jcl": "https://example.com/qbranch.json" "nam": "Q Branch Spy Gadgets"
}, },
"rcdi": { "rcdi": {
"/jcl": "sha256-Gb0lOkj7Z9+plqbOkN32H+YX0Yav3fbioSk7DxQdGZU", "/jcl": "sha256-Gb0lOkj7Z9+plqbOkN32H+YX0Yav3fbioSk7DxQdGZU",
"/jcl/1/3/3": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4", "/jcl/1/3/3": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4",
"/jcl/1/4/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI", "/jcl/1/4/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI",
"/jcl/1/5/3": "sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo" "/jcl/1/5/3": "sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo"
} }
https://example.com/qbranch.json: The following is the example contents of resource pointed to by
https://example.com/qbranch.json used to calculate the above digest
for "/jcl"
["vcard", ["vcard",
[ ["version",{},"text","4.0"], [ ["version",{},"text","4.0"],
[“fn",{},"text","Q Branch"], [“fn",{},"text","Q Branch"],
[“org",{},"text","MI6;Q Branch Spy Gadgets"] [“org",{},"text","MI6;Q Branch Spy Gadgets"]
["photo",{},"uri", ["photo",{},"uri",
"https://example.com/photos/quartermaster-256x256.png"] "https://example.com/photos/quartermaster-256x256.png"]
["logo",{},"uri", ["logo",{},"uri",
"https://example.com/logos/mi6-256x256.jpg"] "https://example.com/logos/mi6-256x256.jpg"]
["logo",{},"uri", ["logo",{},"uri",
"https://example.com/logos/mi6-64x64.jpg"] "https://example.com/logos/mi6-64x64.jpg"]
skipping to change at page 13, line 37 skipping to change at page 14, line 42
string as in jCard JSON objects or binary content. For example, string as in jCard JSON objects or binary content. For example,
image and audio files contain binary content. If the URI image and audio files contain binary content. If the URI
referenced content is JSON formatted, follow the procedures referenced content is JSON formatted, follow the procedures
defined in list item 2 above. Either the binary data or string defined in list item 2 above. Either the binary data or string
content of the file is used to create a resulting string which content of the file is used to create a resulting string which
MUST be a Base64 encoded [RFC4648] digest string (for sha256 this MUST be a Base64 encoded [RFC4648] digest string (for sha256 this
should result in approximately 44 characters). should result in approximately 44 characters).
6.2. JWT Claim Constraints for "rcd" claims only 6.2. JWT Claim Constraints for "rcd" claims only
For the third mode described in the integrity overview section of For the third mode described in the integrity overview Section 4 of
this document, where only JWT Claim Constraints for "rcd" claims this document, where only JWT Claim Constraints for "rcd" claims
without an "rcdi" claim is required, the procedure when creating the without an "rcdi" claim is required, the procedure when creating the
certificate with the intent to always include an "rcd" claim, to certificate with the intent to always include an "rcd" claim, to
include a JWT Claim Constraints on inclusion of an "rcd" claim with include a JWT Claim Constraints on inclusion of an "rcd" claim with
the intended values required to be constrained by the certificate the intended values required to be constrained by the certificate
used to sign the PASSporT. used to sign the PASSporT.
The "permittedValues" for the "rcd" claim may optionally contain The "permittedValues" for the "rcd" claim may optionally contain
multiple entries, to support the case where the certificate holder is multiple 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.
Only including "permittedValues" for "rcd" (with no "mustInclude") Only including "permittedValues" for "rcd" (with no "mustInclude")
provides the ability to either have no "rcd" claim or only the set of provides the ability to either have no "rcd" claim or only the set of
constrained "permittedValues" values for an included "rcd" claim. constrained "permittedValues" values for an included "rcd" claim.
7. JWT Claim Constraints usage for "rcd" and "rcdi" claims 7. JWT Claim Constraints usage for "rcd" and "rcdi" claims
The integrity overview section of this document describes a fourth The integrity overview Section 4 of this document describes a fourth
mode where both "rcdi" and JWT Claim Constraints is used. The use of mode where both "rcdi" and JWT Claim Constraints is used. The use of
this mode implies the signing of an "rcdi" claim is required to be this mode implies the signing of an "rcdi" claim is required to be
protected by the authoritative certificate creator using JWT Claims protected by the authoritative certificate creator using JWT Claims
Constraints in the certificate. The intension of the use of both of Constraints in the certificate. The objective of the use of both of
these mechanisms is to constrain the signer to construct the "rcd" these mechanisms is to constrain the signer to construct the "rcd"
and "rcdi" claims with the "rcd" jCard object including reference and "rcdi" claims with the "rcd" jCard object including reference
external content via URI. Once both the contents of the "rcd" claim external content via URI. Once both the contents of the "rcd" claim
and any linked content is certified by the party that is and any linked content is certified by the party that is
authoritative for the certificate being created and the construction authoritative for the certificate being created and the construction
of the "rcdi" claim is complete, the "rcdi" claim is linked to the of the "rcdi" claim is complete, the "rcdi" claim is linked to the
STIR certificate associated with the signature in the PASSporT via STIR certificate associated with the signature in the PASSporT via
JWT Claim Constraints as defined in [RFC8226] Section 8. It should JWT Claim Constraints extension as defined in [RFC8226] Section 8.
be recognized that the "rcdi" set of digests is intended to be unique It should be recognized that the "rcdi" set of digests is intended to
for only a specific combination of "rcd" content and URI referenced be unique for only a specific combination of "rcd" content and URI
external content, and therefore provides a robust integrity mechanism referenced external content, and therefore provides a robust
for an authentication service being performed by a non-authoritative integrity mechanism for an authentication service being performed by
party. This would often be associated with the use of delegate a non-authoritative party. This would often be associated with the
certificates [I-D.ietf-stir-cert-delegation] for the signing of calls use of delegate certificates [I-D.ietf-stir-cert-delegation] for the
by the calling party directly as an example, even though the signing of calls by the calling party directly as an example, even
"authorized party" is not necessarily the subject of a STIR though the "authorized party" is not necessarily the subject of a
certificate. STIR certificate.
For the case that there should always be both "rcd" and "rcdi" values For the case that there should always be both "rcd" and "rcdi" values
included in the "rcd" PASSporT, the certificate JWT Claims Constraint included in the "rcd" PASSporT, the certificate JWT Claims Constraint
MUST include both of the following: extension MUST include both of the following:
* a "mustInclude" for the "rcd" claim, which simply constrains the * a "mustInclude" for the "rcd" claim, which simply constrains the
fact that an "rcd" must be included if there is a "rcdi" fact that an "rcd" must be included
* a "mustInclude" for the "rcdi" claim and a "permittedValues" equal * a "mustInclude" for the "rcdi" claim and a "permittedValues" equal
to the created "rcdi" claim value string. to the created "rcdi" claim value string.
Note that optionally the "rcd" claims may be included in the Note that optionally the "rcd" claims may be included in the
"permittedValues" however it is recognized that this may be redundant "permittedValues" however it is recognized that this may be redundant
with the "rcdi" permittedValues because the "rcdi" digest will imply with the "rcdi" permittedValues because the "rcdi" digest will imply
the content of the "rcd" claims themselves. the content of the "rcd" claims themselves.
The "permittedValues" for the "rcdi" claims may contain multiple The "permittedValues" for the "rcdi" claims (or "rcd" claims more
entries, to support the case where the certificate holder is generally) may contain multiple entries, to support the case where
authorized to use different sets of rich call data. the certificate holder is authorized to use different sets of rich
call data.
8. PASSporT "crn" claim - Call Reason Defintion and Usage 8. PASSporT "crn" claim - Call Reason Definition and Usage
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.ietf-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 "call-reason" parameter for the Call-Info
This claim is optional. header. This claim is optional.
Example "crn" claim with "rcd": Example "crn" claim with "rcd":
"crn" : "For your ears only",
"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"
As also noted in [I-D.ietf-sipcore-callinfo-rcd] this claim is
included as corresponding to "call-reason" Call-Info parameter, but
there is an alternative suggested way to include call-reason which is
to use the "cif" claim with a "call-reason" key value, as defined
below in this document.
8.1. JWT Constraint for "crn" claim 8.1. JWT Constraint for "crn" claim
The integrity of the "crn" claim can optionally be protected by the The integrity of the "crn" claim can optionally be protected by the
authoritative certificate creator using JWT Constraints in the authoritative certificate creator using JWT Constraints in the
certificate. If the intent of the issuer of the certificate is to certificate. If the intent of the issuer of the certificate is to
always including a call reason, a "mustInclude" for the "crn" claim always including a call reason, a "mustInclude" for the "crn" claim
indicates that a "crn" claim must be present. If the issuer of the indicates that a "crn" claim must be present. If the issuer of the
certificate wants to constrain the contents of "crn", then it may set certificate wants to constrain the contents of "crn", then it may set
"permittedValues" for "crn" in the certificate. "permittedValues" for "crn" in the certificate.
9. Rich Call Data Claims Usage Rules 9. Rich Call Data Claims Usage Rules
Either or both the "rcd" or "crn" claims may appear in any PASSporT Either or both the "rcd" or "crn" claims may appear in any PASSporT
claims object as optional elements. The creator of a PASSporT MAY claims object as optional elements. The creator of a PASSporT MAY
also add a "ppt" value of "rcd" to the header of a PASSporT as well, also 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 in which case the PASSporT claims MUST contain either an "rcd" or
"crn" claim, and any entities verifying the PASSporT object are "crn" claim, and any entities verifying the PASSporT object are
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. An example PASSporT header with the "ppt" PASSporT in question. An example PASSporT header with the "ppt"
included is shown as follows: included is shown as follows:
{ "typ":"passport", { "typ":"passport",
"ppt":"rcd", "ppt":"rcd",
"alg":"ES256", "alg":"ES256",
"x5u":"https://www.example.com/cert.cer" } "x5u":"https://www.example.com/cert.cer" }
The PASSporT claims object contains the "rcd" key with its The PASSporT claims object contains the "rcd" key with its
corresponding value. The value of "rcd" is an array of JSON objects, corresponding value. The value of "rcd" is an array of JSON objects,
of which one, the "nam" object, is mandatory. The key syntax of of which one, the "nam" object, is mandatory. The key syntax of
"nam" follows the display-name ABNF given in [RFC3261]. "nam" follows the display-name ABNF given in [RFC3261].
After the header and claims PASSporT objects have been constructed, After the header and claims PASSporT objects have been constructed,
their signature is generated normally per the guidance in [RFC8225]. their signature is generated normally per the guidance in [RFC8225].
9.1. Verification rules 9.1. "rcd" PASSporT Verification
A PASSporT that uses claims defined in this specification, in order An "rcd" PASSporT that uses claims defined in this specification, in
to have a successful verification outcome, MUST conform to the order to have a successful verification outcome, MUST conform to the
following: following:
* have a valid signature
* abide by all rules set forth in the proper construction of the * abide by all rules set forth in the proper construction of the
claims claims
* abide by JWT Claims Constraint rules defined in [RFC8226] * abide by JWT Claims Constraint rules defined in [RFC8226]
Section 8 or extended in [I-D.ietf-stir-enhance-rfc8226] if Section 8 or extended in [I-D.ietf-stir-enhance-rfc8226] if
present in the certificate used to sign the PASSporT present in the certificate used to sign the PASSporT
* pass integrity verification using "rcdi" if present.
Consistent with the verification rules of PASSporTs more generally Consistent with the verification rules of PASSporTs more generally
[RFC8225], if any of the above criteria is not met, the PASSporT [RFC8225], if any of the above criteria is not met, relying parties
verification should be considered a failed verification for all MUST NOT use any of the claims in the PASSporT.
claims in the PASSporT.
In some middle box scenarios, a relying party may not have the need 9.2. "rcdi" Integrity Verification
to validate content that is referenced by URIs (e.g. only wanting to
validate base PASSporT info like "orig" and "dest" or other "rcd"
info like "nam" or "apn"). In these scenarios, this proceedure while
not considered a full verification, can be performed without
verifying the full integrity checks of URI referenced content.
9.2. Example "rcd" PASSporTs If the "rcdi" claim exists, any party that dereferences a URI (i.e.
downloading content for display to users) from the "rcd" claim MUST
perform integrity validation of the content against the corresponding
digest. Consequently, if URIs with contents covered by integrity
digests are passed to another entity, the corresponding integrity
digest MUST also be included, for example by passing the PASSporT.
Entities that pass on the content without the URI do not have to pass
on the corresponding integrity digest. An entity that does not
otherwise need to dereference a URI from the "rcd" claim would be
discouraged from unnecessarily dereferencing the URI solely to
perform integrity verification.
If there is any issue with completing the integrity verification
procedures for externally referenced content, including HTTP or HTTPS
errors, the referenced content MUST be considered not verified. This
SHOULD NOT however impact the result of base PASSporT verification
for claims content that is directly included in the claims of the
PASSporT.
9.3. Example "rcd" PASSporTs
An example of a "nam" only PASSporT claims object is shown next (with An example of a "nam" only PASSporT claims object is shown next (with
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" and "apn" only PASSporT claims object is shown An example of a "nam" and "apn" only PASSporT claims object is shown
next (with line breaks for readability only). next (with line breaks for readability only).
{ "orig":{"tn":"12025551000"}, { "orig":{"tn":"12025551000"},
"dest":{"tn":["12155551001"]}, "dest":{"tn":["12155551001"]},
"iat":1443208345, "iat":1443208345,
"rcd":{ "rcd":{
"apn":"12025559990", "apn":"12025559990",
"nam":"Her Majesty's Secret Service" } } "nam":"Her Majesty's Secret Service" } }
An example of a "nam" only PASSporT claims object with an "rcdi" An example of an "rcd" claims object that includes the "jcd" and also
claim is shown next (with line breaks for readability only). contains URI references to content which requires the inclusion of an
"rcdi" claim and corresponding digests.
{ "orig":{"tn":"12025551000"},
"dest":{"tn":["12025551001"]},
"iat":1443208345,
"rcd":{"nam":"James Bond"},
"rcdi":{"/nam": "sha256-uDtvpG1xNw+MK0XEOh+2UNQ94MQJ5d2ftgmHxsjKeMw"}
}
An example of a "rcd" claims object that includes the "jcd" and also
contains a URI which requires the inclusion of an "rcdi" claim.
{ {
"crn": "Rendezvous for Little Nellie",
"orig": { "tn": "12025551000"}, "orig": { "tn": "12025551000"},
"dest": { "tn": ["12155551001"]}, "dest": { "tn": ["12155551001"]},
"iat": 1443208345, "iat": 1443208345,
"rcd": { "rcd": {
"nam": "Q Branch Spy Gadgets",
"jcd": ["vcard", "jcd": ["vcard",
[ ["version",{},"text","4.0"], [ ["version",{},"text","4.0"],
["fn",{},"text","Q Branch"], ["fn",{},"text","Q Branch"],
["org",{},"text","MI6;Q Branch Spy Gadgets"], ["org",{},"text","MI6;Q Branch Spy Gadgets"],
["photo",{},"uri","https://example.com/photos/q-256x256.png"], ["photo",{},"uri","https://example.com/photos/q-256x256.png"],
["logo",{},"uri","https://example.com/logos/mi6-256x256.jpg"], ["logo",{},"uri","https://example.com/logos/mi6-256x256.jpg"],
["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg"] ["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg"]
] ] ] ],
"nam": "Q Branch Spy Gadgets"
}, },
"crn": "Rendezvous for Little Nellie",
"rcdi": { "rcdi": {
"/nam": "sha256-sM275lTgzCte+LHOKHtU4SxG8shlOo6OS4ot8IJQImY",
"/jcd": "sha256-7kdCBZqH0nqMSPsmABvsKlHPhZEStgjojhdSJGRr3rk",
"/jcd/1/3/3": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4", "/jcd/1/3/3": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4",
"/jcd/1/4/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI", "/jcd/1/4/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI",
"/jcd/1/5/3": "sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo" "/jcd/1/5/3": "sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo"
} }
} }
In an example PASSporT, where a jCard is linked via HTTPS URL using In an example PASSporT, where a jCard is linked via HTTPS URL using
"jcl", a jCard file served at a particular URL. "jcl", a jCard file served at a particular URL.
An example jCard JSON file is shown as follows: An example jCard JSON file hosted at the example web address of
https://example.com/qbranch.json is shown as follows:
https://example.com/qbranch.json:
["vcard", ["vcard",
[ ["version",{},"text","4.0"], [ ["version",{},"text","4.0"],
["fn",{},"text","Q Branch"], ["fn",{},"text","Q Branch"],
["org",{},"text","MI6;Q Branch Spy Gadgets"], ["org",{},"text","MI6;Q Branch Spy Gadgets"],
["photo",{},"uri","https://example.com/photos/q-256x256.png"], ["photo",{},"uri","https://example.com/photos/q-256x256.png"],
["logo",{},"uri","https://example.com/logos/mi6-256x256.jpg"], ["logo",{},"uri","https://example.com/logos/mi6-256x256.jpg"],
["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg"] ["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg"]
] ]
] ]
If that jCard is hosted at the example address of For the above referenced jCard, the corresponding PASSporT claims
"https://example.com/qbranch.json", the corresponding PASSporT claims
object would be as follows: object would be as follows:
{ {
"crn": "Rendezvous for Little Nellie",
"orig": {"tn": "12025551000"}, "orig": {"tn": "12025551000"},
"dest": {"tn": ["12155551001"]}, "dest": {"tn": ["12155551001"]},
"iat": 1443208345, "iat": 1443208345,
"rcd": { "rcd": {
"nam": "Q Branch Spy Gadgets", "nam": "Q Branch Spy Gadgets",
"jcl": "https://example.com/qbranch.json" "jcl": "https://example.com/qbranch.json"
}, },
"crn": "Rendezvous for Little Nellie",
"rcdi": { "rcdi": {
"/nam": "sha256-Gb0lOkj7Z9+plqbOkN32H+YX0Yav3fbioSk7DxQdGZU",
"/jcl": "sha256-Gb0lOkj7Z9+plqbOkN32H+YX0Yav3fbioSk7DxQdGZU", "/jcl": "sha256-Gb0lOkj7Z9+plqbOkN32H+YX0Yav3fbioSk7DxQdGZU",
"/jcl/1/3/3": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4", "/jcl/1/3/3": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4",
"/jcl/1/4/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI", "/jcl/1/4/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI",
"/jcl/1/5/3": "sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo" "/jcl/1/5/3": "sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo"
} }
} }
10. Compact form of "rcd" PASSporT 10. Compact form of "rcd" PASSporT
10.1. Compact form of the "rcd" PASSporT claim 10.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 that
mainly follows standard PASSporT compact form procedures. For re- will be enumerated below, but mainly follows standard PASSporT
construction of the "nam" claim the string for the display-name in compact form procedures. For re-construction of the "nam" claim the
the From header field. For re-construction of the "jcl", the Call- string for the display-name in the From header field. "jcl" and "jcd"
Info header as with purpose "jcard" defined in MAY NOT be used with compact form due to integrity rules and URI
[I-D.ietf-sipcore-callinfo-rcd] MUST be used. "jcd" claim MAY NOT be reference rules in this specification leading to too restrictive of a
used as part of compact form. set of constraints. Future specifications may revisit this to
propose a consisent and comprehensive way of addressing integrity and
security of information.
10.2. Compact form of the "rcdi" PASSporT claim 10.2. Compact form of the "rcdi" PASSporT claim
Compact form of an "rcdi" PASSporT claim is not supported, so if Compact form of an "rcdi" PASSporT claim is not supported, so if
"rcdi" is required compact form MUST NOT be used. "rcdi" is required compact form MUST NOT be used.
10.3. Compact form of the "crn" PASSporT claim 10.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 "call-reason" parameter of a Call-Info header as defined by the "call-reason" parameter of a Call-Info header as defined by
skipping to change at page 22, line 42 skipping to change at page 24, line 36
14. Using "rcd" in SIP 14. 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.
14.1. Authentication Service Behavior 14.1. Authentication Service Behavior
An authentication service creating a PASSporT containing a "rcd" An authentication service creating a PASSporT containing an "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 12.1 MUST authentication services following the behavior in Section 12.1 MUST
include a "ppt" of "rcd". If "ppt" does contain a "rcd", then any include a "ppt" of "rcd". If "ppt" does contain an "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/HmtyNS7Ltrg9 Identity: sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9
dlxkWzoeU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgt dlxkWzoeU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgt
w0Lu5csIppPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=; w0Lu5csIppPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=;
info=<https://biloxi.example.org/biloxi.cer>;alg=ES256; info=<https://biloxi.example.org/biloxi.cer>;alg=ES256;
ppt="rcd" ppt="rcd"
This specification assumes that by default, a SIP authentication This specification assumes that by default, a SIP authentication
service derives the value of "rcd", specifically only for the "nam" service derives the value of "rcd", specifically only for the "nam"
key value, from the display-name component of the From header field key value, from the display-name component of the From header field
value of the request, alternatively for some calls this may come from value of the request, alternatively for some calls this may come from
the P-Asserted-ID header. It is however a matter of authentication the P-Asserted-ID header. It is however a matter of authentication
service policy to decide how it populates the value of "nam" key, service policy to decide how it populates the value of "nam" key,
which MAY also derive from other fields in the request, from customer which MAY also derive from other fields in the request, from customer
profile data, or from access to external services. If the profile data, or from access to external services. If the
authentication service generates a "rcd" claim containing "nam" with authentication service generates an "rcd" claim containing "nam" with
a value that is not equivalent to the From header field display-name a value that is not equivalent to the From header field display-name
value, it MUST use the full form of the PASSporT object in SIP. value, it MUST use the full form of the PASSporT object in SIP.
14.2. Verification Service Behavior 14.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,
skipping to change at page 24, line 30 skipping to change at page 26, line 18
Verification services may alter their authorization policies for the Verification services may alter their authorization policies for the
credentials accepted to sign PASSporTs when third parties generate credentials accepted to sign PASSporTs when third parties generate
PASSporT objects, per Section 12.1. This may include accepting a PASSporT objects, per Section 12.1. This may include accepting a
valid signature over a PASSporT even if it is signed with a valid signature over a PASSporT even if it is signed with a
credential that does not attest authority over the identity in the credential that does not attest authority over the identity in the
"orig" claim of the PASSporT, provided that the verification service "orig" claim of the PASSporT, provided that the verification service
has some other reason to trust the signer. No further guidance on has some other reason to trust the signer. No further guidance on
verification service authorization policy is given here. verification service authorization policy is given here.
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 largely remains a matter of PASSporT object with an "rcd" claim largely remains 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.
15. Using "rcd" as additional claims to other PASSporT extensions 15. Using "rcd" and "rcdi" as additional claims to other PASSporT
extensions
Rich Call Data, including calling name information, for example, is Rich Call Data, including calling name information, as a common
often data that is additive data to the personal communications example, is often data that is additive to the personal
information defined in the core PASSporT data required to support the communications information defined in the core PASSporT data required
security properties defined in [RFC8225]. For cases where the entity to support the security properties defined in [RFC8225]. For cases
that is originating the personal communications and additionally is where the entity originating the personal communications is
supporting the authentication service and also is the authority of supporting the authentication service for the calling identity and is
the Rich Call Data, rather than creating multiple identity headers the authority of the Rich Call Data, rather than creating multiple
with multiple PASSporT extensions or defining multiple combinations Identity header fields cooresponding to multiple PASSporT extensions,
and permutations of PASSporT extension definitions, the the authentication service can alternatively directly add the "rcd"
authentication service can alternatively directly add the "rcd" claim to a PASSporT that authenticates the calling identity.
claims to the PASSporT it is creating, whether it is constructed with
a PASSporT extension or not.
Note: There is one very important caveat to this capability, because It is critically important for the user of this specification to
generally if there is URI referenced content in an "rcd" PASSporT recognize that the certificates used must include the necessary JWT
there is often the requirement to use "rcdi" and JWT Claims Claims Constraints and permitted values for proper integrity and
Constraints. So, it is important for the user of this specification security of the values in the "rcd" claim incorporated into PASSporTs
to recognize that the certificates used must include the necessary that are not "rcd". The verifier of "rcd" claims MUST recognize if
JWT Claims Constraints for proper integrity and security of the the signing certificate contains no claim constraints for direct
values in the "rcd" claim incorporated into PASSporTs that are not values or referenced content that they should have some sort of
"rcd". "trust" relationship with the signer of the PASSPorT that can vouch
for or have an understanding of how the rich call data was properly
vetted. An example scenario that demonstrates this might be when an
"rcd" PASSporT with information that was properly vetted, integrity
protected and constrained and is transferred by a middle party to
another PASSporT and signed by that party without that integrity
protection and constraints provided in the certificate. These
scenarios lose the end-to-end trust and integrity required by this
specification. However, it is recognized that some UNI or provider
to device scenarios where there is an authenticated "trust"
relationship MAY warrant the technique described in this section.
15.1. Procedures for applying "rcd" as claims only 15.1. Procedures for applying "rcd" as claims only
For a given PASSporT using some other extension than "rcd", the For a given PASSporT using some other extension than "rcd", the
Authentication Service MAY additionally include the "rcd" claim as Authentication Service MAY additionally include the "rcd" claim as
defined in this document. This would result in a set of claims that defined in this document. This would result in a set of claims that
correspond to the original intended extension with the addition of correspond to the original intended extension with the addition of
the "rcd" claim. the "rcd" claim.
The Verification service that receives the PASSporT, if it supports The Verification service that receives the PASSporT, if it supports
skipping to change at page 26, line 21 skipping to change at page 28, line 4
} }
Payload Payload
{ {
“attest”:”A”, “attest”:”A”,
"dest":{“tn”:["12025551001"]}, "dest":{“tn”:["12025551001"]},
"iat":1443208345, "iat":1443208345,
"orig":{“tn”:"12025551000"}, "orig":{“tn”:"12025551000"},
“origid”:”123e4567-e89b-12d3-a456-426655440000”, “origid”:”123e4567-e89b-12d3-a456-426655440000”,
"rcd":{"nam":"James Bond"} "rcd":{"nam":"James Bond"}
} }
A Verification Service that supports "rcd" and "shaken" PASSporT A Verification Service that supports "rcd" and "shaken" PASSporT
extensions is able to receive the above PASSporT and interpret both extensions is able to receive the above PASSporT and interpret both
the "shaken" claims as well as the "rcd" defined claim. the "shaken" claims as well as the "rcd" defined claim.
If the Verification Service only understands the "shaken" extension If the Verification Service only understands the "shaken" PASSporT
claims but doesn't support "rcd", the "rcd" is ignored and extension claims and doesn't support "rcd" PASSporT extension, then
disregarded. the "rcd" claim is used during PASSporT signature validation but is
otherwise ignored and disregarded.
16. Acknowledgements 16. Acknowledgements
We would like to thank David Hancock, Robert Sparks, Russ Housley, We would like to thank David Hancock, Robert Sparks, Russ Housley,
Eric Burger, Alec Fenichel, Ben Campbell, Jack Rickard for helpful Eric Burger, Alec Fenichel, Ben Campbell, Jack Rickard, Jordan
suggestions, review, and comments. Simpson for helpful suggestions, review, and comments.
17. IANA Considerations 17. IANA Considerations
17.1. JSON Web Token Claim 17.1. JSON Web Token Claim
This specification requests that the IANA add three new claims to the This specification requests that the IANA add three new claims to the
JSON Web Token Claims registry as defined in [RFC7519]. JSON Web Token Claims registry as defined in [RFC7519].
Claim Name: "rcd" Claim Name: "rcd"
skipping to change at page 28, line 9 skipping to change at page 29, line 44
Revealing information such as the name, location, and affiliation of Revealing information such as the name, location, and affiliation of
a person necessarily entails certain privacy risks. Baseline a person necessarily entails certain privacy risks. Baseline
PASSporT has no particular confidentiality requirement, as the PASSporT has no particular confidentiality requirement, as the
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.
The use of JWTClaimConstraints, a mechanism defined in [RFC8226] and
extended in [RFC9118] to constrain any of the RCD information in the
public certificate by including that information in the certificate,
depending on the availbility in the deployment of the PKI system, may
present a privacy issue. The use of "rcdi" claim and digests for
representing JWT claim contents may be a recommended way of
preventing the exposure of that information through the certificates
which are often publically accessible and available.
Since computation of "rcdi" digests for URIs requires the loading of Since computation of "rcdi" digests for URIs requires the loading of
referenced content, it would be best practice to validate that referenced content, it would be best practice to validate that
content at the creation of the "rcdi" or corresponding JWT claim content at the creation of the "rcdi" or corresponding JWT claim
constraint value by checking for content that may cause issues for constraint value by checking for content that may cause issues for
verification services or that doesn't follow the behavior defined in verification services or that doesn't follow the behavior defined in
this document, e.g. unreasonably sized data, the inclusion of this document, e.g., unreasonably sized data, the inclusion of
recursive URI references, etc. Along the same lines, the recursive URI references, etc. Along the same lines, the
verification service should also use precautionary best practices to verification service should also use precautionary best practices to
avoid attacks when accessing URI linked content. avoid attacks when accessing URI linked content.
18.1. The use of JWT Claim Constraints in delegate certificates to 18.1. The use of JWT Claim Constraints in delegate certificates to
exclude unauthorized claims exclude unauthorized claims
While this can apply to any PASSporT that is signed with a STIR While this can apply to any PASSporT that is signed with a STIR
Delegate Certificates [I-D.ietf-stir-cert-delegation], it is Delegate Certificates [I-D.ietf-stir-cert-delegation], it is
important to note that when constraining PASSporTs to include important to note that when constraining PASSporTs to include
skipping to change at page 28, line 46 skipping to change at page 30, line 42
Excluding this claim would prevent the integrity protection mechanism Excluding this claim would prevent the integrity protection mechanism
from working properly. from working properly.
19. References 19. References
19.1. Normative References 19.1. Normative References
[I-D.ietf-sipcore-callinfo-rcd] [I-D.ietf-sipcore-callinfo-rcd]
Wendt, C. and J. Peterson, "SIP Call-Info Parameters for Wendt, C. and J. Peterson, "SIP Call-Info Parameters for
Rich Call Data", Work in Progress, Internet-Draft, draft- Rich Call Data", Work in Progress, Internet-Draft, draft-
ietf-sipcore-callinfo-rcd-02, 22 February 2021, ietf-sipcore-callinfo-rcd-03, 25 October 2021,
<https://www.ietf.org/archive/id/draft-ietf-sipcore- <https://www.ietf.org/archive/id/draft-ietf-sipcore-
callinfo-rcd-02.txt>. callinfo-rcd-03.txt>.
[I-D.ietf-stir-cert-delegation] [I-D.ietf-stir-cert-delegation]
Peterson, J., "Secure Telephone Identity Revisited (STIR) Peterson, J., "Secure Telephone Identity Revisited (STIR)
Certificate Delegation", Work in Progress, Internet-Draft, Certificate Delegation", Work in Progress, Internet-Draft,
draft-ietf-stir-cert-delegation-04, 22 February 2021, draft-ietf-stir-cert-delegation-04, 22 February 2021,
<https://www.ietf.org/archive/id/draft-ietf-stir-cert- <https://www.ietf.org/archive/id/draft-ietf-stir-cert-
delegation-04.txt>. delegation-04.txt>.
[I-D.ietf-stir-enhance-rfc8226] [I-D.ietf-stir-enhance-rfc8226]
Housley, R., "Enhanced JSON Web Token (JWT) Claim Housley, R., "Enhanced JSON Web Token (JWT) Claim
skipping to change at page 30, line 43 skipping to change at page 32, line 34
Credentials: Certificates", RFC 8226, Credentials: Certificates", RFC 8226,
DOI 10.17487/RFC8226, February 2018, DOI 10.17487/RFC8226, February 2018,
<https://www.rfc-editor.org/info/rfc8226>. <https://www.rfc-editor.org/info/rfc8226>.
[RFC8588] Wendt, C. and M. Barnes, "Personal Assertion Token [RFC8588] Wendt, C. and M. Barnes, "Personal Assertion Token
(PaSSporT) Extension for Signature-based Handling of (PaSSporT) Extension for Signature-based Handling of
Asserted information using toKENs (SHAKEN)", RFC 8588, Asserted information using toKENs (SHAKEN)", RFC 8588,
DOI 10.17487/RFC8588, May 2019, DOI 10.17487/RFC8588, May 2019,
<https://www.rfc-editor.org/info/rfc8588>. <https://www.rfc-editor.org/info/rfc8588>.
[RFC9118] Housley, R., "Enhanced JSON Web Token (JWT) Claim
Constraints for Secure Telephone Identity Revisited (STIR)
Certificates", RFC 9118, DOI 10.17487/RFC9118, August
2021, <https://www.rfc-editor.org/info/rfc9118>.
19.2. Informative References 19.2. Informative References
[ATIS-1000074] [ATIS-1000074]
ATIS/SIP Forum NNI Task Group, "Signature-based Handling ATIS/SIP Forum NNI Task Group, "Signature-based Handling
of Asserted information using toKENs (SHAKEN) of Asserted information using toKENs (SHAKEN)
<https://access.atis.org/apps/group_public/ <https://access.atis.org/apps/group_public/
download.php/32237/ATIS-1000074.pdf>", January 2017. download.php/32237/ATIS-1000074.pdf>", January 2017.
[I-D.ietf-stir-oob] [I-D.ietf-stir-oob]
Rescorla, E. and J. Peterson, "Secure Telephone Identity Rescorla, E. and J. Peterson, "Secure Telephone Identity
Revisited (STIR) Out-of-Band Architecture and Use Cases", Revisited (STIR) Out-of-Band Architecture and Use Cases",
Work in Progress, Internet-Draft, draft-ietf-stir-oob-07, Work in Progress, Internet-Draft, draft-ietf-stir-oob-07,
9 March 2020, <https://www.ietf.org/archive/id/draft-ietf- 9 March 2020, <https://www.ietf.org/archive/id/draft-ietf-
stir-oob-07.txt>. stir-oob-07.txt>.
Authors' Addresses Authors' Addresses
Chris Wendt Chris Wendt
Comcast Somos Inc.
Comcast Technology Center
Philadelphia, PA 19103,
United States of America
Email: chris-ietf@chriswendt.net Email: chris-ietf@chriswendt.net
Jon Peterson Jon Peterson
Neustar Inc. Neustar Inc.
1800 Sutter St Suite 570
Concord, CA 94520,
United States of America
Email: jon.peterson@neustar.biz Email: jon.peterson@neustar.biz
 End of changes. 80 change blocks. 
223 lines changed or deleted 315 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/