[netmod] Reuse of SZTP-CSR YANG definition in BRSKI-AE

"Fries, Steffen" <steffen.fries@siemens.com> Thu, 17 June 2021 14:51 UTC

Return-Path: <steffen.fries@siemens.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22FDD3A232E; Thu, 17 Jun 2021 07:51:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.897
X-Spam-Level:
X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 W499Ztznx8YQ; Thu, 17 Jun 2021 07:51:05 -0700 (PDT)
Received: from gw-eagle2.siemens.com (gw-eagle2.siemens.com [194.138.20.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB39E3A2314; Thu, 17 Jun 2021 07:51:04 -0700 (PDT)
Received: from mail2.dc4ca.siemens.de (mail2.dc4ca.siemens.de [139.25.224.94]) by gw-eagle2.siemens.com (Postfix) with ESMTPS id 3C0934682AE; Thu, 17 Jun 2021 16:50:58 +0200 (CEST)
Received: from DEMCHDC89ZA.ad011.siemens.net (demchdc89za.ad011.siemens.net [139.25.226.105]) by mail2.dc4ca.siemens.de (Postfix) with ESMTPS id 360E11951F727; Thu, 17 Jun 2021 16:50:58 +0200 (CEST)
Received: from DEMCHDC89XA.ad011.siemens.net (139.25.226.103) by DEMCHDC89ZA.ad011.siemens.net (139.25.226.105) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14; Thu, 17 Jun 2021 16:50:57 +0200
Received: from DEMCHDC89XA.ad011.siemens.net ([139.25.226.103]) by DEMCHDC89XA.ad011.siemens.net ([139.25.226.103]) with mapi id 15.01.2176.014; Thu, 17 Jun 2021 16:50:57 +0200
From: "Fries, Steffen" <steffen.fries@siemens.com>
To: Kent Watsen <kent+ietf@watsen.net>
CC: "anima@ietf.org" <anima@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>, "Werner, Thomas" <thomas-werner@siemens.com>
Thread-Topic: Reuse of SZTP-CSR YANG definition in BRSKI-AE
Thread-Index: AddjiC0D00j6GcKVSy+dSa8jk3TUtA==
Date: Thu, 17 Jun 2021 14:50:57 +0000
Message-ID: <3a31e33678484625b9f4f3810e673e56@siemens.com>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2021-06-17T14:50:56Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=33a5de5c-fd73-4a34-8009-87e02f4a84e1; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0
document_confidentiality: Restricted
x-originating-ip: [144.145.220.66]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/nwXo0KzoSH73Yjc8xv6A-L4DxRM>
Subject: [netmod] Reuse of SZTP-CSR YANG definition in BRSKI-AE
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Jun 2021 14:51:19 -0000

Hi Kent, 

There is a further YANG related question in the context of BRSKI-AE. 

In one use case, the pledge has no direct connection to the registrar and a registrar-agent communicates with the pledge. In that specific case we do not have a TLS connection between the pledge and the registrar-agent and protect the exchanged objects by an additional signature. This is done by embedding the necessary information into a JOSE object. 
For the enrollment Michael was pointing to the YANG module in https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr to avoid a double definition to transport a certification request. In BRSKI-AE we currently use a PKCS#10 request, but using the defined ietf-sztp-csr would also allow to use other formats. 

For the enrollment request created by the pledge we have defined the following JOSE object:
   {
       "alg": "ES256",
       "x5c": ["MIIB2jCC...dA=="]
   }
   {
     "ietf-sztp-csr:csr": {
       "p10": "base64encodedvalue=="
     }
   }
   {
       SIGNATURE
   }

The question (https://github.com/anima-wg/anima-brski-async-enroll/issues/10) now is, if this construct is possible, as we are just using a subset (sztp-csr:csr) of the YANG  module " ietf-sztp-bootstrap-server" from draft-ietf-netconf-sztp-csr? The alternative would be to define an own module modeled in a similar. 

Best regards
Steffen