Dear Gunter, Thank you for your comments. I made my comments to yours inline.
> -----Original Message----- > From: Gunter Van de Velde via Datatracker <nore...@ietf.org> > Sent: Monday, April 14, 2025 1:45 PM > To: The IESG <i...@ietf.org> > Cc: draft-ietf-anima-brski-...@ietf.org; anima-cha...@ietf.org; > anima@ietf.org; > i...@kovatsch.net; t...@cs.fau.de; i...@kovatsch.net > Subject: Gunter Van de Velde's No Objection on draft-ietf-anima-brski-prm-18: > (with COMMENT) > > Gunter Van de Velde has entered the following ballot position for > draft-ietf-anima-brski-prm-18: No Objection > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel free to cut this introductory > paragraph, however.) > > > Please refer to > https://www.ietf.org/ > %2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot- > positions%2F&data=05%7C02%7Csteffen.fries%40siemens.com%7C7ad3bc0e323 > 84a1b0df208dd7b49c06b%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0% > 7C638802278872104468%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D > %3D%7C0%7C%7C%7C&sdata=NjV9YsW8aqEe2EShkT4Q5uOHcRm%2B%2Bh9 > wxfeo922h5AU%3D&reserved=0 > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.i/ > etf.org%2Fdoc%2Fdraft-ietf-anima-brski- > prm%2F&data=05%7C02%7Csteffen.fries%40siemens.com%7C7ad3bc0e32384a1 > b0df208dd7b49c06b%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C63 > 8802278872134963%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW > UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D% > 7C0%7C%7C%7C&sdata=RRvfnvSPsQWeUQ59nGeAOgd2Cexm%2BIV%2BsiVX9 > sMGNsE%3D&reserved=0 > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > # Gunter Van de Velde, RTG AD, comments for draft-ietf-anima-brski-prm-18 > > # The line numbers used are rendered from IETF idnits tool: > https://author-/ > tools.ietf.org%2Fapi%2Fidnits%3Furl%3Dhttps%3A%2F%2Fwww.ietf.org%2Farchi > ve%2Fid%2Fdraft-ietf-anima-brski-prm- > 18.txt&data=05%7C02%7Csteffen.fries%40siemens.com%7C7ad3bc0e32384a1b0 > df208dd7b49c06b%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6388 > 02278872156142%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU > sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7 > C0%7C%7C%7C&sdata=KJ%2BkyU7VraeKtDLbz6fIpH2egSSmnkPZI0EiDrKSm3s > %3D&reserved=0 > > # for your convenience, please find some non-blocking COMMENTS > > # My review is rather generic and high level, it is not my area of expertise. > If my comments refer to items obvious when familiar with the technology, then > feel free to ignore. > > # comments > # ======== > > 14 Abstract > > GV> Would this abstract be a viable alternative? > > " > This document defines the BRSKI-PRM (Pledge in Responder Mode) variant of the > Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. BRSKI-PRM > supports the secure enrollment of devices, referred to as pledges, into a > domain where direct communication with the registrar is not possible. Instead, > the pledges interact with a proxy entity that relays authenticated and > authorized enrollment requests to the registrar. This approach accommodates > deployment scenarios where network constraints, operational considerations, or > topological factors prevent direct pledge-to-registrar communication. The > protocol extensions defined in this document maintain the security and trust > properties of BRSKI while enabling broader applicability in constrained or > segmented environments. " [stf] Your proposal for an updated abstract reads good in general but misses some details, we would like to emphasize. One relates to the reversal of the interaction model. I tried to create a mixture of both, the old abstract and your suggestions. OLD This document defines enhancements to Bootstrapping a Remote Secure Key Infrastructure (BRSKI, RFC8995) to enable bootstrapping in domains featuring no or only limited connectivity between a pledge and the domain registrar. It specifically changes the interaction model from a pledge-initiated mode, as used in BRSKI, to a pledge-responding mode, where the pledge is in server role. For this, BRSKI with Pledge in Responder Mode (BRSKI-PRM) introduces new endpoints for the Domain Registrar and pledge, and a new component, the Registrar-Agent, which facilitates the communication between pledge and registrar during the bootstrapping phase. To establish the trust relation between pledge and registrar, BRSKI-PRM relies on object security rather than transport security. This approach is agnostic to the enrollment protocol that connects the domain registrar to a Key Infrastructure (e.g., domain Certification Authority). NEW This document defines enhancements to Bootstrapping Remote Secure Key Infrastructure (BRSKI, RFC8995) as BRSKI with Pledge in Responder Mode (BRSKI-PRM). BRSKI-PRM supports the secure bootstrapping of devices, referred to as pledges, into a domain where direct communication with the registrar is either limited or not possible at all. To facilitate interaction between a pledge and a domain registrar the registrar-agent is introduced as new component. The registrar-agent supports the reversal of the interaction model from a pledge-initiated mode, to a pledge-responding mode, where the pledge is in a server role. To establish the trust relation between pledge and registrar, BRSKI-PRM relies on object security rather than transport security. This approach is agnostic to enrollment protocols that connect a domain registrar to a key infrastructure (e.g., domain Certification Authority). > > 183 Security information about the customer domain, specifically the > 184 customer domain certificate, are exchanged and authenticated > 185 utilizing signed data objects, the voucher artifacts as defined in > 186 [RFC8995]. > > GV> original text reads odd. Revised textblob: > > " > Security information pertaining to the customer domain, specifically, the > customer domain certificate, is exchanged and authenticated through the use of > signed data objects, namely the voucher artifacts, as defined in [RFC8995]. " [stf] Accepted with a small change: "Security information pertaining to the customer domain, specifically, the customer domain certificate, is exchanged and authenticated through the use of signed data objects, namely the voucher artifacts, as defined in [I-D.ietf-anima-rfc8366bis]." > > 3789 10.2. Service Name and Transport Protocol Port Number Registry > 3790 > 3791 IANA has registered the following service names: > 3792 > 3793 *Service Name:* brski-pledge > 3794 *Transport Protocol(s):* tcp > 3795 *Assignee:* IESG i...@ietf.org (mailto:i...@ietf.org) > 3796 *Contact:* IETF Chair ch...@ietf.org (mailto:ch...@ietf.org) > 3797 *Description:* The Bootstrapping Remote Secure Key Infrastructure > 3798 Pledge > 3799 *Reference:* [THISRFC] > > GV> Does this need to be the iesg and the chair to be as assignee and contact? > At first glance this looks unusual. This seems to have happened in v18 of the > draft. [stf] We got the comments leading to the actual statement from the IANA review and was updated in the last version. Best regards Steffen > > Gunter Van de Velde > RTG Area Director > > _______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
