Re: [netconf] [Anima] Reuse of SZTP-CSR YANG definition in BRSKI-AE

Kent Watsen <> Mon, 21 June 2021 12:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BF2553A0CDA; Mon, 21 Jun 2021 05:50:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.004
X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TFNIAJ0-yOPi; Mon, 21 Jun 2021 05:50:39 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A9EFF3A0CD8; Mon, 21 Jun 2021 05:50:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug;; t=1624279837; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=X+Xl1/q9CB2BweGXOt+LHQquwBIvoSFmhrfjw4mPxms=; b=e/gYeKsK+EPj/4kQhkr6dVNhc+DIYz29joYvfUMRa3URyFm6gDYrbKb/zilz0MmJ KfawYK2GHK/BzVCjQBLJbLQ/vY8BQkzLLFjswo8kVWhP+6nCq4b7MoIBF3m9jYvCMnx eXsOAueHZegudeEwBlaiI1AtrZduhA/dIdzmxFiA=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Kent Watsen <>
In-Reply-To: <8407.1624138175@localhost>
Date: Mon, 21 Jun 2021 12:50:37 +0000
Cc: "Fries, Steffen" <>, "Werner, Thomas" <>, "" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-ID: <>
References: <> <> <8407.1624138175@localhost>
To: Michael Richardson <>
X-Mailer: Apple Mail (2.3654.
X-SES-Outgoing: 2021.06.21-
Archived-At: <>
Subject: Re: [netconf] [Anima] Reuse of SZTP-CSR YANG definition in BRSKI-AE
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 21 Jun 2021 12:50:42 -0000

Hi Michael,

>> [future threads about SZTP should CC NETCONF, the WG that
>> published/maintains SZTP]
> Yes, and not netmod?

Correct.  Though questions regarding the YANG language are best post to NETMOD.

>    sf> In one use case, the pledge has no direct connection to the registrar
>    sf> and a registrar-agent communicates with the pledge. In that specific
>    sf> case we do not have a TLS connection between the pledge and the
>    sf> registrar-agent and protect the exchanged objects by an additional
>    sf> signature. This is done by embedding the necessary information into a JOSE object.
> ...
>    sf> The question
>    sf> ( now
>    sf> is, if this construct is possible, as we are just using a subset
>    sf> (sztp-csr:csr) of the YANG  module " ietf-sztp-bootstrap-server" from
>    sf> draft-ietf-netconf-sztp-csr?
>    kw> This is not possible.
> I feel that the question might have been so specific that it didn't match.
> My thought was to do CORECONF (possibly using CoAP over BTLE), to retrieve a
> CSR from a device.  It seems to fit right into the ietf-sztp-bootstrap-server
> pattern to me.
> So, I'm unclear why ietf-sztp-csr:csr-support couldn't be used.
> Is it because the module augments sztp, and we don't need it all?

In part, but also because what you want is buried inside a definition and there is no mechanism to cherry-pick inner-nodes.

> We really just want container csr-support, csr-generation, csr, ???
> Maybe we could chat about this more.
> We have a regular Thursday 9:30 EST design team.
>>> The alternative would be to define an own module modeled in a similar.
>> You can do this.
> I think that we can have some common mindshare here.

One option would be to move stuff into ietf-crypto-types…as that module already defines a number of grouping statements for handy structures.  That said, these structures are not context-free…they are very much entwined in a specific dialog that is rather specific to bootstrapping processes.  [FWIW,  just adding “cmc” and “cmp" typedefs to crypto-types, alongside the existing “csr” (e.g., “p10”) typedef, might be a good thing]

Another option would be to move stuff into grouping statements, in the same module, that are immediately.  In theory this would have no impact to the on-the-wire format.  However, it’s somewhat late in the process to entertain this, as the draft is in the AD queue (AD-review was just posted today) and no doubt we would dicker over how many groupings to create and whether they should be put into another draft to whitewash out the SZTP-stint.  Is it proper to reset a NETCONF publication for another WG?  Rob?