Thank you Theresa. Russ also said a new numbered RFC updating 8226, but I appreciate the additional procedural detail you provide. You've both answered my question. Thank you.
Best regards, Pierce -----Original Message----- From: Theresa Enghardt <i...@tenghardt.net> Sent: Friday, June 11, 2021 12:39 PM To: Gorman, Pierce <pierce.gor...@t-mobile.com> Cc: draft-ietf-stir-enhance-rfc8226....@ietf.org; IETF Gen-ART <gen-art@ietf.org>; IETF STIR Mail List <s...@ietf.org>; last-c...@ietf.org; Russ Housley <hous...@vigilsec.com> Subject: Re: [Last-Call] [stir] Genart last call review of draft-ietf-stir-enhance-rfc8226-02 [External] Dear Pierce, Once published, this I-D will result in a new numbered RFC, which updates 8226. Note that this is exactly the procedure to issue an RFC 8226bis (i.e., a -bis document is always a new numbered RFC, and the published RFC 8226 does not change). Apologies if I misunderstood your question or if I'm missing any relevant context such as other drafts in the STIR WG etc, in which case I'd ask Russ and/or other STIR folks to chime in. Best, Theresa On 6/8/21 2:13 PM, Gorman, Pierce wrote: > Russ and Theresa, > > Please forgive my ignorance, but is the intent to issue an RFC 8226bis? Or > is the intent that the I-D result in a new numbered RFC which updates 8226? > > >From reading various things I've learned, I think, that new RFCs and updates > >to existing RFCs begin life as an Internet-Draft which may or may not be > >adopted by a working group as a work item. If adopted by the group, the > >author/editor continues development of the I-D until such time as it expires > >or is promoted to last call, et cetera. The end result in many cases are > >new numbered RFCs which may obsolete or update existing RFCs as appropriate. > > The STIR RFC 4474 had a 4474bis version that remained unchanged for some > >years before being obsoleted by RFC 8224 for which it was a conceptual > >foundation and that is now a key component of the STIR/SHAKEN set of > >standards required to be used by US VoIP service providers by law and > >federal mandate. > > The reason I ask was because of some of the conversation at the last (I > think) interim meeting and on the e-mail distribution where proposed changes > were suggested to be submitted as a new I-D. This -02 version may be the > same sort of thing but confusion/ignorance on my part about naming and > procedures made me want to ask. > > Respectfully, > > Pierce Gorman > > -----Original Message----- > From: stir <stir-boun...@ietf.org> On Behalf Of Russ Housley > Sent: Saturday, June 5, 2021 3:18 PM > To: Theresa Enghardt <i...@tenghardt.net> > Cc: draft-ietf-stir-enhance-rfc8226....@ietf.org; IETF Gen-ART > <gen-art@ietf.org>; last-c...@ietf.org; IETF STIR Mail List > <s...@ietf.org> > Subject: Re: [stir] [Last-Call] Genart last call review of > draft-ietf-stir-enhance-rfc8226-02 > > [External] > > > 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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fgen%2Fwiki%2FGenArtfaq&data=04%7C01%7Cpierce.gorman%40t-mobile.com%7C40491250c2394836923608d9285f1574%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637585211113043953%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QbFtT%2FIZ0CUXQB%2B0LUm3zIzgWqQQ%2BTk%2BNUJtuJelda8%3D&reserved=0>. >> >> 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 > > _______________________________________________ > stir mailing list > s...@ietf.org > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > ietf.org%2Fmailman%2Flistinfo%2Fstir&data=04%7C01%7Cpierce.gorman%40t-mobile.com%7C40491250c2394836923608d9285f1574%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637585211113054217%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ITvmEkX683nmfZ4HH8owXKlroFxBDV8LtXkqvre3Co0%3D&reserved=0 > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
