Theresa: Thanks for your thoughtful review. See my responses in-line. I'll post an updated I-D when IETF Last Call ends. > Reviewer: Theresa Enghardt > Review result: Ready with Issues > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-stir-enhance-rfc8226-02 > Reviewer: Theresa Enghardt > Review Date: 2021-06-04 > IETF LC End Date: 2021-06-10 > IESG Telechat date: Not scheduled for a telechat > > Summary: The draft is basically ready for publication as a Standards Track RFC, > but it has some clarity issues that need to be addressed before publication. > > Major issues: None. > > Minor issues: > > Abstract: > > Please expand JWT on first use. > Assuming PASSporT is an acronym, please expand it on first use. > The phrase "STIR certificates" appears in the title, but is not used in the > abstract, introduction, or the draft in general. Is this intentional? Is STIR > the same as PASSporT, in which case it could be replaced? How about the replacement Abstract: RFC 8226 specifies the use of certificates for Secure Telephone Identity Credentials, and these certificates are often called "STIR Certificates". RFC 8226 provides a certificate extension to constrain the JSON Web Token (JWT) claims that can be included in the Personal Assertion Token (PASSporT) as defined in RFC 8225. If the PASSporT signer includes a JWT claim outside the constraint boundaries, then the PASSporT recipient will reject the entire PASSporT. This document updates RFC 8226 to define an additional way that the JWT claims can be constrained. > Section 1: Introduction > > "Section 8 of [RFC8226] provides a certificate extension to constrain > the JWT claims that can be included in the PASSporT [RFC8225]. If > the signer includes a JWT claim outside the constraint boundaries, > then the recipient will reject the entire PASSporT." > > That's basically copied straight out of the Abstract (or the other way round). > Please provide some basic context for those who are not deeply involved with > JWT/PassporT. I do think that it makes sense to expand the Introduction to say more about STIR certificates, but I do not think that the Introduction should repeat too much of RFC 8226. > For example: > - How does establishing authority over telephone numbers work, broadly? Does > establishing authority mean that certifying that a telephone number belongs to, > say, a specific organization? Or does anything happen "over" something > telephony-related, as in some VoIP technology? (The "over telephone numbers" is > ambiguous on first read.) - Is the PASSPorT a set of certificates or something > else? Are these X.509 certificates or some other kind of certificates? Is the > technology described in this doc independent of the format of the certificate? > - Does the actual process of "establishing authority" happen over, e.g., a Web > API? Are there other ways? Is the technology described here specific to some > way of "establishing authority"? - What is JWT and what are JWT claims? - Are > JWT claim constraints provided in the certificate (PASSportT?) or are they > communicated separately? Who provides them? The draft later talks about CA, > authentication service, verification service - It would be good to briefly name > these actors in the Introduction already and briefly describe to whom the > change in this doc applies. Is this enough? The use of certificates [RFC5280] in establishing authority over telephone numbers is described in [RFC8226]. These certificates are often called "STIR Certificates". STIR certificates are an important element of the overall system that prevents the impersonation of telephone numbers on the Internet. Section 8 of [RFC8226] provides a certificate extension to constrain the JSON Web Token (JWT) claims that can be included in the Personal Assertion Token (PASSporT) [RFC8225]. If the PASSporT signer includes a JWT claim outside the constraint boundaries, then the PASSporT recipient will reject the entire PASSporT. This document defines an enhanced JWTClaimConstraints certificate extension, which provides all of the capabilities available in the original certificate extension as well as an additional way to constrain the allowable JWT claims. That is, the enhanced extension can provide a list of claims that are not allowed to be included in the PASSporT. > Please consider adding a brief explanation why further constraints on PASSporT > claims may be necessary. I suggest two additional paragraphs at the end of the above Introduction: The Enhanced JWT Claim Constraints certificate extension is needed to limit the authority when a parent STIR certificate delegates to a subordinate STIR certificate. For example, [I-D.ietf-stir-cert-delegation] describes the situation where service providers issue a STIR certificate to enterprises or other customers to sign PASSporTs, and the Enhanced JWT Claim Constraints certificate extension can be used to prevent specific claims from being included in PASSporTs and accepted as valid by the PASSporT recipient. The JWT Claim Constraints certificate extension defined in [RFC8226] provides a list of claims that must be included in a valid PASSporT as well as a list if permitted values for selected claims. The Enhanced JWT Claim Constraints certificate extension defined in this document includes those capabilities and adds a list of claims that must not be included in a valid PASSporT. > Section 3: Enhanced JWT Claim Constraints Syntax > > "The Enhanced JWT Claim Constraints certificate extension limits the > PASSporT claims and the claim values that can successfully validated > by the certificate that contains the extension." > Are the claims and claim values validated BY the certificate? Aren't they > validated by some recipient, e.g., a verification service? (A similar statement > appears in Section 7: "[…] some combinations can prevent any PASSporT from > being successfully validated by the certificate.") Addressing comments below changed this part of Section 3. More on Section 7 below. > "Certificate issuers > permit all claims by omitting the Enhanced JWT Claim Constraints > certificate extension from the extension field of the certificate > [RFC5280]. The certificate extension is non-critical, applicable > only to end-entity certificates, and defined with ASN.1 [X.680]. The > syntax of the JWT claims in a PASSporT is specified in [RFC8225]." > As this paragraph defines the scope of the extension, it seems misplaced under > "Enhanced JWT Claim Constraints Syntax" as it's not describing the actual > syntax. Maybe either some of this text should be moved to "Introduction", or a > new section could be added, e.g., titled "Scope of Enhanced JWT Claim > Constraints"? As you can see above, I moved some of this to the end of the Introduction. This part remains: The Enhanced JWT Claim Constraints certificate extension is non- critical, applicable only to end-entity certificates, and defined with ASN.1 [X.680]. The syntax of the JWT claims in a PASSporT is specified in [RFC8225]. > The section then goes on to describe constraints. What is the difference > between the described constrains and RFC 8226, i.e., what is added by this doc? I think that is now answered by the last paragraph of the Introduction. > Section 7: Security considerations > > "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." > Is this supposed to be a normative SHOULD? If it is, perhaps it should be moved > up to, e.g., Section 3. I do not think so. I have been coordinating with the authors of draft-ietf-stir-passport-rcd, and both documents will warn implementers about the situation. > Several paragraphs here describe scenarios that prevent successful validation > of any PASSporT. What is the specific security risk here, e.g., Denial of > Service? Any other consequences? Could there be a possibility for, e.g., a > malicious actor introducing constraints that prevent successful validation? Are > any (other) attacks possible on this technology (e.g., malicious deletion of > constraints, replay attacks), and what countermeasures exist? If the malicious actors can sign certificates, then these constraints will be the least of the worries. I think that is covered by the pointer to RFC 5280. > Nits/editorial comments: > > Section 3: Enhanced JWT Claim Constraints Syntax > > OLD: "[…] the claim values that can successfully validated by the certificate > […]" NEW: "[…] the claim values that can be successfully validated by the > certificate […]" (And/or rephrase sentence, see comment above) Addressing above comments changed this part of Section 3. > Section 4: Usage Examples > > OLD: "If a CA issues to an authentication service certificate that > includes an Enhanced JWT Claim Constraints certificate extension […]" > Is this either: > NEW: "If a CA issues to an authentication service a certificate that > includes an Enhanced JWT Claim Constraints certificate extension […]" > Or is it: > NEW: "If a CA issues an authentication service certificate that > includes an Enhanced JWT Claim Constraints certificate extension […]" > (This sentence is very long and not easy to parse in general, maybe it can be > rephrased or split?) It is "If a CA issues a certificate to an authentication service ,,," I got rid of the semicolon, and made two sentences. > Section 7: Security Considerations > > This paragraph appears twice, unless I'm missing a subtle difference: > " Certificate issuers must take care when imposing constraints on the > PASSporT claims and the claim values that can successfully validated; > some combinations can prevent any PASSporT from being successfully > validated by the certificate. For example, an entry in mustInclude > and an entry in mustExclude for the same claim will prevent > successful validation on any PASSporT." Good catch. I deleted one of them. Russ -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
