Re: [stir] Benjamin Kaduk's Discuss on draft-ietf-stir-enhance-rfc8226-03: (with DISCUSS and COMMENT)

Russ Housley <> Tue, 29 June 2021 15:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BB7213A376C for <>; Tue, 29 Jun 2021 08:22:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id n_H5tdZHkUH4 for <>; Tue, 29 Jun 2021 08:22:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7A3A33A376D for <>; Tue, 29 Jun 2021 08:22:12 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2E5CE300BF8 for <>; Tue, 29 Jun 2021 11:22:11 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id Ag5NqB1FDmaf for <>; Tue, 29 Jun 2021 11:22:05 -0400 (EDT)
Received: from a860b60074bd.fios-router.home ( []) by (Postfix) with ESMTPSA id A034D300B50; Tue, 29 Jun 2021 11:22:04 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
From: Russ Housley <>
In-Reply-To: <>
Date: Tue, 29 Jun 2021 11:22:04 -0400
Cc: IESG <>, IETF STIR Mail List <>, Ben Campbell <>, Robert Sparks <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Ben Kaduk <>
X-Mailer: Apple Mail (2.3445.104.21)
Archived-At: <>
Subject: Re: [stir] Benjamin Kaduk's Discuss on draft-ietf-stir-enhance-rfc8226-03: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Secure Telephone Identity Revisited <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Jun 2021 15:22:15 -0000


Turning to the comments ...

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> As a standalone description of a certificate extension this document is
> in good shape; the main complication that doesn't seem covered is
> (per the Discuss) the interaction with the preexisting extension.
> Section 3
>   3.  mustExclude indicates JWT claims that MUST NOT appear in the
>       PASSporT.  The baseline PASSporT claims ("iat", "orig", and
>       "dest") are always permitted, and these claims MUST NOT be part
>       of the mustExclude list.
> If I see one of those claims in the mustExclude list, do I ignore the
> entire EnhancedJWTClaimConstraints extension?

Yes.  I'll add a sentence to state that.  I suggest:

       ...  If one of these baseline PASSporT
       claims appears in the mustExclude list, then the certificate MUST
       be treated as if the extension was not present.

>       JWTClaimName ::= IA5String
> I'd consider a comment that RFC 8226 restricts JWT claim names to be

Okay. I suggest:

   Following the precedent in [RFC8226], JWT Claim Names MUST be ASCII
   strings, which are also known as strings using the International
   Alphabet No. 5 [ISO646].

> Section 7
> We might mention that since the extension is non-critical, the
> additional constraints on validation will only be applied with the
> PASSporT recipient implements this extension, and thus that the
> constraints might be ignored by some recipients.

I suggest:

   Since non-critical certificate extension are ignored by
   implementations that do not recognize the extension object identifier
   (OID), constraints on PASSporT validation will only be applied by
   relying parties that recognize the EnhancedJWTClaimConstraints

FYI, I expect that the [I-D.ietf-stir-cert-delegation] will require implementations of that specification to support this new extension and the original in RFC 8226.

>   The Enhanced JWT Claim Constraints certificate extension can be used
>   by certificate issuers to provide limits on the acceptable PASSporTs
>   that will be accepted by verification services.  Enforcement of these
>   limits depends upon proper implementation by the verification
>   services.  The digital signature on the PASSportT data structure will
>   be valid even if the limits are violated.
> I'd consider s/will/can/ in the last sentence, as there's no guarantee
> that an arbitrary PASSporT signature will be valid.


>   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'd consider prefacing this paragraph with something like "For example",
> as otherwise one might wonder why this particular claim is so important
> to call out in this document's security considerations.

Rob asked for SHOULD NOT.  And if you look at the structure in [I-D.ietf-stir-passport-rcd], the integrity really does depend on this claim.