Re: [stir] Éric Vyncke's No Objection on draft-ietf-stir-enhance-rfc8226-03: (with COMMENT)

[Russ Housley <[e-mail]>]

> On Jun 25, 2021, at 11:04 AM, Éric Vyncke via Datatracker <[e-mail]> wrote:
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-stir-enhance-rfc8226-03: 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:
> ----------------------------------------------------------------------
> 
> 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.

Does this updated Abstract resolve your non-blocking concern?

   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; it provides all of the
   capabilities available in the original certificate extension as well
   as an additional way to constrain the allowable JWT claims.  The
   enhanced extension can also provide a list of claims that are not
   allowed to be included in the PASSporT.

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

This was raised during Last Call, and the current quotes are consistent with RFC 8225 and RFC 8226.

> -- Section 7 --
> Wondering whether a reference to RFC4949 is required for "renewal".

Someone asked to a reference at some point along the way.  There are other early documents from the PKIX WG that also define the term, but RFC 4949 seemed to have the least baggage.

Russ