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 14:14 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 E65973A3593 for <stir@ietfa.amsl.com>; Tue, 29 Jun 2021 07:14:05 -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 37uHMUwIrimU for <stir@ietfa.amsl.com>; Tue, 29 Jun 2021 07:14:01 -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 032773A359C for <stir@ietf.org>; Tue, 29 Jun 2021 07:14:01 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5CF93300BF3 for <stir@ietf.org>; Tue, 29 Jun 2021 10:14:00 -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 2fCUcPXIC2AM for <stir@ietf.org>; Tue, 29 Jun 2021 10:13:54 -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 1DE88300B82; Tue, 29 Jun 2021 10:13:54 -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: <20210629140724.GE17170@kduck.mit.edu>
Date: Tue, 29 Jun 2021 10:13:53 -0400
Cc: IETF STIR Mail List <stir@ietf.org>, Ben Campbell <ben@nostrum.com>, IESG <iesg@ietf.org>, Robert Sparks <rjsparks@nostrum.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <43571C73-38E6-4B58-9BE6-536B83C35CCF@vigilsec.com>
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>
To: Ben Kaduk <kaduk@mit.edu>
X-Mailer: Apple Mail (2.3445.104.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/fgWCCE62LsaNFFAaOa5lkv2XaFA>
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:14:06 -0000

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.

I think that the text in Section 1 does that:

   The Enhanced JWT Claim Constraints certificate extension is needed to
   limit the authority when a parent STIR certificate delegates to a
   subordinate STIR certificate.  For example,
   [I-D.ietf-stir-cert-delegation] describes the situation where service
   providers issue a STIR certificate to enterprises or other customers
   to sign PASSporTs, and the Enhanced JWT Claim Constraints certificate
   extension can be used to prevent specific claims from being included
   in PASSporTs and accepted as valid by the PASSporT recipient.

What do you think needs to be added?

Russ