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

From: Russ Housley <[email-masked]>
Date: Mon, 2 Aug 2021 11:55:46 -0400

I have a few comments.  All of them are pretty minor.

In the Abstract, it says: '... subsequently rendered to the intended called party.'  I think it is rendered to the called party, whether that party is intended or otherwise.

In Section 6.2, first paragraph, it says: '... contents of the certified "rcd" claim.'  I do not know what 'certified' means here.  To me, it usually means that it is included in a certificate, but that is not the meaning here.  Please clarify.

In Section 7, first paragraph, it refers to a 'STIR certificate eco-system'.  I think this can be simplified by just saying that the 'authorized party' is not necessarily the subject of a STIR certificate,

In Section 12.1, first paragraph, the term 'Subject Name' is used several times.  The certificate has a subject field that contains a name, but it does nt have a Subject Name field.  Please reword.

In Section 18, second paragraph, the IESG approval of [I-D.housley-stir-enhance-rfc8226] required the addition of a SHOULD NOT statement:

   Certificate issuers SHOULD NOT include an entry in mustExclude for
   the "rcdi" claim for a certificate that will be used with the
   PASSporT Extension for Rich Call Data defined in
   [I-D.ietf-stir-passport-rcd].  Excluding this claim would prevent the
   integrity protection mechanism from working properly.

It seems that a SHOULD NOT statement should appear here as well.

In Section 18.1, please reference draft-ietf-stir-enhance-rfc8226 (not draft-housley-stir-enhance-rfc8226).

Russ

> On Jul 29, 2021, at 3:19 PM, Russ Housley <[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/.
> 
> Please send reviews to the STIR mail list by the end of day 19 August 2021.
> 
> Russ and Robert
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Chris Wendt <[email-masked]>
Date: Mon, 2 Aug 2021 15:16:54 -0400

Hi Russ,

Thanks for the comments! Will integrate fixes into next version, but will give a little more time for other comments to come in.

-Chris

> On Aug 2, 2021, at 11:55 AM, Russ Housley <[email-masked]> wrote:
>

---

From: Ben Campbell <[email-masked]>
Date: Fri, 13 Aug 2021 17:01:48 -0500

(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? 
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.

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

§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.

§6: “implementations MUST support the following hash algorithms, "SHA256", "SHA384", or "SHA512”.”
Should “or” be “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?

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?

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

Should that be a normative SHOULD? Or maybe MUST?

§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.)

§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”?

§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.

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

---

From: Ben Campbell <[email-masked]>
Date: Wed, 18 Aug 2021 15:42:27 -0500

Just a reminder—this WGLC ends at the end of day on 19 August. That’s tomorrow. If you plan to send feedback, please do so really soon now.

Thanks!

Ben.