IETF Logo Mail Archive

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

Russ Housley <housley@vigilsec.com> Tue, 29 June 2021 21:34 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5063A0C51 for <stir@ietfa.amsl.com>; Tue, 29 Jun 2021 14:34:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpTNHGJNQdMY for <stir@ietfa.amsl.com>; Tue, 29 Jun 2021 14:34:30 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B9043A0C49 for <stir@ietf.org>; Tue, 29 Jun 2021 14:34:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7BEF2300232 for <stir@ietf.org>; Tue, 29 Jun 2021 17:34:29 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id bY8c_7-pjsBm for <stir@ietf.org>; Tue, 29 Jun 2021 17:34:24 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 5FA73300231 for <stir@ietf.org>; Tue, 29 Jun 2021 17:34:24 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
Date: Tue, 29 Jun 2021 17:34:23 -0400
References: <162491913776.24561.10295832590740387025@ietfa.amsl.com> <17CC8994-103E-4EA6-BF43-624F0A08FD5B@vigilsec.com> <20210629050839.GC17170@kduck.mit.edu> <A46901E1-E0B6-45FB-B70A-70771643BC5B@vigilsec.com> <20210629140724.GE17170@kduck.mit.edu> <43571C73-38E6-4B58-9BE6-536B83C35CCF@vigilsec.com> <BD2651EC-175A-45D3-A098-2B48A3B96BBE@nostrum.com> <1B56D3D0-C887-435E-A611-C01AD6D446EF@vigilsec.com> <559AFF0B-2CAD-4203-B383-CE49087D96C5@nostrum.com> <E59CDA6C-D54E-4041-933D-A47B491862EC@vigilsec.com> <7E6BED26-32EF-4545-A862-8C23B7A19CCD@nostrum.com>
To: IETF STIR Mail List <stir@ietf.org>
In-Reply-To: <7E6BED26-32EF-4545-A862-8C23B7A19CCD@nostrum.com>
Message-Id: <62E5EAE7-5A33-4C8E-A17D-BD0CC25AE97F@vigilsec.com>
X-Mailer: Apple Mail (2.3445.104.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/LJcdmD6TxblMAzuih1p6IZM9I5c>
Subject: Re: [stir] Benjamin Kaduk's Discuss on draft-ietf-stir-enhance-rfc8226-03: (with DISCUSS and COMMENT)
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Jun 2021 21:34:32 -0000

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

v2.23.0 | Report a Bug | By Email