Subject: Re: [stir] Third WGLC: draft-ietf-stir-passport-rcd-12

From: Chris Wendt <[email-masked]>
Date: Thu, 9 Sep 2021 20:27:22 -0400

HI Ben,

Thanks for the review!  Comments inline:

> On Aug 13, 2021, at 6:01 PM, Ben Campbell <[email-masked]> wrote:
> 
> (No Hats)
> 
> I have a few comments. The biggest one is I think we need more explanation of verifier behavior for JWTClaimConstraints and RCDi. The rest are pretty minor and hopefully easy to address.
> 
> Thanks!
> 
> Ben.
> 
> Substantive:
> 
> General:
> 
> I still have some questions about expected verifier behavior after multiple passes. I think that the verification service discussion should be expanded to address the following:
> Is a verifier _required_ to verify that all claims are valid according to any JWTClaimConstraints? What does it mean if a given claim violates the constraints? Is the whole ppt considered invalid and discarded? Can relying parties still use parts of the passport that were either not constrained or did not violate the constraints?
> Same questions for RCDi digest verification.
> If RCDi digest verification is optional, does that change if there is a claim constraint on it? 
The simple answer is that we think the entire PASSporT validation should fail if any part of it fails validation either because of signature, JWTConstraint, or rcdi integrity failure.  I will add text to make this clear.

> For an example use case related to these questions. Imagine a SHAKEN environment, where the caller UA signs an RCD passport with a delegate-certificate. The cert has JWTClaimConstraints for the “rcd” and “rcdi” claims. The UA also includes an rcdi claim, because the “rcd” claim points to an external icon.
> 
> The UA forwards the INVITE to an originating service provider (OSP). The OSP doesn’t care what’s in the “rcd” claims. All it wants to do is see that the call is signed with the private key associated with the caller’s certificate and verify that the cert has a TNAuthList extension that encompasses the number in the From header field. If that is true, the OSP adds it’s own SHAKEN passport with full attestation and forwards the INVITE to a Terminating Service Provider (TSP) with both passports.   As far as the OSP is concerned, it’s the TSP’s problem to verify the RCD bits.
> 
> Would the OSP be required to verify the JWTClaimConstraints and RCDi digest in this case? Consider that verifying the RCDI digest probably requires downloading an icon from a potentially arbitrary source, which the OSP might not be willing to do.

I agree that in case of SHAKEN, OSP at a minimum only cares about telephone number for STI-VS and uses the delegate certificate TNAuthList telephone number and ‘orig’/From/Paid to determine attestation level.  That said, i think the mechanics of what OSP or TSP do with a delegate cert is a SHAKEN concept and doesn’t need to be addressed in the ‘rcd’ draft, so i’d prefer to leave that to IPNNI documents.

> 
> §2: So we’re sticking with that RFC 6919 reference? :-)   (But seriously, we should probably us RFC 8174 boilerplate.)

Updated 

> 
> §5.1.1: “This key MUST be included once and MUST be included as part of the "rcd"  claim value JSON object.“
> 
> That second MUST seems non-constraining. I’m not sure where else one might put it.

Removed second MUST

> 
> §6: “implementations MUST support the following hash algorithms, "SHA256", "SHA384", or "SHA512”.”
> Should “or” be “and”?

changed to and

> 
> §6.1, last paragraph (list item 3):
> 
> The previous paragraph requires JSOn serialization for by-value JSON strings. List item 3 does not appear to require serialization of referenced JSON objects. Is that intentional?

Added this: "If the URI referenced content is JSON formatted, follow the procedures defined in list item 2 above."
> 
> Should the “should” in “If the content is binary format it should be Base64 encoded“ be normative?

I actually made it a MUST but also other text was modified/clarified based on comments from Jack R.

> 
> §8.1: Does you envision a use case where one might want to constrain a claim value if it is present, but it’s okay for it to not be present at all?

Yes, i believe that is handled by not having a “mustInclude” for the claim, but having “permittedValues” for the constrained claim value.

> 
> §10.2: “… so if "rcdi" is required compact form should not be used.”
> 
> Should that be a normative SHOULD? Or maybe MUST?

Yes MUST NOT, fixed

> 
> §14.2: “ Optionally, if there exists a Call-Info header field…”
> 
> Is this really “optional”? Is the verifier expected to know whether the AS included information from the Call-Info field in the signature?

Yes, correct, removed word Optionally and replaced with "Additionally"

> 
> §18, last paragraph:
> 
> This recommends that the creator of an rcdi claim “detect evil” on any referenced content, to avoid sending things might be harmful to the verifier. Shouldn’t the verifier also check that? It seems dangerous for the verifier to trust that the sender got this right.
> 
> Along those lines, I wonder if there is something we can reference for server-side request forgery attack mitigation? (I don’t know of anything offhand.)

I put a note at the end to reference that verification services should use precautions to avoid attacks based on accessing URI linked content.

> 
> Editorial:
> 
> §4, first paragraph: “… there should be the desire to pre-certify or "vet" the specific use of rich call data. “
> 
> Is “should” the right word here? Do we mean to suggest that this pre-certification is really something one should do vs something one _might_ do?  (I recognize its not normative, but even a non-normative should carries a moral judgement.)

Changed to might, i think you are right we can’t exactly be normative, even though most applications hopefully would desire vetting of RCD content.

> 
> §5.1.3: “The jCard object value referenced in the URI value for "jcl" MUST only have referenced content for URI values that do not further reference URIs. “
> 
> That’s a little hard to parse—maybe it would be better constructed as a “MUST NOT”?

:) yeah that was a tough sentence, changed to "The jCard object referenced by the URI value for "jcl" MUST NOT contain any further referenced content (i.e. URIs as values in the referenced jCard object)”

> 
> §6.1: “avoid any possibility of substitution or insertion attacks that may be possible to avoid integrity detection, even though unlikely. “
> 
> I suggest avoiding predictions of likelihood here, since we already specify a countermeasure.

Removed 

> 
> 
>> On Jul 29, 2021, at 2:19 PM, Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> As we discussed on the IETF 111 session today, significant changes were made to address concerns that were raised during the second WGLC.
>> 
>> This note begins a third WGLC for draft-ietf-stir-passport-rcd-12 (PASSporT Extension for Rich Call Data).  See https://datatracker.ietf.org/doc/draft-ietf-stir-passport-rcd/ <https://datatracker.ietf.org/doc/draft-ietf-stir-passport-rcd/>.
>> 
>> Please send reviews to the STIR mail list by the end of day 19 August 2021.
>> 
>> Russ and Robert
>> _______________________________________________
>> stir mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/stir
>

---

From: "Gorman, Pierce" <[email-masked]>
Date: Fri, 10 Sep 2021 15:03:34 +0000

§5.1.3: "The jCard object value referenced in the URI value for "jcl" MUST only have referenced content for URI values that do not further reference URIs. "

That's a little hard to parse-maybe it would be better constructed as a "MUST NOT"?

:) yeah that was a tough sentence, changed to "The jCard object referenced by the URI value for "jcl" MUST NOT contain any further referenced content (i.e. URIs as values in the referenced jCard object)"

A jCard is a JSON encoded vCard.  Several parameters and properties of vCard are explicitly URI data type, and for example, in the case of TEL it SHOULD be a URI.

Are you creating a restriction that none of the allowed (and in some cases required) URI data type parameters or properties of a jCard (vCard) referenced from an RCD PASSporT are permitted?

I'm probably ignorant of, or misunderstanding something, so please be kind.  :)

Pierce

From: stir <[email-masked]> On Behalf Of Chris Wendt
Sent: Thursday, September 9, 2021 7:27 PM
To: Ben Campbell <[email-masked]>
Cc: Jon Peterson <[email-masked]>; IETF STIR Mail List <[email-masked]>
Subject: Re: [stir] Third WGLC: draft-ietf-stir-passport-rcd-12

[External]

HI Ben,

On Aug 13, 2021, at 6:01 PM, Ben Campbell <[email-masked]<mailto:[email-masked]>> wrote:

(No Hats)

Thanks!

Ben.

Substantive:

General:

  *   Is a verifier _required_ to verify that all claims are valid according to any JWTClaimConstraints? What does it mean if a given claim violates the constraints? Is the whole ppt considered invalid and discarded? Can relying parties still use parts of the passport that were either not constrained or did not violate the constraints?
  *   Same questions for RCDi digest verification.
  *   If RCDi digest verification is optional, does that change if there is a claim constraint on it?
The simple answer is that we think the entire PASSporT validation should fail if any part of it fails validation either because of signature, JWTConstraint, or rcdi integrity failure.  I will add text to make this clear.

For an example use case related to these questions. Imagine a SHAKEN environment, where the caller UA signs an RCD passport with a delegate-certificate. The cert has JWTClaimConstraints for the "rcd" and "rcdi" claims. The UA also includes an rcdi claim, because the "rcd" claim points to an external icon.

The UA forwards the INVITE to an originating service provider (OSP). The OSP doesn't care what's in the "rcd" claims. All it wants to do is see that the call is signed with the private key associated with the caller's certificate and verify that the cert has a TNAuthList extension that encompasses the number in the From header field. If that is true, the OSP adds it's own SHAKEN passport with full attestation and forwards the INVITE to a Terminating Service Provider (TSP) with both passports.   As far as the OSP is concerned, it's the TSP's problem to verify the RCD bits.

I agree that in case of SHAKEN, OSP at a minimum only cares about telephone number for STI-VS and uses the delegate certificate TNAuthList telephone number and 'orig'/From/Paid to determine attestation level.  That said, i think the mechanics of what OSP or TSP do with a delegate cert is a SHAKEN concept and doesn't need to be addressed in the 'rcd' draft, so i'd prefer to leave that to IPNNI documents.

§2: So we're sticking with that RFC 6919 reference? :-)   (But seriously, we should probably us RFC 8174 boilerplate.)

Updated

§5.1.1: "This key MUST be included once and MUST be included as part of the "rcd"  claim value JSON object."

That second MUST seems non-constraining. I'm not sure where else one might put it.

Removed second MUST

§6: "implementations MUST support the following hash algorithms, "SHA256", "SHA384", or "SHA512"."
Should "or" be "and"?

changed to and

Should the "should" in "If the content is binary format it should be Base64 encoded" be normative?

§8.1: Does you envision a use case where one might want to constrain a claim value if it is present, but it's okay for it to not be present at all?

Yes, i believe that is handled by not having a "mustInclude" for the claim, but having "permittedValues" for the constrained claim value.

§10.2: "... so if "rcdi" is required compact form should not be used."

Yes MUST NOT, fixed

§14.2: " Optionally, if there exists a Call-Info header field..."

Is this really "optional"? Is the verifier expected to know whether the AS included information from the Call-Info field in the signature?

§18, last paragraph:

This recommends that the creator of an rcdi claim "detect evil" on any referenced content, to avoid sending things might be harmful to the verifier. Shouldn't the verifier also check that? It seems dangerous for the verifier to trust that the sender got this right.

Along those lines, I wonder if there is something we can reference for server-side request forgery attack mitigation? (I don't know of anything offhand.)

Editorial:

§4, first paragraph: "... there should be the desire to pre-certify or "vet" the specific use of rich call data. "

Is "should" the right word here? Do we mean to suggest that this pre-certification is really something one should do vs something one _might_ do?  (I recognize its not normative, but even a non-normative should carries a moral judgement.)

Changed to might, i think you are right we can't exactly be normative, even though most applications hopefully would desire vetting of RCD content.

§5.1.3: "The jCard object value referenced in the URI value for "jcl" MUST only have referenced content for URI values that do not further reference URIs. "

That's a little hard to parse-maybe it would be better constructed as a "MUST NOT"?

:) yeah that was a tough sentence, changed to "The jCard object referenced by the URI value for "jcl" MUST NOT contain any further referenced content (i.e. URIs as values in the referenced jCard object)"

§6.1: "avoid any possibility of substitution or insertion attacks that may be possible to avoid integrity detection, even though unlikely. "

Removed

On Jul 29, 2021, at 2:19 PM, Russ Housley <[email-masked]<mailto:[email-masked]>> wrote:

This note begins a third WGLC for draft-ietf-stir-passport-rcd-12 (PASSporT Extension for Rich Call Data).  See https://datatracker.ietf.org/doc/draft-ietf-stir-passport-rcd/<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-stir-passport-rcd%2F&data=04%7C01%7Cpierce.gorman%40t-mobile.com%7Ce4ae20a10484490bbdb108d973f1d02e%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637668304682004296%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6HRJAR7xEH4FU5asHwnBoDspzkqXfRQMstbYtGblWTE%3D&reserved=0>.

Russ and Robert
_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/stir<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&data=04%7C01%7Cpierce.gorman%40t-mobile.com%7Ce4ae20a10484490bbdb108d973f1d02e%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637668304682014288%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TkcfnUee3iuPwUjP9ZA9xySqE6Aif%2BC74OLL2kOZjVg%3D&reserved=0>

---

From: Chris Wendt <[email-masked]>
Date: Fri, 10 Sep 2021 13:16:01 -0400

Hi Pierce,

This is referring only to the URI property value in jCard, not the other properties.  So i think we are good, although maybe i could update it to say “referenced in the “uri” property value” to make it a little clearer, since there is multiple URI references :)

-Chris

> On Sep 10, 2021, at 11:03 AM, Gorman, Pierce <[email-masked]> wrote:
> 
> §5.1.3: “The jCard object value referenced in the URI value for "jcl" MUST only have referenced content for URI values that do not further reference URIs. “ <>
>  
> I’m probably ignorant of, or misunderstanding something, so please be kind.  J
>  
> Pierce
>  
> From: stir <[email-masked] <mailto:[email-masked]>> On Behalf Of Chris Wendt
> To: Ben Campbell <[email-masked] <mailto:[email-masked]>>
> Cc: Jon Peterson <[email-masked] <mailto:[email-masked]>>; IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>
> On Aug 13, 2021, at 6:01 PM, Ben Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>  
> (No Hats)
>  
> This note begins a third WGLC for draft-ietf-stir-passport-rcd-12 (PASSporT Extension for Rich Call Data).  Seehttps://datatracker.ietf.org/doc/draft-ietf-stir-passport-rcd/ <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-stir-passport-rcd%2F&data=04%7C01%7Cpierce.gorman%40t-mobile.com%7Ce4ae20a10484490bbdb108d973f1d02e%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637668304682004296%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6HRJAR7xEH4FU5asHwnBoDspzkqXfRQMstbYtGblWTE%3D&reserved=0>.
> 
> https://www.ietf.org/mailman/listinfo/stir <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&data=04%7C01%7Cpierce.gorman%40t-mobile.com%7Ce4ae20a10484490bbdb108d973f1d02e%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637668304682014288%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TkcfnUee3iuPwUjP9ZA9xySqE6Aif%2BC74OLL2kOZjVg%3D&reserved=0>

---

From: "Gorman, Pierce" <[email-masked]>
Date: Fri, 10 Sep 2021 17:51:07 +0000

Thank you Chris, but I'm still not sure I understand.

Would the example JSON encoding below that includes the vCard "source" and "logo" general and organizational properties respectively be permissible in a jCard referenced from an RCD PASSporT "jcl" URI?

If not, why not?  i.e., what would be the reason(s) for exclusion?

   ["vcard",
     [
       ["version", {}, "text", "4.0"],
       ["fn", {}, "text", "John Doe"],
       ["gender", {}, "text", "M"],
       ["categories", {}, "text", "computers", "cameras"],

       ["logo", {}, "uri", "http://www.example.com/pub/logos/abccorp.jpg"],

       ["source", {}, "uri", "ldap://ldap.example.com/cn=babs%20jensen"]
     ]
   ]

Pierce

From: stir <[email-masked]> On Behalf Of Chris Wendt
Sent: Friday, September 10, 2021 12:16 PM
To: Gorman, Pierce <[email-masked]>
Cc: Ben Campbell <[email-masked]>; IETF STIR Mail List <[email-masked]>; Jon Peterson <[email-masked]>
Subject: Re: [stir] Third WGLC: draft-ietf-stir-passport-rcd-12

[External]

Hi Pierce,

This is referring only to the URI property value in jCard, not the other properties.  So i think we are good, although maybe i could update it to say "referenced in the "uri" property value" to make it a little clearer, since there is multiple URI references :)

-Chris

On Sep 10, 2021, at 11:03 AM, Gorman, Pierce <[email-masked]<mailto:[email-masked]>> wrote:

Pierce

From: stir <[email-masked]<mailto:[email-masked]>> On Behalf Of Chris Wendt
Sent: Thursday, September 9, 2021 7:27 PM
To: Ben Campbell <[email-masked]<mailto:[email-masked]>>
Cc: Jon Peterson <[email-masked]<mailto:[email-masked]>>; IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] Third WGLC: draft-ietf-stir-passport-rcd-12

[External]

HI Ben,

(No Hats)

Thanks!

Ben.

Substantive:

General:

Updated

Removed second MUST

changed to and

Yes MUST NOT, fixed

§18, last paragraph:

Editorial:

Removed

This note begins a third WGLC for draft-ietf-stir-passport-rcd-12 (PASSporT Extension for Rich Call Data).  Seehttps://datatracker.ietf.org/doc/draft-ietf-stir-passport-rcd/<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-stir-passport-rcd%2F&data=04%7C01%7Cpierce.gorman%40t-mobile.com%7Ce4ae20a10484490bbdb108d973f1d02e%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637668304682004296%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6HRJAR7xEH4FU5asHwnBoDspzkqXfRQMstbYtGblWTE%3D&reserved=0>.

Russ and Robert

---

From: Chris Wendt <[email-masked]>
Date: Fri, 10 Sep 2021 14:04:45 -0400

We allow one level of URI, like your example, but we don’t want recursive levels of URI indirection which delves into security issues and complexity we don’t want to address in the specification now, and don’t believe there is really a use case for currently.  For example, we don’t want people to point to an HTML page that includes links to javascript and CSS and other content, or other similar use-cases.

-Chris

> On Sep 10, 2021, at 1:16 PM, Chris Wendt <[email-masked]> wrote:
> 
> Hi Pierce,
> 
>> On Sep 10, 2021, at 11:03 AM, Gorman, Pierce <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Chris Wendt <[email-masked]>
Date: Fri, 10 Sep 2021 14:20:16 -0400

And of course, right after i give that example :)  Apologize, i confused myself, it is URI values more generally that are allowed to exist in the card, it’s just the content that they reference should not have any URI references as part of that content.  But of course, there is an exception, which is ‘url’ property in jcard, which is intended to be used by end user to point specifically to a webpage and the sipcore-callinfo document has the necessary caveats about that.  But the main reason we don’t want to deal with recursive URIs is for security, complexity as stated before, in particular with the integrity/‘rcdi’.

I will review the language again to make sure that’s clearer, but of course other comments are welcome.

> On Sep 10, 2021, at 2:04 PM, Chris Wendt <[email-masked]> wrote:
> 
>> On Sep 10, 2021, at 1:16 PM, Chris Wendt <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Pierce,
>>

---

From: "Gorman, Pierce" <[email-masked]>
Date: Fri, 10 Sep 2021 18:36:34 +0000

OK.  That helps.  Thank you Chris.  I remember there was discussion about deprecating URIs which referenced objects which themselves included URIs, and if that's what that language was intended to convey, I understand, but also agree that stating that more clearly as you did here could be helpful.

Pierce

Sent: Friday, September 10, 2021 1:20 PM

[External]

And of course, right after i give that example :)  Apologize, i confused myself, it is URI values more generally that are allowed to exist in the card, it's just the content that they reference should not have any URI references as part of that content.  But of course, there is an exception, which is 'url' property in jcard, which is intended to be used by end user to point specifically to a webpage and the sipcore-callinfo document has the necessary caveats about that.  But the main reason we don't want to deal with recursive URIs is for security, complexity as stated before, in particular with the integrity/'rcdi'.

I will review the language again to make sure that's clearer, but of course other comments are welcome.

On Sep 10, 2021, at 2:04 PM, Chris Wendt <[email-masked]<mailto:[email-masked]>> wrote:

We allow one level of URI, like your example, but we don't want recursive levels of URI indirection which delves into security issues and complexity we don't want to address in the specification now, and don't believe there is really a use case for currently.  For example, we don't want people to point to an HTML page that includes links to javascript and CSS and other content, or other similar use-cases.

-Chris

On Sep 10, 2021, at 1:16 PM, Chris Wendt <[email-masked]<mailto:[email-masked]>> wrote:

Hi Pierce,

-Chris

Pierce

[External]

HI Ben,

(No Hats)

Thanks!

Ben.

Substantive:

General:

Updated

Removed second MUST

changed to and

Yes MUST NOT, fixed

§18, last paragraph:

Editorial:

Removed

Russ and Robert

---

From: Ben Campbell <[email-masked]>
Date: Sat, 11 Sep 2021 17:39:52 -0500

Hi

Comments inline. I’ve removed sections that don’t seem to need further discussion.

> On Sep 9, 2021, at 7:27 PM, Chris Wendt <[email-masked]> wrote:
> 
> HI Ben,
> 

[…]

> The simple answer is that we think the entire PASSporT validation should fail if any part of it fails validation either because of signature, JWTConstraint, or rcdi integrity failure.  I will add t…

The new text in version 13 is helpful. But it seems to say the passport MUST abide by claim construction rules OR JWT Claim Constraints OR pass integrity verification. Were those meant to be AND?

I also note the new text doesn’t mention signature verification—but I’m willing to believe that goes without saying.

Also see comments below re: SHAKEN use case.

> I agree that in case of SHAKEN, OSP at a minimum only cares about telephone number for STI-VS and uses the delegate certificate TNAuthList telephone number and ‘orig’/From/Paid to determine attesta…

I agree we should not define SHAKEN semantics in STIR. But I think we need to avoid precluding expected SHAKEN behavior without a good reason.

From the new text in §9.1, I understand that in the example of an RCD PASSporT with an rcdi claim that covers content included by reference, a VS MUST verify the RCDi claim, which requires it to download the external content. At least for “ppt”:“rcd”. And and the AS that inserted the rcd passport MUST include the RCDi claim, due to the external content. 

Am I reading that right? If so, in the SHAKEN OSP example above, do you think it is reasonable to make the OSP download and verify an icon it will never use for potentially every call it processes? I fear that might be a barrier to the idea of an OSP using the TnAuthList from a delegate cert for SHAKEN attestation purposes. At least for RCD passports that reference logos and such.

OTOH, I realize that the idea of a partially-verified passport might be tricky to implement safely, so that nothing downstream of a VS accidentally relies on unverified claims.

[…]

> Yes, i believe that is handled by not having a “mustInclude” for the claim, but having “permittedValues” for the constrained claim value.

Both section 6.2 and 8.1 say “mustInclude” must be included. (So does 7, but leaving out “mustInclude” probably makes less sense there.)

[…]

---

From: Chris Wendt <[email-masked]>
Date: Mon, 13 Sep 2021 08:36:47 -0400

Inline

> On Sep 11, 2021, at 6:39 PM, Ben Campbell <[email-masked]> wrote:
> 
> Hi
> 
>> On Sep 9, 2021, at 7:27 PM, Chris Wendt <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> HI Ben,
>> 

Yeah, thanks, changed it to this format to make it a little clearer:
"A PASSporT that uses claims defined in this specification, in order to have a successful verification outcome, MUST conform to the following:

  * abide by all rules set forth in the proper construction of the claims 
  * abide by JWT Claims Constraint rules defined in {{RFC8226}} Section 8 or extended in {{I-D.ietf-stir-enhance-rfc8226}} if present in the certificate used to sign the PASSporT 
  * pass integrity verification using "rcdi" if present.  "

> OTOH, I realize that the idea of a partially-verified passport might be tricky to implement safely, so that nothing downstream of a VS accidentally relies on unverified claims.

RFC8225 does have the rule that you can ignore claims you don’t understand, and i think for ’shaken’ specifically, we don’t have a PASSporT extension type that includes both ’shaken’ claims and ‘rcd’ claims, even though people have talked about putting both in a single PASSporT, so i think we are ok.  I just feel uncomfortable trying to “cross the streams” and cover other extension types in this spec. Would we expect all future specs to cover every combination of claims/extension types?  I still think that is left for IPNNI type specs to define more specific usage.

Put more simply, this spec is about “rcd” PASSporT rules, using “rcd” claims in another PASSporT type is not in scope for this spec.

> Both section 6.2 and 8.1 say “mustInclude” must be included. (So does 7, but leaving out “mustInclude” probably makes less sense there.)

Changed wording to 

6.2
"For the third mode described in the integrity overview section of this document, where only JWT Claim Constraint for "rcd" claims without an "rcdi" claim is required, the procedure should be when creating the certificate and the intent is to always include an "rcd" claim, to include a JWT Claim Constraint on inclusion of an "rcd" claim with the intended values required to be constrained by the certificate used to sign the PASSporT.

The "permittedValues" for the "rcd" claim may optionally contain multiple entries, to support the case where the certificate holder is authorized to use different sets of rich call data.

Only including "permittedValues" for "rcd" provides the ability to either have no "rcd" claim or only the set of constrained "permittedValues" values for an included "rcd" claim.”

8.1

“If the intent of the issuer of the certificate is to always including a call reason, a "mustInclude" for the "crn" claim indicates that a "crn" claim must be present."

---

From: Ben Campbell <[email-masked]>
Date: Mon, 13 Sep 2021 09:41:10 -0500

> On Sep 13, 2021, at 7:36 AM, Chris Wendt <[email-masked]> wrote:
> 
>>> 
>>> 

Unless I misunderstand what people have in mind, the use case doesn’t involve mixing rcd and shaken claims in a single PPT. To be more precise:

1. Caller AS signs an passport with a delegate cert. with “ppt” : “rcd”. It includes an RCD claim with external references, and therefore an “rcdi” claim.
2. OSP VS verifies the RCD passport and checks that the “orig” claim is encompassed by the cert's TnAuthList. It wants to ignore the RCD claims because it doesn’t care about them, but IIUC it cannot ignore them because of the “rcd” value in “ppt”.
3. OSP AS inserts a SHAKEN passport, with an attestation level (hopefully A), based on the results of step 2.
4. OSP forwards the INVITE with both the SHAKEN and RCD passport.

The way I understand things, step 2 will require verification of the rcdi claim, and therefore downloading of the external content. Am I missing something? 

I think this means the caller is using the same passport for two purposes (authentication, RCD assertion) with two separate relying parties (OSP, TSP or recipient), Is this an invalid approach? I’m willing to accept that one should not do this, but I think it will surprise some consumers of the spec. I recognize this is not the only approach people are thinking about (e.g. the OSP might verify the RCD claims and insert them into its SHAKEN ppt.)

Thanks!

Ben.

---

From: Chris Wendt <[email-masked]>
Date: Mon, 13 Sep 2021 14:47:05 -0400

inline

> On Sep 13, 2021, at 10:41 AM, Ben Campbell <[email-masked]> wrote:
> 
> 
> 
>> On Sep 13, 2021, at 7:36 AM, Chris Wendt <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>>> 
>>>> 

Ok, that clarifies the use-case, but i think i still would like to stay a level higher. Focus on the security (and integrity) and not give excuses for half-steps or “optimizations”.  If the “identity” includes RCD information with integrity turned on encoded in a PASSporT, you should have to decode the entire PASSporT to achieve pass/fail. Otherwise, we get into some thorny scenarios, IMHO.
Like i said before (even though i misunderstood your use-case), I think you provide one example on how the industry might implement this, but i could imagine others.  But, however things turn out, i don’t think we should change the fundamental rules of we have already established or create shortcuts in the protocol specifications.  RCD is fundamentally not about “A” attestation, although as we have said it’s a side benefit, that said, i would hate to cripple things for a shortcut or potentially create a hole.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 13 Sep 2021 13:52:58 -0500

> On Sep 13, 2021, at 1:47 PM, Chris Wendt <[email-masked]> wrote:
> 
> inline
> 
>> On Sep 13, 2021, at 10:41 AM, Ben Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> 

Just to be clear, I agree we should stay at a higher level in the spec. I think from a higher level, the rules that would allow the use case I mentioned would be to say something like the VS MUST verify the signature and that any JWT Claim Constraints are satisfied, and MUST NOT rely on integrity-protected RCD claims without verifying the rcdi claim.

I’m perfectly okay if the answer is still “verify everything or rely on nothing”; I’m just probing to make sure we have considered how this will be used in practice.

Thanks!

Ben.

---

From: Chris Wendt <[email-masked]>
Date: Mon, 13 Sep 2021 14:57:54 -0400

> On Sep 13, 2021, at 2:52 PM, Ben Campbell <[email-masked]> wrote:
> 
> 
> 
>> On Sep 13, 2021, at 1:47 PM, Chris Wendt <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> inline
>> 

Right, understood, I think the integrity was included for a specific purpose, one that is a non-trivial part of the overall “identity” of the caller so it should still be considered in verification. Open to hearing others opinion and we can discuss in few minutes, but i don’t want to give up on that lightly :)  But, as you said, good to talk about it explicitly, so glad you are bringing it forward.