Enhanced JSON Web Token (JWT) Claim Constraints for Secure Telephone Identity Revisited (STIR) Certificates
draft-ietf-stir-enhance-rfc8226-05

[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...

I support Ben Kaduk's DISCUSS on refining the language around the possibility of both of these extension co-existing.

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...

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).

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".

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.

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