Hi Michael, hi Brian, > -----Original Message----- > From: Brian E Carpenter <[email protected]> > Sent: Montag, 2. August 2021 23:07 > On 03-Aug-21 07:55, Michael Richardson wrote: > > > > Fries, Steffen <[email protected]> wrote: > > > Based on the discussion in the ANIMA WG last week, I would like to > > > proceed with the discussion on the author's proposal to split the > > > current BRSKI-AE draft > > > > (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata > tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-anima-brski-async-enroll- > 03&data=04%7C01%7Ccef9763c-149c-4881-b9c2- > 5fedc277663a%40ad011.siemens.com%7C01cc5c134fa141586f2c08d955f9702 > d%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6376353520778173 > 88%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM > zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VikJIzx0apXELx7 > q8yDp7hVwgHnEU3HwIvPq6nAlZk8%3D&reserved=0) > > > to separate the contained use cases as they have developed > > > differently. We did not finish the discussion during the meeting > > during > > > lack of time, but for the way forward I would like to ask for support > > > from the chairs to find the decision. I included this question also as > > > open issue in the ANIMA github > > > > > (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit > > hub.com%2Fanima-wg%2Fanima-brski-async- > enroll%2Fissues%2F19&data=0 > > 4%7C01%7Ccef9763c-149c-4881-b9c2- > 5fedc277663a%40ad011.siemens.com%7C01 > > > cc5c134fa141586f2c08d955f9702d%7C38ae3bcd95794fd4addab42e1495d55a% > 7C1% > > > 7C0%7C637635352077817388%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4 > wLjAwMDAiL > > > CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jxU > xUpv > > XcTLXNjcXwRMgEUxtA7TlK1RzMyJpOM%2BXWks%3D&reserved=0) > > > > > Declaration of conformity to "AE" is difficult, as the use cases have > > > developed in different directions. Therefore the proposal to split the > > > draft into two separate documents for use case 1 and use case 2. We > may > > > also discuss, what the target for each document would be > (informational > > > / standard RFC). > > > > ... > > > > > If the WG is in favor of the split, the expectation would be that the > > > resulting document would proceed as WG documents. > > > > Are there common parts that would argue for three documents > > (B--referencing-->A, and C--referencing-->A) > > That was my question too. Splitting the document but having Part 1 > normatively reference Part 2 would be unfortunate. > > > "A" could also be RFC8366bis. > > Then we'd have 3 documents as an AUTH48 cluster, right? But if the result is a > more logical set of documents for future readers, it's the right thing to do. >
The two use cases have technically less in common regarding the specific realization. Both are intended for scenarios in which the pledge has no or limited connectivity to a backend. Use Case 1 is relying on RFC 8995 for communication flow and for the voucher handling, but targets to use alternative enrollment protocols to achieve a proof-of-identity binding to the certification request directly without relying on TLS to be able to "store and forward "certification requests". For alternative enrollment, use case 1 could use the Lightweight CMP profile https://datatracker.ietf.org/doc/draft-ietf-lamps-lightweight-cmp-profile/ to achieve its goal. So this document would have no reference to use case 2. Use case 2, as currently described, instead reverses the communication flow to let the pledge be a server by introducing the registrar-agent as new component. The communication between the registrar-agent and the pledge is defined based on the exchange of JOSE objects, which provide proof-of-identity on a message level to be independent of an underlying TLS connection. This also allows to utilize BTLE for instance as transport. The communication from the registrar-agent to the registrar is kept as close as possible to BRSKI by relying on an enhanced voucher and utilizing EST with enhanced objects for enrollment. Based on that, use case 2 document would not reference use case 1 document. So a way forward could be to simply take the use case 2 from the current BRSKI-AE document into a new document and add a motivation/use case for reversing the call flow as well as the targeted solution approach. From the scenarios, currently available in the draft, some could be adopted also for use case 2. Regarding the existing use case 1, the text is stable for quite a while now, and the authors think it should be easier to advance the draft faster because of this. That said, I don’t see a real need to have three documents and would propose to stick to the 2. One could argue to take out the application examples (2 pages) as a separate document, but I don’t think this justifies the effort. Best regards Steffen _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
