[Last-Call] 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: last-call@ietf.org
Delivered-To: last-call@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: =?utf-8?q?Christian_Ams=C3=BCss_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: =?utf-8?q?Christian_Ams=C3=BCss?= <christian@amsuess.com>
Date: Tue, 05 Apr 2022 12:25:16 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/WPLGd_VrpAJGmyNWDu24xcpnG6s>
Subject: [Last-Call] Artart last call review of draft-ietf-tls-subcerts-12
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>,
<mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>,
<mailto:last-call-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.
- [Last-Call] Artart last call review of draft-ietf… Christian Amsüss via Datatracker