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

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Tue, 20 Jul 2021 12:19:59 +0000

Kent, Russ, Sean

I was not involved in the discussion of reusing the Yang Module in BRSKI-AE some weeks back. But we would like to use the momentum that draft-ietf-netconf-sztp-csr is currently opened for editing for CMP specific corrections in the YANG module ietf-sztp-csr for brining up this discussion again.

In BRSKI-AE (https://datatracker.ietf.org/doc/draft-ietf-anima-brski-async-enroll/) we address a use case in which we use a signature wrapped CSR, for which we would like to re-use the existing YANG definition in SZTP (see also the discussion in the thread https://mailarchive.ietf.org/arch/msg/netconf/AFFqdeYJll9IndkQfT6scXWct6U/)
As BRSKI-AE  currently only utilize the CSR type part without the SZTP bootstrapping server information, it would be advantageous for BRSKI-AE (for general applicability) to extract the CSR types into a separate YANG module, which could be imported by the YANG module ietf-sztp-csr and can be re-used also by BRSKI-AE. This would avoid a potential protocol specific definition of CSR types for SZTP and BRSKI-AE with most likely the same content. In addition, while BRSKI-AE currently only utilizes P10, it would open the possibility to also utilize other certification request types in the future.
We would like to ask if you see an opportunity for this change (separate ietf-csr-types YANG module as part of draft-ietf-sztp-csr) at this point in time.

Hendrik

Siemens AG
Technology
Research in Digitalization and Automation
Security Architecture
T RDA CST SEA-DE
Otto-Hahn-Ring 6
81739 Muenchen, Germany 
Tel.: +49 89 7805-22411
Fax: +49 89 7805-29116
Mobile: +49 174 1517765
mailto:[email-masked]

www.siemens.com

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann Snabe; Managing Board: Roland Busch, Chairman, President and Chief Executive Officer; Cedrik Neike, Matthias Rebellius, Ralf P. Thomas, Judith Wiese; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin-Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

---

From: Kent Watsen <[email-masked]>
Date: Tue, 20 Jul 2021 13:55:45 +0000

Hi Hendrik, et. al.,

The other matter is under AD review as well.  I’m currently waiting to see the final text in the SZTP-CSR draft (thank you, and David too, CC-ed).  Once the dust settles there, I’ll look at what can be done.  At a minimum, there seems to be an opportunity to move, to typedefs for “cmc” and “cmp” to the "ietf-crypto-types” module.

Kent // co-author of both drafts “sztp-csr” and "crypto-types”

> On Jul 20, 2021, at 8:19 AM, Brockhaus, Hendrik <[email-masked]> wrote:
> 
> Kent, Russ, Sean
>

---

From: "Fries, Steffen" <[email-masked]>
Date: Wed, 21 Jul 2021 09:23:25 +0000

Hi Kent,

Thank you for addressing this point (hope I understood your previous email correctly in that sense).
 
If we (BRSKI-AE authors) can provide support here let us know. Having a solution independent CSR type, which can be used directly would be good. As noted by Hendrik, in BRSKI-AE we utilize plain P10 so far and provide an own wrapping signature. Using the -types approach (to my understanding) makes it more easy to have the flexibility to also support certification requests, which already come with an own wrapping signature like in CMP or CMC. 

Best regards
Steffen

> -----Original Message-----
> From: Kent Watsen <[email-masked]>
> Sent: Dienstag, 20. Juli 2021 15:56
> To: Brockhaus, Hendrik (T RDA CST SEA-DE)
> <[email-masked]>
> Cc: [email-masked]; [email-masked]; Michael
> Richardson <[email-masked]>; Fries, Steffen (T RDA CST)
> <[email-masked]>; Werner, Thomas (T RDA CST SEA-DE)
> <[email-masked]>; von Oheimb, David (T RDA CST SEA-DE)
> <[email-masked]>
> Subject: Re: [netconf] Reuse of SZTP-CSR YANG definition in BRSKI-AE
> 
> Hi Hendrik, et. al.,
> 
> The other matter is under AD review as well.  I’m currently waiting to see the
> final text in the SZTP-CSR draft (thank you, and David too, CC-ed).  Once the
> dust settles there, I’ll look at what can be done.  At a minimum, there seems
> to be an opportunity to move, to typedefs for “cmc” and “cmp” to the "ietf-
> crypto-types” module.
> 
> > I was not involved in the discussion of reusing the Yang Module in BRSKI-AE
> some weeks back. But we would like to use the momentum that draft-ietf-
> netconf-sztp-csr is currently opened for editing for CMP specific corrections
> in the YANG module ietf-sztp-csr for brining up this discussion again.
> >
> > In BRSKI-AE
> >
> (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdat
> > atracker.ietf.org%2Fdoc%2Fdraft-ietf-anima-brski-async-enroll%2F&amp;d
> > ata=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com
> >
> %7C250e55485bd94d68365608d94b8613a6%7C38ae3bcd95794fd4addab42e14
> 95d55a
> >
> %7C1%7C0%7C637623862521802710%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAw
> >
> MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sda
> ta=M7
> >
> fY8oKOMLUxnMmpM6o2fazibyZXYfY2%2F2%2FsnB6FV5k%3D&amp;reserve
> d=0) we
> > address a use case in which we use a signature wrapped CSR, for which
> > we would like to re-use the existing YANG definition in SZTP (see also
> > the discussion in the thread
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> >
> archive.ietf.org%2Farch%2Fmsg%2Fnetconf%2FAFFqdeYJll9IndkQfT6scXWct
> 6U%
> > 2F&amp;data=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.sie
> >
> mens.com%7C250e55485bd94d68365608d94b8613a6%7C38ae3bcd95794fd4a
> ddab42e
> >
> 1495d55a%7C1%7C0%7C637623862521802710%7CUnknown%7CTWFpbGZsb3
> d8eyJWIjoi
> >
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300
> 0&amp;
> >
> sdata=lCJn7Z%2FaY38Umxf%2FRPF7WQZTqDUTGqSTlC6Vx%2BGypog%3D&a
> mp;reserve
> > d=0) As BRSKI-AE  currently only utilize the CSR type part without the
> > SZTP bootstrapping server information, it would be advantageous for
> BRSKI-AE (for general applicability) to extract the CSR types into a separate
> YANG module, which could be imported by the YANG module ietf-sztp-csr
> and can be re-used also by BRSKI-AE. This would avoid a potential protocol
> specific definition of CSR types for SZTP and BRSKI-AE with most likely the
> same content. In addition, while BRSKI-AE currently only utilizes P10, it would
> open the possibility to also utilize other certification request types in the
> future.
> > We would like to ask if you see an opportunity for this change (separate
> ietf-csr-types YANG module as part of draft-ietf-sztp-csr) at this point in
> time.
> >
> > Hendrik
> >
> > Siemens AG
> > Technology
> > Research in Digitalization and Automation Security Architecture T RDA
> > CST SEA-DE Otto-Hahn-Ring 6
> > 81739 Muenchen, Germany
> > Tel.: +49 89 7805-22411
> > Fax: +49 89 7805-29116
> > Mobile: +49 174 1517765
> > Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim
> > Hagemann Snabe; Managing Board: Roland Busch, Chairman, President and
> > Chief Executive Officer; Cedrik Neike, Matthias Rebellius, Ralf P.
> > Thomas, Judith Wiese; Registered offices: Berlin and Munich, Germany;
> > Commercial registries: Berlin-Charlottenburg, HRB 12300, Munich, HRB
> > 6684; WEEE-Reg.-No. DE 23691322