The document will get a new RFC number. Russ
> On Jun 8, 2021, at 5:13 PM, Gorman, Pierce <[email protected]> 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 <[email protected]> On Behalf Of Russ Housley > Sent: Saturday, June 5, 2021 3:18 PM > To: Theresa Enghardt <[email protected]> > Cc: [email protected]; IETF Gen-ART > <[email protected]>; [email protected]; IETF STIR Mail List <[email protected]> > 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 > [email protected] > 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 > > -- > last-call mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/last-call _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
