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

Ben Campbell <ben@nostrum.com> Thu, 01 July 2021 13:56 UTC

Return-Path: <ben@nostrum.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 E47853A09BE; Thu, 1 Jul 2021 06:56:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.281
X-Spam-Level:
X-Spam-Status: No, score=-0.281 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.398, MAY_BE_FORGED=1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
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 R2PHj_cODcsn; Thu, 1 Jul 2021 06:55:56 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF6443A09BB; Thu, 1 Jul 2021 06:55:56 -0700 (PDT)
Received: from smtpclient.apple (mta-70-120-133-87.satx.rr.com [70.120.133.87] (may be forged)) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 161DtnUG008421 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 1 Jul 2021 08:55:50 -0500 (CDT) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1625147753; bh=u37zqXwvvJGRLzRJ5C5Q8wlqSoErHZEhJJz3c7WTh1s=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=sT9IM9gaCU7mJetFL75YlTuZqK/puEFfPf2hZ23EN3DgKWBPp66ckm7srU8YLdagB pVOZe53I+RUXuUzTTUx03BDXw11bj5DNpCGx2L10L7HETbaY2LCF1EvAJzJnjbLOc4 +h1TlTgj7ukSPVOQ/FNoAJrFQFnCe9RBI4q9Q1/E=
X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-133-87.satx.rr.com [70.120.133.87] (may be forged) claimed to be smtpclient.apple
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <20210629140724.GE17170@kduck.mit.edu>
Date: Thu, 1 Jul 2021 08:55:44 -0500
Cc: Russ Housley <housley@vigilsec.com>, IETF STIR Mail List <stir@ietf.org>, IESG <iesg@ietf.org>, Robert Sparks <rjsparks@nostrum.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <36147CD6-9167-4FFC-B8AC-CB0EDC2A19B1@nostrum.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: Benjamin Kaduk <kaduk@mit.edu>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/GNU1bze4fAMnJQBlDqv1UXAZ_vY>
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: Thu, 01 Jul 2021 13:56:02 -0000

(as draft shepherd)

Hi Ben,

Russ submitted an update yesterday (04) that I _think_ covers  your DISCUSS and COMMENT points.

https://datatracker.ietf.org/doc/draft-ietf-stir-enhance-rfc8226/

Thanks!

Ben C.

> On Jun 29, 2021, at 9:07 AM, Benjamin Kaduk <kaduk@mit.edu> wrote:
> 
> 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
>