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

Benjamin Kaduk <kaduk@mit.edu> Tue, 29 June 2021 14:07 UTC

Return-Path: <kaduk@mit.edu>
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 0CA463A3571; Tue, 29 Jun 2021 07:07:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.196
X-Spam-Level:
X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 HqSncMhpL0T0; Tue, 29 Jun 2021 07:07:35 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54F4A3A3570; Tue, 29 Jun 2021 07:07:34 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 15TE7PSI002787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 29 Jun 2021 10:07:30 -0400
Date: Tue, 29 Jun 2021 07:07:24 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Russ Housley <housley@vigilsec.com>
Cc: IESG <iesg@ietf.org>, IETF STIR Mail List <stir@ietf.org>, Robert Sparks <rjsparks@nostrum.com>, Ben Campbell <ben@nostrum.com>
Message-ID: <20210629140724.GE17170@kduck.mit.edu>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <A46901E1-E0B6-45FB-B70A-70771643BC5B@vigilsec.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/v_8lQYvQl_UAt0dX4FI6oAX8ldY>
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 14:07:37 -0000

On Tue, Jun 29, 2021 at 09:52:00AM -0400, Russ Housley wrote:
> 
> Ben:
> 
> >> For now, just responding to the DISCUSS ...
> >> 
> >>> ----------------------------------------------------------------------
> >>> DISCUSS:
> >>> ----------------------------------------------------------------------
> >>> 
> >>> Let's discuss whether we should have content in this document discussing
> >>> the relationship between this new certificate extension and the
> >>> extension defined by RFC 8226.  In paticular, whether it is
> >>> permitted/expected for both extensions to appear in the same
> >>> certificate, and whether any specific processing is required in that
> >>> case.  (If no such processing is specified, we could end up with
> >>> interesting edge cases where a given PASSporT is handled differently
> >>> depending on which extension(s) are supported by the recipient.)
> >> 
> >> I see no reason why both extensions would ever appear in the same certificate.
> > 
> > There was an open question for me about backwards compatibility...
> > 
> >> If there is a mustExclude, then the constraints cannot be expressed in the extension defined in RFC 8226, so I would only expect the on in this document to be present.
> > 
> > ... specifically, if the desired constraints include both mustExclude and
> > one of the preexisting restrictions, does "something is better than
> > nothing" apply when the recipient might not implement the new extension,
> > prompting a desire to include both extensions so that the recipient will
> > apply those constraints it does know about?
> 
> No.  It is important that all of the constraints are met for the use cases where mustExclude come into play.

It seems like that might be worth mentioning as the intended use, as well.

> > If there is a desire to provide this backwards compatibility, is it better
> > to duplicate the constraint in both extensions or rely on both extensions
> > being processed and only put mustExclude in the new extension?  If the
> > latter, why do we bother allowing the mustInclude and permittedValues forms
> > in the new extension?
> 
> Indeed,  If that were the case, I think a different design would be preferable.
> 
> >> If there is not a mustExclude, the the constraints can be expressed in either extension equally well, so I would expect only the extension defined in RFC 8226, with the presumption that it is implemented more widely.
> >> 
> >> I can add this advice to the document if it resolves your concern.
> > 
> > I think at least the last bit makes sense to mention in this document.  I'm
> > still not entirely clear on the full picture, though.
> 
> I'll craft some text to address this, and then I will turn to your other comments.

Sounds good; thanks.

-Ben