[Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-39: (with DISCUSS and COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Tue, 31 March 2020 00:03 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: anima@ietf.org
Delivered-To: anima@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F0B3A1004; Mon, 30 Mar 2020 17:03:32 -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-anima-bootstrapping-keyinfra@ietf.org, anima-chairs@ietf.org, anima@ietf.org, Toerless Eckert <tte+ietf@cs.fau.de>, tte+ietf@cs.fau.de
X-Test-IDTracker: no
X-IETF-IDTracker: 6.123.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <158561301296.11367.9776561744635554098@ietfa.amsl.com>
Date: Mon, 30 Mar 2020 17:03:32 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/toDmfRyo1YsBX_3AhorzDxZB0jE>
Subject: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-39: (with DISCUSS and COMMENT)
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Mar 2020 00:03:33 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-anima-bootstrapping-keyinfra-39: 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 IESG DISCUSS and COMMENT positions.

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


Thanks for the updates leading to the -39; I believe we're almost there!

Unfortunately, it seems that the "pinned-domain-cert" in the issued voucher
is the registrar's cert, not the CA cert.  (Given that the documented workflow is
to extract this CA cert from the registrar-voucher-request CMS object, and the
registrar-voucher-request in our examples does include both the registrar cert
and the CA cert, I wonder if this reflects a bug in the code itself used to generate
the examples, in that it picks the wrong cert?)  My understanding is that the
protocol requires this field to be populated by a CA cert, and the registrar's
cert is not a CA cert.

I am very hopeful that we can just regenerate the voucher without having to
redo the rest of the examples, since we have all the keys and certificate enshrined
in the document already, and my apologies for not noticing whether this issue was
present in previous revisions as well.


I would make this a Discuss point but I think I already had my chance at the text and
missed it: Section C.1.5 says that "The public key is used by the registrar to find the MASA",
but it's really the certificate (via the "MASA URL" extension) and not the public key that
is so used.

I would suggest noting in C.2 that the asn1parse output is truncated at $number
columns, and specifically calling out that this makes it hard to differentiate between
organizationally related name components, specifically "highway-test.example.com CA"
and "highway-test.example.com MASA".  (The full asn1parse output from the live openssl
CLI is much clearer about the distinction.)