Last Call Review of draft-ietf-stir-enhance-rfc8226-02
review-ietf-stir-enhance-rfc8226-02-genart-lc-enghardt-2021-06-04-00

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://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

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?

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.

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.

Please consider adding a brief explanation why further constraints on PASSporT
claims may be necessary.

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

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

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?

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.

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?

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)

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

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