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

Russ Housley <> Wed, 30 June 2021 16:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E04883A220D for <>; Wed, 30 Jun 2021 09:27:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MmzhQj-qzAuS for <>; Wed, 30 Jun 2021 09:27:49 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C5F653A220E for <>; Wed, 30 Jun 2021 09:27:48 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0116A3005D7 for <>; Wed, 30 Jun 2021 12:27:47 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id azBZ8jSkJ0Ji for <>; Wed, 30 Jun 2021 12:27:42 -0400 (EDT)
Received: from a860b60074bd.fios-router.home ( []) by (Postfix) with ESMTPSA id BC6A3300230; Wed, 30 Jun 2021 12:27:42 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
From: Russ Housley <>
In-Reply-To: <>
Date: Wed, 30 Jun 2021 12:27:42 -0400
Cc: IETF STIR Mail List <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
To: "Peterson, Jon" <>
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: Wed, 30 Jun 2021 16:27:55 -0000

Thanks Jon.

I understand that the EnhancedJWTClaimConstraints extension will support certificate delegation as well as other things.  In an 0ff-list message, I learned that the ATIS will be mandating support for the EnhancedJWTClaimConstraints extension in one of their documents.  So, this approach seems to be on target.


> On Jun 30, 2021, at 11:37 AM, Peterson, Jon <> wrote:
> I don't know that enhanced constraints need to be coupled that tightly to delegation. When delegation gets approved in the SHAKEN ecosystem (I wouldn't venture when exactly that will be), it would certainly make sense for SHAKEN specs to point to the enhanced constraints, but I'm not sure there's something we need to close in the IETF to make that possible. I think your Section 6 text looks fine. I guess I can also imagine non-delegation cases that could use enhanced constraints in the future as well, so I wouldn't necessarily want to make them so intertwined.
> Jon Peterson
> Neustar, Inc.
> On 6/29/21, 2:34 PM, "stir on behalf of Russ Housley" < on behalf of> wrote:
>    Based on the comments from Ben Kaduk, I drafted the below guidance to CAs.
>> 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 the EnhancedJWTClaimConstraints become widely
>> implemented, the use of the JWTClaimConstraints extension may be more
>> likely to be implemented.  This guess is based on the presumption
>> that the first specified extension will be implemented more widely in
>> the next few years.
>    The delegated certs activities lead to this document in the first place, so it seems appropriate to ask when people think that delegate certificates will be implement?  Will a future version of the delegated certificates document mandate the implementation of the EnhancedJWTClaimConstraints extension?  Do these answers to these questions offer any better guidance than the above?
>    Russ