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

Ben Campbell <> Thu, 01 July 2021 13:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E47853A09BE; Thu, 1 Jul 2021 06:56:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.281
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: (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R2PHj_cODcsn; Thu, 1 Jul 2021 06:55:56 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CF6443A09BB; Thu, 1 Jul 2021 06:55:56 -0700 (PDT)
Received: from ( [] (may be forged)) (authenticated bits=0) by (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
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; 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: Host [] (may be forged) claimed to be
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Ben Campbell <>
In-Reply-To: <>
Date: Thu, 1 Jul 2021 08:55:44 -0500
Cc: Russ Housley <>, IETF STIR Mail List <>, IESG <>, Robert Sparks <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Benjamin Kaduk <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [stir] Benjamin Kaduk's Discuss on draft-ietf-stir-enhance-rfc8226-03: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Secure Telephone Identity Revisited <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


Ben C.

> On Jun 29, 2021, at 9:07 AM, Benjamin Kaduk <> 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