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

Benjamin Kaduk <> Tue, 31 March 2020 15:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 109783A2299; Tue, 31 Mar 2020 08:03:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CTLfs7uu9nHm; Tue, 31 Mar 2020 08:03:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4B06C3A2292; Tue, 31 Mar 2020 08:02:19 -0700 (PDT)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 02VF23r4029072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 31 Mar 2020 11:02:05 -0400
Date: Tue, 31 Mar 2020 08:02:02 -0700
From: Benjamin Kaduk <>
To: Michael Richardson <>
Cc: The IESG <>,,,,
Message-ID: <>
References: <> <4603.1585620652@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4603.1585620652@localhost>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <>
Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-39: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 31 Mar 2020 15:03:04 -0000

Hi Michael,

On Mon, Mar 30, 2020 at 10:10:52PM -0400, Michael Richardson wrote:
> Benjamin Kaduk via Datatracker <> wrote:
>     > 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
> That's entirely correct.
> The thing in the voucher validates the TLS connection that the pledge sees.

I'm not quite sure if the "that" that is entirely correct is intended to be
"the voucher artifact in the -39" or "pinned-domain-cert should be the CA
cert that signed the registrar's cert".

I agree that the primary role of the pinned-domain-cert is to validate the
provisional TLS connection to the registrar, but validating a TLS
connection can be done by indicating that any certificate in the chain is
trusted, from leaf/end-entity up to root CA.  If the pledge goes on to
perform full EST (which is currently listed as optional), then the exact
contents of the pinned-domain-cert don't matter in practice very much other
than validating the provisional TLS connection, but for the case where the
pledge stops after BRSKI and does not do full EST, having a domain CA
certificate seems much more useful than just knowing that the registrar's
end-entity certificate is trusted.

My interpretation of "pinned-domain-cert is always a CA certificate" seems
to have persistent support throughout the text:

Section 5.5.2:

   The registrar's certificate chain is extracted from the signature
   method.  The entire registrar certificate chain was included in the
   CMS structure, as specified in Section 5.5.  This CA certificate will
   be used to populate the "pinned-domain-cert" of the voucher being

Section 5.6:

   pinned-domain-cert:  The domain CA cert.  See Section 5.5.2.  This
      figure is illustrative, for an example, see Appendix C.2

Section 5.6.2:

   The 'pinned-domain-cert' element of the voucher contains the domain
   CA's public key.  The pledge MUST use the 'pinned-domain-cert' trust
   anchor to immediately complete authentication of the provisional TLS
   The pinned-domain-cert MAY be installed as an trust anchor for future
   operations such as enrollment (e.g.  [RFC7030] as recommended) or
   trust anchor management or raw protocols that do not need full PKI
   based key management.  It can be used to authenticate any dynamically
   discovered EST server that contain the id-kp-cmcRA extended key usage
   extension as detailed in EST RFC7030 section 3.6.1; but to reduce
   system complexity the pledge SHOULD avoid additional discovery
   operations.  Instead the pledge SHOULD communicate directly with the

but I'd be happy to learn why I'm misreading things.

As far as the bigger picture goes, I think that the BRSKI document as a
whole is essentially done, and only know of the last issues (noted in my
ballot position on the -39) that, given my current understanding of the
document, seems to be factual errors where the document is internally
inconsistent with itself.  Once they get resolved (whether by educating me
on my improper understanding or by updating the text), I expect to change
my ballot position to YES so the document can get approved for publication.
(With Ignas having cycled off the IESG, it currently does not have a YES.)
I am even willing to produce an updated example voucher artifact myself, if
that would help expedite things -- I believe I already have the needed
keys/certs locally from my review of the -39.  As an alternate option, if
more expedient, I could probably even accept just adding a note to the
example that says that the pledge goes on to perform full EST, so the
pinned-domain-cert is only needed to validate the provisional TLS

Please let me know if I'm missing anything here.