Subject: [stir] Second WGLC: draft-ietf-stir-passport-rcd-10

From: Russ Housley <[email-masked]>
Date: Sat, 13 Mar 2021 15:24:32 -0500

As we discussed yesterday, significant changes were made to address concerns that were raised during the first WGLC.  This note begins a second a WGLC for draft-ietf-stir-passport-rcd-10 (PASSporT Extension for Rich Call Data).

Please send reviews to the STIR mail list by the end of day 28 March 2021.  If you plan to provide a review but need more time, please let us know early.

See <https://datatracker.ietf.org/doc/draft-ietf-stir-passport-rcd/ <https://datatracker.ietf.org/doc/draft-ietf-stir-passport-rcd/>>

Russ and Robert

---

From: Russ Housley <[email-masked]>
Date: Tue, 16 Mar 2021 12:42:57 -0400

I have reviewed the document.  It is in good shape, but I have a few comments.

TECHNICAL:

What happens if the JWTClaimConstraints in the certificate explicitly excludes the "rcdi" claim?

EDITORIAL:

Section 4, 2nd para, says: "... defined to accomplish that ...".  Given the many things discussed in the previous paragraph, please replace "that" with a few words to add clarity.

Section 5.1.2, end of 1st para, says: 'The "jcd" and "jcl" keys should be mutually exclusive.'  Please use a MUST or MUST NOT statement here.

Section 5.1.3, end of 1st para, says: 'The "jcd" and "jcl" keys MUST be used mutually exclusively.'  I suggest: 'The "jcd" and "jcl" claim keys are mutually exclusive; the "jcd" and "jcl" claim keys MUST NOT both be present in the same PASSport.'

NITS:

Section 3:
   s/set of info/information/
   s/extensions to that data./extensions./
   s/on a more frequent, per call, type of basis/with each call/

Section 4:
   s/sufficiently strong cryptographic digest/message digest/

Section 5.2:
   s/crypto algorithm/cryptographic one-way hash function/
   s/by the NIST/by the NIST [FIPS180-4]/

Russ

---

From: Chris Wendt <[email-masked]>
Date: Fri, 19 Mar 2021 11:42:40 -0400

Thanks Russ for the review will take care of editorial/nits, discussion inline:

> On Mar 16, 2021, at 12:42 PM, Russ Housley <[email-masked]> wrote:
> 

Good question, i think the easiest answer is I can’t think of a reason any authoritative certificate creator would want to do that, so question is whether we explicitly say MUST NOT do this normatively somewhere in the document?  I can do that, unless someone can come up with a scenario that excluding “rcdi” claim would be a good thing to do.  To me adding a unauthorized “rcdi” can only confirm the contents that is authorized or break the verification, so not sure there is any possibility of an attack if a “rcdi” is added by delegate signer if it’s not in mustInclude already.

-Chris

> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Russ Housley <[email-masked]>
Date: Fri, 19 Mar 2021 11:45:58 -0400

> Good question, i think the easiest answer is I can’t think of a reason any authoritative certificate creator would want to do that, so question is whether we explicitly say MUST NOT do this normati…

I think a sentence or two in the Security Considerations of draft-ietf-stir-enhance-rfc8226 might be desirable.  It will need a reference to this document to be effective.  That is probably okay.

Russ