Subject: [stir] Benjamin Kaduk's No Objection on draft-ietf-stir-enhance-rfc8226-04: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Sat, 03 Jul 2021 10:50:27 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-stir-enhance-rfc8226-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-stir-enhance-rfc8226/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.

---

From: Russ Housley <[email-masked]>
Date: Sat, 3 Jul 2021 15:40:06 -0400

Thanks for the careful reading.  I have made these edits:

6.  Guidance to Certification Authorities

   The EnhancedJWTClaimConstraints extension specified in this document
   and the JWTClaimConstraints extension specified in [RFC8226] MUST NOT
   both appear in the same certificate.

   If the situation calls for mustExclude constraints, then the
   EnhancedJWTClaimConstraints extension is the only extension that can
   express the constraints.

   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 support for the EnhancedJWTClaimConstraints extension
   becomes widely implemented, the use of the JWTClaimConstraints
   extension may be more likely to be supported.  This guess is based on
   the presumption that the first specified extension will be
   implemented more widely in the next few years.

I will not post a new version until IANA assigns the object identifiers.  I need to update the example in Section 5 and the ASN.1 in Appendix A once the OIDs are assigned.

Russ