< draft-ietf-stir-passport-rcd-15.txt   draft-ietf-stir-passport-rcd-16.txt >
Network Working Group C. Wendt Network Working Group C. Wendt
Internet-Draft Somos Inc. Internet-Draft Somos Inc.
Intended status: Standards Track J. Peterson Intended status: Standards Track J. Peterson
Expires: 8 September 2022 Neustar Inc. Expires: 21 October 2022 Neustar Inc.
7 March 2022 19 April 2022
PASSporT Extension for Rich Call Data PASSporT Extension for Rich Call Data
draft-ietf-stir-passport-rcd-15 draft-ietf-stir-passport-rcd-16
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 8 September 2022. This Internet-Draft will expire on 21 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 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
skipping to change at page 2, line 35 skipping to change at page 2, line 35
4. Overview of Rich Call Data Integrity . . . . . . . . . . . . 5 4. Overview of Rich Call Data Integrity . . . . . . . . . . . . 5
5. PASSporT Claim "rcd" Definition 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 . . . . . . . . . . . . . . . . . . . . . . 7 5.1.2. "apn" key . . . . . . . . . . . . . . . . . . . . . . 7
5.1.3. "icn" key . . . . . . . . . . . . . . . . . . . . . . 8 5.1.3. "icn" key . . . . . . . . . . . . . . . . . . . . . . 8
5.1.4. "jcd" key . . . . . . . . . . . . . . . . . . . . . . 9 5.1.4. "jcd" key . . . . . . . . . . . . . . . . . . . . . . 9
5.1.5. "jcl" key . . . . . . . . . . . . . . . . . . . . . . 9 5.1.5. "jcl" key . . . . . . . . . . . . . . . . . . . . . . 9
6. "rcdi" RCD Integrity Claim Definition and Usage . . . . . . . 10 6. "rcdi" RCD Integrity Claim Definition and Usage . . . . . . . 10
6.1. Creation of the "rcd" element digests . . . . . . . . . . 11 6.1. Creation of the "rcd" element digests . . . . . . . . . . 11
6.1.1. "nam" and "apn" elements . . . . . . . . . . . . . . 11 6.1.1. "nam" and "apn" elements . . . . . . . . . . . . . . 12
6.1.2. "icn" elements . . . . . . . . . . . . . . . . . . . 11 6.1.2. "icn" elements . . . . . . . . . . . . . . . . . . . 12
6.1.3. "jcd" elements . . . . . . . . . . . . . . . . . . . 12 6.1.3. "jcd" elements . . . . . . . . . . . . . . . . . . . 12
6.1.4. "jcl" elements . . . . . . . . . . . . . . . . . . . 13 6.1.4. "jcl" elements . . . . . . . . . . . . . . . . . . . 14
6.2. JWT Claim Constraints for "rcd" claims only . . . . . . . 14 6.2. JWT Claim Constraints for "rcd" claims only . . . . . . . 15
7. JWT Claim Constraints usage for "rcd" and "rcdi" claims . . . 15 7. JWT Claim Constraints usage for "rcd" and "rcdi" claims . . . 15
8. PASSporT "crn" claim - Call Reason Definition and Usage . . . 16 8. PASSporT "crn" claim - Call Reason Definition and Usage . . . 16
8.1. JWT Constraint for "crn" claim . . . . . . . . . . . . . 16 8.1. JWT Constraint for "crn" claim . . . . . . . . . . . . . 16
9. Rich Call Data Claims Usage Rules . . . . . . . . . . . . . . 16 9. Rich Call Data Claims Usage Rules . . . . . . . . . . . . . . 17
9.1. "rcd" PASSporT Verification . . . . . . . . . . . . . . . 17 9.1. "rcd" PASSporT Verification . . . . . . . . . . . . . . . 17
9.2. "rcdi" Integrity Verification . . . . . . . . . . . . . . 17 9.2. "rcdi" Integrity Verification . . . . . . . . . . . . . . 18
9.3. Example "rcd" PASSporTs . . . . . . . . . . . . . . . . . 18 9.3. Example "rcd" PASSporTs . . . . . . . . . . . . . . . . . 18
10. Compact form of "rcd" PASSporT . . . . . . . . . . . . . . . 20 10. Compact form of "rcd" PASSporT . . . . . . . . . . . . . . . 20
10.1. Compact form of the "rcd" PASSporT claim . . . . . . . . 20 10.1. Compact form of the "rcd" PASSporT claim . . . . . . . . 20
10.2. Compact form of the "rcdi" PASSporT claim . . . . . . . 20 10.2. Compact form of the "rcdi" PASSporT claim . . . . . . . 21
10.3. Compact form of the "crn" PASSporT claim . . . . . . . . 20 10.3. Compact form of the "crn" PASSporT claim . . . . . . . . 21
11. Further Information Associated with Callers . . . . . . . . . 21 11. Further Information Associated with Callers . . . . . . . . . 21
12. Third-Party Uses . . . . . . . . . . . . . . . . . . . . . . 22 12. Third-Party Uses . . . . . . . . . . . . . . . . . . . . . . 22
12.1. Signing as a Third Party . . . . . . . . . . . . . . . . 23 12.1. Signing as a Third Party . . . . . . . . . . . . . . . . 23
13. Levels of Assurance . . . . . . . . . . . . . . . . . . . . . 24 13. Levels of Assurance . . . . . . . . . . . . . . . . . . . . . 24
14. Using "rcd" in SIP . . . . . . . . . . . . . . . . . . . . . 24 14. Using "rcd" in SIP . . . . . . . . . . . . . . . . . . . . . 24
14.1. Authentication Service Behavior . . . . . . . . . . . . 24 14.1. Authentication Service Behavior . . . . . . . . . . . . 24
14.2. Verification Service Behavior . . . . . . . . . . . . . 25 14.2. Verification Service Behavior . . . . . . . . . . . . . 25
15. Using "rcd" and "rcdi" as additional claims to other PASSporT 15. Using "rcd" and "rcdi" as additional claims to other PASSporT
extensions . . . . . . . . . . . . . . . . . . . . . . . 26 extensions . . . . . . . . . . . . . . . . . . . . . . . 26
15.1. Procedures for applying "rcd" as claims only . . . . . . 27 15.1. Procedures for applying "rcd" as claims only . . . . . . 27
skipping to change at page 5, line 48 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 each resource referenced as a claim value or as a value within a for each resource referenced by a URI within a claim value (e.g., an
claim value by one or more globally unique URIs (e.g., an image file image file referenced by "jcd" or a jCard referenced by "jcl"). This
referenced by "jcd" or a jCard referenced by "jcl"). This mechanism mechanism is inspired by and based on the W3C Subresource Integrity
is inspired by and based on the W3C Subresource Integrity
specification (http://www.w3.org/TR/SRI/). The second of the specification (http://www.w3.org/TR/SRI/). The second of the
mechanisms uses the capability called JWT Claim Constraints, defined mechanisms uses the capability called JWT Claim Constraints, defined
in [RFC8226] and extended in [I-D.ietf-stir-enhance-rfc8226]. The in [RFC8226] and extended in [RFC9118]. The JWT Claim Constraints
JWT Claim Constraints specifically guide the verifier within the specifically guide the verifier within the certificate used to sign
certificate used to sign the PASSporT for the inclusion (or the PASSporT for the inclusion (or exclusion) of specific claims and
exclusion) of specific claims and their values, so that the content their values, so that the content intended by the signer can be
intended by the signer can be verified to be accurate. 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 11, line 22 skipping to change at page 11, line 22
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", "icn", "jcd", or "jcl" "rcd" claim objects can contain "nam", "apn", "icn", "jcd", or "jcl"
keys as part of the "rcd" JSON object claim value. This keys as part of the "rcd" JSON object claim value. This
specification defines the use of JSON pointer [RFC6901] as a specification defines the use of JSON pointer [RFC6901] as a
mechanism to reference specific "rcd" claim elements. mechanism to reference specific "rcd" claim elements.
In order to facilitate proper verification of the digests and whether
the "rcd" elements or content referenced by URIs were modified, the
input to the digest must be completely deterministic at three points
in the process. First, at the certification point where the content
is evaluated to conform to the application policy and the JWT Claim
Constraints is applied to the certificate containing the digest.
Second, when the call is signed at the Authentication Service, there
may be a local policy to verify that the provided "rcd" claim
corresponds to each digest. Third, when the "rcd" data is verified
at the Verification Service, the verification is performed for each
digest by constructing the input digest string for the element being
verified and referenced by the JSON pointer string.
The procedure for the creation of each "rcd" element digest string
corresponding to a JSON pointer string key is as follows.
1. The JSON pointer either refers to a value that is a part or the
whole of a JSON object or to a string that is a URI referencing
an external resource.
2. For a JSON value, serialize the JSON to remove all white space
and line breaks. The procedures of this deterministic JSON
serialization are defined in [RFC8225], Section 9. The resulting
string is the input for the hash function.
3. For any URI referenced content, the bytes of the body of the HTTP
response is the input for the hash function.
6.1.1. "nam" and "apn" elements 6.1.1. "nam" and "apn" elements
In the case of "nam" and "apn", the only allowed value is a string. In the case of "nam" and "apn", the only allowed value is a string.
For both of these key values an "rcdi" JSON pointer or integrity For both of these key values an "rcdi" JSON pointer or integrity
digest is optional because the direct value is protected by the digest is optional because the direct value is protected by the
signature and can be constrained directly with JWTClaimConstraints. signature and can be constrained directly with JWTClaimConstraints.
If used, the JSON key value referenced by the JSON pointer is the 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 string includes the quotes, so quotes MUST be included to compute the
digest. digest.
6.1.2. "icn" elements 6.1.2. "icn" elements
In the case of "icn", the only allowed value is a URI value. If the In the case of "icn", the only allowed value is a URI value that
URI references externally linked content there would need to be a references an image file. If the URI references externally linked
JSON pointer and digest entry for this value. In order to reference content there would need to be a JSON pointer and digest entry for
the "icn" value for a digest, the JSON pointer string would be "/icn" the content in that linked resource. In order to reference the "icn"
and the digest string would be created using only the string pointed value for a digest, the JSON pointer string would be "/icn" and the
to by that "/apn" following the rules of JSON pointer. Even though digest string would be created using the image file data following
this is probably not the typical case, an "rcdi" JSON pointer or the rules of JSON pointer. Even though this is probably not the
integrity digest is optional if the image value is directly included typical case, an "rcdi" JSON pointer or integrity digest is optional
via a data URI. However, even though the direct value can be if the image value is directly included via a data URI. However,
protected by the signature and can be constrained directly with even though the direct value can be protected by the signature and
JWTClaimConstraints, since the length of the image data is likely can be constrained directly with JWTClaimConstraints, since the
much larger than the integrity digest, this specification would length of the image data is likely much larger than the integrity
recommend the use of the "rcdi" JSON pointer and integrity digest as digest, this specification would recommend the use of the "rcdi" JSON
the constraint value in JWTClaimConstraints over the image data. pointer and integrity digest as the constraint value in
JWTClaimConstraints over the image data.
6.1.3. "jcd" elements 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:
skipping to change at page 12, line 37 skipping to change at page 13, line 28
"nam": "Q Branch Spy Gadgets" "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-tbxXX9mRY2dtss3vNdNkNkt9hrV9N1LqGST2hDlw97I",
"/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"
} }
} }
The use of a JSON pointer and integrity digest for the "jcd" claim The use of a JSON pointer and integrity digest for the "jcd" claim
key and value is optional. The "jcd" value is the directly included key and value is optional. The "jcd" value is the directly included
jCard array and can be protected by the signature and can be jCard array and can be protected by the signature and can be
constrained directly with JWTClaimConstraints. However, for data constrained directly with JWTClaimConstraints. However, for data
skipping to change at page 14, line 4 skipping to change at page 15, line 4
[“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"]
] ]
] ]
In order to facilitate proper verification of the digests and whether
the "rcd" elements or content referenced by URIs were modified, the
input to the digest must be completely deterministic at three points
in the process. First, at the certification point where the content
is evaluated to conform to the application policy and the JWT Claim
Constraints is applied to the certificate containing the digest.
Second, when the call is signed at the Authentication Service, there
may be a local policy to verify that the provided "rcd" claim
corresponds to each digest. Third, when the "rcd" data is verified
at the Verification Service, the verification is performed for each
digest by constructing the input digest string for the element being
verified and referenced by the JSON pointer string.
The procedure for the creation of each "rcd" element digest string
corresponding to a JSON pointer string key is as follows.
1. The JSON pointer either refers to an element that is a part or
whole of a JSON object string or to a string that is a URI
referencing an external resource.
2. For a JSON formatted string, serialize the element JSON to remove
all white space and line breaks. The procedures of this
deterministic JSON serialization are defined in [RFC8225],
Section 9. The resulting string MUST be a Base64 encoded
[RFC4648] digest string (for sha256 this should result in
approximately 44 characters).
3. For any URI referenced content, the content can either be a
string as in jCard JSON objects or binary content. For example,
image and audio files contain binary content. If the URI
referenced content is JSON formatted, follow the procedures
defined in list item 2 above. Either the binary data or string
content of the file is used to create a resulting string which
MUST be a Base64 encoded [RFC4648] digest string (for sha256 this
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 4 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.
skipping to change at page 17, line 30 skipping to change at page 17, line 41
An "rcd" PASSporT that uses claims defined in this specification, in An "rcd" PASSporT that uses claims defined in this specification, in
order 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 * 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 [RFC9118] if present in the certificate
present in the certificate used to sign the PASSporT used to sign the PASSporT
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, relying parties [RFC8225], if any of the above criteria is not met, relying parties
MUST NOT use any of the claims in the PASSporT. MUST NOT use any of the claims in the PASSporT.
9.2. "rcdi" Integrity Verification 9.2. "rcdi" Integrity Verification
If the "rcdi" claim exists, any party that dereferences a URI (i.e. If the "rcdi" claim exists, any party that dereferences a URI (i.e.
downloading content for display to users) from the "rcd" claim MUST downloading content for display to users) from the "rcd" claim MUST
perform integrity validation of the content against the corresponding perform integrity validation of the content against the corresponding
skipping to change at page 20, line 15 skipping to change at page 20, line 15
{ {
"crn": "Rendezvous for Little Nellie", "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"
}, },
"rcdi": { "rcdi": {
"/jcl": "sha256-Gb0lOkj7Z9+plqbOkN32H+YX0Yav3fbioSk7DxQdGZU", "/jcl": "sha256-qCn4pEH6BJu7zXndLFuAP6DwlTv5fRmJ1AFkqftwnCs",
"/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"
} }
} }
An example "rcd" PASSporT that uses "nam" and "icn" keys with "rcdi"
for calling name and referenced icon image content:
{
"crn": "Rendezvous for Little Nellie",
"orig": {"tn": "12025551000"},
"dest": {"tn": ["12155551001"]},
"iat": 1443208345,
"rcd": {
"nam": "Q Branch Spy Gadgets",
"icn": "https://example.com/photos/q-256x256.png"
},
"rcdi": {
"/nam": "sha256-sM275lTgzCte+LHOKHtU4SxG8shlOo6OS4ot8IJQImY",
"/icn": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4",
}
}
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 that Compact form of an "rcd" PASSporT claim has some restrictions that
will be enumerated below, but mainly follows standard PASSporT will be enumerated below, but mainly follows standard PASSporT
compact form procedures. For re-construction of the "nam" claim the compact form procedures. For re-construction of the "nam" claim the
string for the display-name in the From header field. "jcl" and "jcd" string for the display-name in the From header field. "jcl" and "jcd"
MAY NOT be used with compact form due to integrity rules and URI MAY NOT be used with compact form due to integrity rules and URI
reference rules in this specification leading to too restrictive of a reference rules in this specification leading to too restrictive of a
skipping to change at page 30, line 25 skipping to change at page 30, line 38
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
specific claims or contents of claims, it is also important to specific claims or contents of claims, it is also important to
consider potential attacks by non-authorized signers that may include consider potential attacks by non-authorized signers that may include
other potential PASSporT claims that weren't originally vetted by the other potential PASSporT claims that weren't originally vetted by the
authorized entity providing the delegate certificate. The use of JWT authorized entity providing the delegate certificate. The use of JWT
claims constraints as defined in [I-D.ietf-stir-enhance-rfc8226] for claims constraints as defined in [RFC9118] for preventing the ability
preventing the ability to include claims beyond the claims defined in to include claims beyond the claims defined in this document may need
this document may need to be considered. to be considered.
Certificate issuers SHOULD NOT include an entry in mustExclude for Certificate issuers SHOULD NOT include an entry in mustExclude for
the "rcdi" claim for a certificate that will be used with the the "rcdi" claim for a certificate that will be used with the
PASSporT Extension for Rich Call Data defined in this document. PASSporT Extension for Rich Call Data defined in this document.
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-03, 25 October 2021, ietf-sipcore-callinfo-rcd-04, 7 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-sipcore- <https://www.ietf.org/archive/id/draft-ietf-sipcore-
callinfo-rcd-03.txt>. callinfo-rcd-04.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]
Housley, R., "Enhanced JSON Web Token (JWT) Claim
Constraints for Secure Telephone Identity Revisited (STIR)
Certificates", Work in Progress, Internet-Draft, draft-
ietf-stir-enhance-rfc8226-05, 26 July 2021,
<https://www.ietf.org/archive/id/draft-ietf-stir-enhance-
rfc8226-05.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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>.
 End of changes. 21 change blocks. 
86 lines changed or deleted 90 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/