Re: [Anima] Questions raised during IETF 105 regarding BRSKI-AE

Michael Richardson <> Fri, 23 August 2019 21:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E514712009C for <>; Fri, 23 Aug 2019 14:18:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 33vz3qjAcQ-7 for <>; Fri, 23 Aug 2019 14:18:55 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1F6F112011D for <>; Fri, 23 Aug 2019 14:18:54 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 0AD1938191; Fri, 23 Aug 2019 17:17:52 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id CDAA8D51; Fri, 23 Aug 2019 17:18:53 -0400 (EDT)
From: Michael Richardson <>
To: "Fries, Steffen" <>
cc: "" <>, Eliot Lear <>
In-Reply-To: <>
References: <>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Fri, 23 Aug 2019 17:18:53 -0400
Message-ID: <10184.1566595133@localhost>
Archived-At: <>
Subject: Re: [Anima] Questions raised during IETF 105 regarding BRSKI-AE
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: Fri, 23 Aug 2019 21:18:57 -0000

Fries, Steffen <> wrote:
    > There was a question regarding the benefits on Full CMC (PKI) Request
    > support in EST from Michael. One of the benefits of the Full CMC
    > request is that it provides a way to bind the entity identification and
    > authentication to the certification request. This can be achieved by an
    > additional signature over the certification request with the IDevID EE
    > cert of a pledge. The result is what we called in the draft a
    > self-contained object with two signatures, one with the private key
    > corresponding to the contained public key in the CSR, the second with
    > the private key, which's corresponding certificate can be validated.
    > Maybe the term is misleading as the CSR is also self-contained. So we
    > may need to fine a better term.

okay.  I need to re-read things to better understand.

    > Having this type of self-contained object comes with some advantages:
    > - It removes the strict binding of the  certification request with the
    > pledge authentication in TLS using the tls-unique value in the CSR
    > during the EST run. This is especially interesting for scenarios, in
    > which the registrar (EST server) acts as LRA and has (temporarily) no
    > connection to the issuing RA/CA. If it needs to store the CSR and
    > forward it later on for further processing to the RA/CA, the
    > information about the identity and authentication is not directly bound
    > to the CSR and would require other mechanisms.

    > - For the "no soup case - come back later" case (Eliot, I just borrowed
    > your analogy)  it provides the advantage, if the tls-unique parameter
    > is used in the CSR (BRSKI is open to this) to bind the CSR to a
    > specific TLS connection. If the TLS connection between the pledge and
    > the registrar was teared down, EST (in simple enroll/reenroll) requires
    > to resent the CSR, which would require to include a new tls-unique
    > number, which in turn would require rebuilding the CSR (also described
    > in RFC 7030, section 4.2.3).

I agree that this is a good feature.
Can you tell us more about how you'd use it?

My next question would be, given that some would like CMP rather than EST as
an option, and it appears that LAMPS may do a minimal profile of CMP, maybe
that would suit you better for these disconnected uses rather than fullcmc.

Regardless, how would one discover and signal the use of fullcmc or CMP?

Michael Richardson <>, Sandelman Software Works
 -= IPv6 IoT consulting =-