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

Benjamin Kaduk via Datatracker <noreply@ietf.org> Mon, 28 June 2021 22:25 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: stir@ietf.org
Delivered-To: stir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F983A1768; Mon, 28 Jun 2021 15:25:38 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-stir-enhance-rfc8226@ietf.org, stir-chairs@ietf.org, stir@ietf.org, rjsparks@nostrum.com, ben@nostrum.com, ben@nostrum.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.33.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <162491913776.24561.10295832590740387025@ietfa.amsl.com>
Date: Mon, 28 Jun 2021 15:25:38 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/g8qXR6RQ2EdHjclv3XUibCy8Xp8>
Subject: [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
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: Mon, 28 Jun 2021 22:25:38 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-stir-enhance-rfc8226-03: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-stir-enhance-rfc8226/



----------------------------------------------------------------------
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.)


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

As a standalone description of a certificate extension this document is
in good shape; the main complication that doesn't seem covered is
(per the Discuss) the interaction with the preexisting extension.

Section 3

   3.  mustExclude indicates JWT claims that MUST NOT appear in the
       PASSporT.  The baseline PASSporT claims ("iat", "orig", and
       "dest") are always permitted, and these claims MUST NOT be part
       of the mustExclude list.

If I see one of those claims in the mustExclude list, do I ignore the
entire EnhancedJWTClaimConstraints extension?

       JWTClaimName ::= IA5String

I'd consider a comment that RFC 8226 restricts JWT claim names to be
ASCII.

Section 7

We might mention that since the extension is non-critical, the
additional constraints on validation will only be applied with the
PASSporT recipient implements this extension, and thus that the
constraints might be ignored by some recipients.

   The Enhanced JWT Claim Constraints certificate extension can be used
   by certificate issuers to provide limits on the acceptable PASSporTs
   that will be accepted by verification services.  Enforcement of these
   limits depends upon proper implementation by the verification
   services.  The digital signature on the PASSportT data structure will
   be valid even if the limits are violated.

I'd consider s/will/can/ in the last sentence, as there's no guarantee
that an arbitrary PASSporT signature will be valid.

   Certificate issuers should not include an entry in mustExclude for
   the "rcdi" claim for a certificate that will be used with the
   PASSporT Extension for Rich Call Data defined in
   [I-D.ietf-stir-passport-rcd].  Excluding this claim would prevent the
   integrity protection mechanism from working properly.

I'd consider prefacing this paragraph with something like "For example",
as otherwise one might wonder why this particular claim is so important
to call out in this document's security considerations.