Enhanced JSON Web Token (JWT) Claim Constraints for Secure Telephone Identity Revisited (STIR) Certificates
RFC 9118
Yes
No Objection
Note: This ballot was opened for revision 03 and is now closed.
Murray Kucherawy Yes
Alvaro Retana No Objection
Erik Kline No Objection
[S4] [comment] * Given the example in section 5, it seems that mustInclude can be used in conjunction with permittedValues. Perhaps amend the last sentence of the 2nd example to indicate this? "However, a verification service will not treat as invalid a PASSporT it receives without a PASSporT "confidence" claim at all (unless also appearing in a mustInclude claim)." or something...
Francesca Palombini No Objection
John Scudder No Objection
Robert Wilton No Objection
Hi, Thanks for the document, despite not being my area of expertise I found it easy to read and understand. A couple of minor comments: (1) Like Erik, when reading section 4, I was wondering whether it would be helpful to have an example that included both mustInclude and permittedValues. But of course, I note that you effectively do that in section 5. (2) In the security section, it states: 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. I was wondering whether it would be helpful to include this as RFC 2119 SHOULD NOT in 3, or perhaps have a forward reference from the section 3 description of mustExclude to the "rcdi" consideration in the security section. Regards, Rob
Roman Danyliw No Objection
I support Ben Kaduk's DISCUSS on refining the language around the possibility of both of these extension co-existing.
Warren Kumari No Objection
Hey, look! A document talking about two technologies I know nothing about - JWT, and certif... Three technologies I know nothing about, JWT, certificates and STIR...
Zaheduzzaman Sarker No Objection
Thanks for the effort here.
I have one single comments or clarification question -
* Section 4:
If a CA issues a certificate to an authentication service that
includes an Enhanced JWT Claim Constraints certificate extension
that contains the permittedValues JWTClaimName "confidence" and a
permitted "high" value, then a verification service will treat as
invalid any PASSporT it receives with a PASSporT "confidence"
claim with a value other than "high". However, a verification
service will not treat as invalid a PASSporT it receives without a
PASSporT "confidence" claim at all.
Please clarify why a PASSporT is not invalid as described in the last sentence of be above bullet. I think it is supposed to be clear by preceding section, however, it is not (at least to me).
Éric Vyncke No Objection
Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated). I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Abstract -- "This document updates RFC 8226 to define an additional way that the JWT claims can be constrained" at first sight, it is unclear whether the change adds a constraints or present another set of constraints (may be it is being non-ENglish native issue...) The introduction clarifies the ambiguity but the abstract should stand alone. -- Section 3 -- Suggest to be consistent with the use of double quotes in <to the iat, orig, and dest claims. The baseline PASSporT claims ("iat", "orig", and "dest")>. -- Section 7 -- Wondering whether a reference to RFC4949 is required for "renewal".
(Benjamin Kaduk; former steering group member) (was Discuss) No Objection
Thanks for the updates in the -04; they address all my comments well. Just one editorial note on the new Section 6: On the other hand, if the situation does not call for mustExclude constraints, then either the EnhancedJWTClaimConstraints extension or the JWTClaimConstraints extension can express the constraints. Until such time as the EnhancedJWTClaimConstraints become widely For singular/plural match, I think "becomes" is better. I'd also consuder "such time as support for the EnhancedJWTClaimConstraints extension becomes widely implemented". implemented, the use of the JWTClaimConstraints extension may be more likely to be implemented. This guess is based on the presumption "use of ... may be more likely to be implemented" is an unusual construction. I think "use of ... may be more likely to succeed" or "the [extension] may be more likely to be implemented" would be more typical. that the first specified extension will be implemented more widely in the next few years.