[stir] Roman Danyliw's No Objection on draft-ietf-stir-cert-delegation-03: (with COMMENT)

Roman Danyliw via Datatracker <noreply@ietf.org> Wed, 09 September 2020 14:10 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 94E463A0C82; Wed, 9 Sep 2020 07:10:14 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-stir-cert-delegation@ietf.org, stir-chairs@ietf.org, stir@ietf.org, Russ Housley <housley@vigilsec.com>, housley@vigilsec.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.16.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <159966061458.21926.1670711388251011329@ietfa.amsl.com>
Date: Wed, 09 Sep 2020 07:10:14 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/qgocwOW3ETgWa8j4EaBLASerGSA>
Subject: [stir] Roman Danyliw's No Objection on draft-ietf-stir-cert-delegation-03: (with 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: Wed, 09 Sep 2020 14:10:15 -0000

Roman Danyliw has entered the following ballot position for
draft-ietf-stir-cert-delegation-03: No Objection

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 IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


I support Ben Kaduk’s DISCUSS positions.

** Given that this document specifies the delegation model alluded to in
Section 5 of RFC8226 with normative guidance, is there a reason it doesn’t
formally update RFC8226?

** Section 4. Should this guidance be a normative MUST: “… each delegate
certificate _must_ have a TNAuthList scope that is equal to …”

** Section 4.  Should this guidance use a normative MAY: “… Delegate
certificates _may_ also contain a basic constraints extensions with the cA
boolean …”

** Section 4.1.  Per the inheritance described in: “STIR certificates may have
a TNAuthList containing one or more SPCs, one or more telephone number ranges,
or both.  When delegating from a STIR certificate, a child certificate may
inherit from its parent either of the above”, can a parent certificate specify
a SPC and the child certificate have a telephone number range; or is the
delegation only of the same types?

** Section 4.*.  Can you please clarify the use of the AIA extension in
delegation as posed by the SECDIR reviewer (thanks to Carl Wallance for doing
the review!).  Additionally, can AIA be used in delegated certificates?

** Section 7.  With regard to the use of “x5u” vs. “x5c”, what is the normative
guidance on these elements?

** Section 8.1. Per “Service providers that want the capability to rapidly
revoke delegated certificates can rely on the ACME STAR [I-D.ietf-acme-star] 
mechanism”, please clarify this text.  The intent is correct, but ACME STAR
doesn’t actually revoke certificates.

** Editorial Nits:
-- Section 5.  This text doesn’t parse “… and if that certificate has a own
parent …”

-- Section 7.  Typo. s/certificate path are/certificates paths are/