> On 28. Feb 2018, at 23:46, Michael Richardson <[email protected]> wrote: > > Fries, Steffen <[email protected]> wrote: >> The current BRSKI draft addresses the bootstrapping of a secure >> infrastructure based on existent manufacturer certificates. This is for >> sure a basic requirement in industrial applications to enable secure >> service deployment or device integration. The current document utilizes >> EST to provide a realization example for the BRSKI approach. This >> already fits perfect for the energy automation domain, as EST is >> already been envisioned/utilized as enrollment protocol in IEC defined >> security. As we experience, there are other scenarios like industrial >> automation or intelligent traffic systems, which feature different >> enrollment approaches, like CMP, but could leverage the generic BRSKI > > Just to be sure, you are talking about: https://tools.ietf.org/html/rfc4210 Yes, exactly. It is utilized by most (if not all) of the CAs I’m aware of. > >> approach, we would like to propose to also consider CMP as further >> example for BRSKI. In contrast to EST, CMP builds on a self-contained >> container, which are independent from the transport. Hence, they can be >> easily processed in online (connected) or offline scenarios, even if no >> direct network access is possible. As CMP is very versatile, there is >> the option to profile the protocol to only support the features needed >> for a specific application. The LTE profile of CMP is one example of >> "simplifying" CMP by requiring only 3 Handshake messages to be >> supported. This profiling reduces the burden on the device implementing >> CMP to not support all of its features. > >> Even though the BRSKI document is already advanced, we would like to >> propose to also include CMP as further example for certificate >> enrollment in BRSKI. This inclusion would make it also easier for other >> standards or frameworks to consider security bootstrapping based on >> BRSKI. > > I think that it would be very difficult to hack CMP into the BRSKI document > at this point. Based on CMPs complexity? That was the reason to mention the LTE profile. Not as a transport for CMP but rather as example how to streamline CMP to the functionality needed.
Or was it based on the timeline for the BRSKI document? Best regards Steffen > >> I hope it is okay to raise the question of scope enhancements of BRSKI >> in terms of mapped enrollment protocols on the mailing list and not >> wait till the next IETF meeting regarding a discussion. If this >> proposal is accepted, we are very eager on providing a mapping section >> for the draft using a similar approach as section 5 takes for defining >> BRSKI as extension to EST. > >> Any thoughts regarding such an enhancement? > >> Best regards Steffen > > >> -- >> Steffen Fries Siemens AG Corporate Technology Research and Development >> for Digitalization and Automation IT Security CT RDA ITS Otto-Hahn-Ring >> 6 81739 Muenchen, Germany Tel.: +49 89 636-633604 Fax: +49 89 636-48000 >> mailto:[email protected] >> www.siemens.com/ingenuityforlife<https://siemens.com/ingenuityforlife> > >> Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard >> Cromme; Managing Board: Joe Kaeser, Chairman, President and Chief >> Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina >> Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices: >> Berlin and Munich, Germany; Commercial registries: Berlin >> Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 > >> _______________________________________________ Anima mailing list >> [email protected] https://www.ietf.org/mailman/listinfo/anima > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] [email protected] http://www.sandelman.ca/ | ruby on rails > [ > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
