[secdir] secdir review of draft-ietf-stir-cert-delegation-03

Carl Wallace <carl@redhoundsoftware.com> Mon, 31 August 2020 11:43 UTC

Return-Path: <carl@redhoundsoftware.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9ACD3A12A0 for <secdir@ietfa.amsl.com>; Mon, 31 Aug 2020 04:43:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zve3ZhJPM5sC for <secdir@ietfa.amsl.com>; Mon, 31 Aug 2020 04:43:11 -0700 (PDT)
Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7719B3A129E for <secdir@ietf.org>; Mon, 31 Aug 2020 04:43:11 -0700 (PDT)
Received: by mail-qt1-x82e.google.com with SMTP id v54so2966836qtj.7 for <secdir@ietf.org>; Mon, 31 Aug 2020 04:43:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-transfer-encoding; bh=x2cvn3rctiENL93z7Z0Wt28DE3/+ueo6Z3VyVHVYc3A=; b=uz7lxFxpI6gpFdyVT4QriRM43JuUd23qAR6bjGEpoiTqoqGdNeulpQfte9QHRx/Cpf YqAooS94d4Ab17NPLJUYuCP9aNDnkd+u86GdGzNr2ss/8yf5LUbg6w1xka9f56VoNady /owpVcWGG1Wb2w5K+/FwsoJ/qu4e7zyT0WRGs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version:content-transfer-encoding; bh=x2cvn3rctiENL93z7Z0Wt28DE3/+ueo6Z3VyVHVYc3A=; b=mRFirh789NpIBFZX1u0c4hcK4M9kG+jk5Pl/Ko3aE1Congpi8gzbnMyD9YpRLkHlRz /s/DFM7TGfPZvGMdig1SjNsQ2+937wMrxkIrKljvbGuB469RO8uYVh1wkLgTgL1yDeZ/ vXnl1p08TWbPDlobnnk9NmeB63S4hoa1N+Uqv5FCXoAfZyCeklHBZbw1SqlhSXT5UnuZ bKfnWgIbgufj1E/DcoB8GGlPQChqNxDpXFC2L+XwElMYwstPAS6hYJswcrMWywYyX9TC k+eTnBkko8p/9iDJjBqzk+ioj1qCNR/j6Po4AFOSHpjDOpKLCvPPWfoTSsmH6k6aGGit 2pmA==
X-Gm-Message-State: AOAM531HvvkCcJMqSb5CRgTEH7J6OuaXql5eAkjNdJeFAAM5Dn468PUB hcja9TJzN7eULM5rLZFF6ckhFY2pGq2PihLj
X-Google-Smtp-Source: ABdhPJzNwFjYUsSoLIb+xzRieGMFdXT+RPcgg56246UZjLbnSA+xfq9U9/UvbWXk4RTH6ltX3Ee9bw==
X-Received: by 2002:ac8:411b:: with SMTP id q27mr792857qtl.255.1598874190113; Mon, 31 Aug 2020 04:43:10 -0700 (PDT)
Received: from [192.168.2.18] (pool-108-18-106-102.washdc.fios.verizon.net. [108.18.106.102]) by smtp.gmail.com with ESMTPSA id v56sm3887386qtc.49.2020.08.31.04.43.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Aug 2020 04:43:09 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/10.10.19.200810
Date: Mon, 31 Aug 2020 07:43:09 -0400
From: Carl Wallace <carl@redhoundsoftware.com>
To: secdir@ietf.org, draft-ietf-stir-cert-delegation.all@ietf.org, last-call@ietf.org
Message-ID: <0A4A83A8-8090-4F5A-9380-3408B8986114@redhoundsoftware.com>
Thread-Topic: secdir review of draft-ietf-stir-cert-delegation-03
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/yBhHM8H1dx1OiKhreGhp4FwLQ8k>
Subject: [secdir] secdir review of draft-ietf-stir-cert-delegation-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2020 11:43:13 -0000

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the  IESG. These comments were written primarily for the benefit of the  security area directors.  Document editors and WG chairs should treat  these comments just like any other last call comments.

This document describes how authority over telephone numbers and related identifiers can be delegated from a parent certificate to a subordinate certificate. I am not versed in STIR but have a few questions and comments:

1) Section 4 states "STIR delegate certificates are certificates containing a TNAuthList object that have been signed with the private key of a parent certificate that itself contains a TNAuthList object." Section 4.1 references the use of "by-reference rather than by value, where a URL in the certificate points to a secure, dynamically-updated list of the telephone numbers in the scope of authority of a certificate". If the statement requiring inclusion of the TNAuthList extension is intended to preclude the AIA-based by-reference approach, this should be clearly stated. If this is not the intent, then the statement should be generalized to allow for either mechanism.
2) Assuming by-reference is intended, section 4.1 should include some guidance re: when the encompassing check must be performed. The current language states the check "might be performed at the time the delegate certificate is issued, or at the time that a verification service receives an inbound call, or potentially both."
3) Some discussion of handling certification paths with both TNAuthList extensions and AIA-based by-reference objects is likely needed.
4) Why is the authority token draft in the informative section instead of normative? ACME itself is in the normative and the importance of this draft to the setting of basic constraints may justify listing as normative and citing it in the security considerations section.