Re: [stir] Benjamin Kaduk's No Objection on draft-ietf-stir-enhance-rfc8226-04: (with COMMENT)

Russ Housley <housley@vigilsec.com> Sat, 03 July 2021 19:40 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 509C63A21CF for <stir@ietfa.amsl.com>; Sat, 3 Jul 2021 12:40:17 -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=unavailable 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 q3po7Y4M2Mm2 for <stir@ietfa.amsl.com>; Sat, 3 Jul 2021 12:40:14 -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 2437F3A21D0 for <stir@ietf.org>; Sat, 3 Jul 2021 12:40:14 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1D46E300BF9 for <stir@ietf.org>; Sat, 3 Jul 2021 15:40:13 -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 SF8uTk96HNiu for <stir@ietf.org>; Sat, 3 Jul 2021 15:40:07 -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 0BC0A3001A8; Sat, 3 Jul 2021 15:40:07 -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 <housley@vigilsec.com>
In-Reply-To: <162533462765.18440.5054449553859461793@ietfa.amsl.com>
Date: Sat, 3 Jul 2021 15:40:06 -0400
Cc: IESG <iesg@ietf.org>, IETF STIR Mail List <stir@ietf.org>, Robert Sparks <rjsparks@nostrum.com>, Ben Campbell <ben@nostrum.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1AA191FD-7CE0-454B-9739-FE095E294482@vigilsec.com>
References: <162533462765.18440.5054449553859461793@ietfa.amsl.com>
To: Ben Kaduk <kaduk@mit.edu>
X-Mailer: Apple Mail (2.3445.104.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/DKu-Fe-geA8cTabvkHAxSerL_EI>
Subject: Re: [stir] Benjamin Kaduk's No Objection on draft-ietf-stir-enhance-rfc8226-04: (with 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: Sat, 03 Jul 2021 19:40:17 -0000

Ben:

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks for the updates in the -04; they address all my comments well.
> 
> Just one editorial note on the new Section 6:
> 
>   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
> 
> For singular/plural match, I think "becomes" is better.
> I'd also consuder "such time as support for the EnhancedJWTClaimConstraints
> extension becomes widely implemented".
> 
>   implemented, the use of the JWTClaimConstraints extension may be more
>   likely to be implemented.  This guess is based on the presumption
> 
> "use of ... may be more likely to be implemented" is an unusual construction.
> I think "use of ... may be more likely to succeed" or "the [extension] may
> be more likely to be implemented" would be more typical.
> 
>   that the first specified extension will be implemented more widely in
>   the next few years.

Thanks for the careful reading.  I have made these edits:

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 support for the EnhancedJWTClaimConstraints extension
   becomes widely implemented, the use of the JWTClaimConstraints
   extension may be more likely to be supported.  This guess is based on
   the presumption that the first specified extension will be
   implemented more widely in the next few years.

I will not post a new version until IANA assigns the object identifiers.  I need to update the example in Section 5 and the ASN.1 in Appendix A once the OIDs are assigned.

Russ