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 > 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. > 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
