Hello Toerless, hello Michael, we had some further discussion on the intended functionality addressed, which was the reason for the proposed split.
Two functional approaches are considered: A: Handling situations in which the pledge implements a different enrollment protocol but keeps the voucher exchange as is. BRSKI distinguishes already between voucher handling and enrollment handling through different endpoints. This distinction is used in BRSKI-AE use case 1 by showing how to utilize an alternative enrollment protocol. BRSKI-AE use case 1 is focusing on the enrollment only and reuses the voucher handling as is. B: Handling situations in which there is no connection between pledge and registrar. Offline cases between the registrar and other components in the backend may already be handled using BRSKI means. In BRSKI the registrar is assumed to be the component that authorizes domain membership based on voucher exchanges and acts as registration authority (RA) for the enrollment exchanges. This relates to two different approaches for offline or no direct connections between pledge and registrar: - Pledge is initiator: If the pledge is not connected to the registrar, the bootstrapping process as defined in BRSKI may not be possible as it relies on the TLS connection between the pledge and the registrar. Loosing the benefits of the TLS connection results in a new approach for BRSKI exchanges. Note temporarily offline pledges are not addressed here. - Pledge is responder: Situation addressed by BRSKI-AE use case 2. BRSKI-AE introduces the registrar-agent, which interacts with the pledge and the registrar to fetch the voucher/enrollment requests and also provides the corresponding responses. The registrar-agent itself acts as an initiator to the pledge and to the registrar. Note that the registrar-agent may be part of a commissioning tool or of the registrar itself. Registrar-agent deployment on the registrar enables online interactions with both, pledges in initiator mode or responder mode. Based on the points above we see the problem space and propose the split: A: Informative document outlining the use of an alternative enrollment protocol in BRSKI. B: Normative document specifying responder mode of pledges in BRSKI. Best regards Thomas > -----Original Message----- > From: Anima <[email protected]> On Behalf Of Fries, Steffen > Sent: Freitag, 3. September 2021 20:57 > To: Michael Richardson <[email protected]>; [email protected]; [email protected] > Subject: Re: [Anima] BRSKI-AE document split discussion > > Hi Toerless, hi Michael > > > -----Original Message----- > > From: Michael Richardson <[email protected]> > > Sent: Freitag, 3. September 2021 19:09 > > > > [email protected] <[email protected]> wrote: > > > plant would often want to have a combination of both scenarios: > > > The manufacturing plant might prefer to not be connected to the > > > Internet (== scenario 1) AND pledges want to be of the type defined > > > via Scenario 2. > > > > Will we be able to avoid normative cross-references? Probably not. > > So the documents will progress together. > The problem space that we had in mind regarding the split should address this > by: > A: An informative document outlining the use of alternative enrollment > protocols in BRSKI. As BRSKI already distinguishes between the > endpoints for voucher handling and enrolment handling, the introduction of an > alternative enrollment should be straight forward as > outlined in the latest async draft. BRSKI is not prescriptive regarding the > protocol used from the Registrar (as RA) to the CA. Handling > of offline situation with respect to enrollment could thus also be part of an > operational considerations document. Offline voucher > exchanges are already considered in BRSKI by using nonceless vouchers. > > B: A normative document specifying responder mode of pledges. This is what > use case 2 addresses by introducing the registrar-agent. > Depending on the deployment, the registrar-agent may be part of a > commissioning tool, to provide support when there is no > connectivity to the registrar. Alternatively, the registrar-agent may be part > of the registrar itself. This enables (online) interactions > with pledges in initiator mode and pledges in responder mode. > > > > > I think that where we will benefit will be in the review/reader point of > > view. > > > > > Meaning: I would not exclude the option yet, to split the document in > > > 3: One that is the inclusive "reference/architecture" document that > > > we keep alive and extend with whatever we need to keep in common, > > > and then 2 or maybe over time more protocol specification parts of > > > the pieces we are adding. > > > > I would call the third document the applicability statement for uses > > in industry FOO. > Or it may be part of an operational considerations document that addresses > different architecture deployment options. > > Regards > Steffen > > > > > > -- > > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) > > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > > > > _______________________________________________ > Anima mailing list > [email protected] > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fanima&data=04 > %7C01%7Cthomas- > werner%40siemens.com%7Ced1178047ed34707b50408d96f0cbbf5%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637662 > 922756618491%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C10 > 00&sdata=GTub%2BiCgzD19iVeXqIlED0nkSGg2h8e1Fzd%2BgH4gsVk%3D&reserved=0 _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
