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

Benjamin Kaduk <> Sat, 03 July 2021 17:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 89BFF3A1E78; Sat, 3 Jul 2021 10:55:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0YewYt4kawo8; Sat, 3 Jul 2021 10:55:05 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CC8CB3A1E75; Sat, 3 Jul 2021 10:55:04 -0700 (PDT)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 163HstrU010156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 3 Jul 2021 13:55:00 -0400
Date: Sat, 3 Jul 2021 10:54:54 -0700
From: Benjamin Kaduk <>
To: Russ Housley <>
Cc: IETF STIR Mail List <>, Ben Campbell <>, IESG <>, Robert Sparks <>
Message-ID: <>
References: <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
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: Sat, 03 Jul 2021 17:55:11 -0000

Hi Russ,

On Tue, Jun 29, 2021 at 10:13:53AM -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.
> 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?

It has become much less important now that the two extensions MUST NOT
both appear in the same certificate, since that has implicitly made a value
judgement on the importance of supporting all of the constraints

But the quoted text from Section 1 seems to only say that there is a need
to use this extension for the delegation case (for the new behavior); it
seems indifferent on whether it's important to have all the constraints
together so that either all the constraints are applied or none are.  Just
based on this description, it would be just as effective to put the new
constraint in the new extension and put the other constraints in the
preexisting extension.  Obviously that's not possible given the "MUST NOT
both appear", so I'm not going to push for additional text on this point.