[art] Artart last call review of draft-ietf-tls-subcerts-12

Christian Amsüss via Datatracker <noreply@ietf.org> Tue, 05 April 2022 19:25 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: art@ietf.org
Delivered-To: art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B578E3A1047; Tue, 5 Apr 2022 12:25:16 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Christian Amsüss via Datatracker <noreply@ietf.org>
To: art@ietf.org
Cc: draft-ietf-tls-subcerts.all@ietf.org, last-call@ietf.org, tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.46.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <164918671652.6833.10891731784699091201@ietfa.amsl.com>
Reply-To: Christian Amsüss <christian@amsuess.com>
Date: Tue, 05 Apr 2022 12:25:16 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/7lzdOaiccRnXFtSuX3aUyh9ffV8>
Subject: [art] Artart last call review of draft-ietf-tls-subcerts-12
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2022 19:25:17 -0000

Reviewer: Christian Amsüss
Review result: Ready with Nits

Thanks for this well-written document

ART topics:

The document does not touch on any of the typical ART review issues; times are
relative in well understood units, and versioning, formal language (ASN.1,
which is outside of my experience to check) and encoding infrastructure
(struct) follows TLS practices.

General comments:

* The introduction of this mechanism gives the impression of a band-aid applied
to a PKI ecosystem that has accumulated many limitations as outlined in section
3.1. The present solution appears good, but if there is ongoing work on the
underlying issues (even experimentally), I'd appreciate a careful reference to
it.

* Section 7.6 hints at the front end querying the back-end for creation of new
DCs -- other than that, DC distribution (neither push- nor pull-based) is
discussed. If there are any mechanisms brewing, I'd appreciate a reference as
well.

Please check:

* The IANA considerations list "delegated_credential" for CH, CR and CT
messages. I did not find a reference in the text for Ct, only for CH and CR.

Editorial comments:

* (p5) "result for the peer.." -- extraneous period.
* (p9, p15, p16) The "7 days" are introduced as the default for a profilable
prarameter, but later used without further comment.