Hi Michael > -----Original Message----- > From: Michael Richardson <[email protected]> > Sent: Dienstag, 3. August 2021 18:28 > > Fries, Steffen <[email protected]> wrote: > > 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. > > I thought that the enrollment objects in use case 2 could be CMP objects. Yes it could be. What is specified in use case 2 is currently based on JOSE and realizes a simple wrapper of a PKCS#10 to be able to utilize the BRSKI enrollment endpoint on a registrar. Different pledges may support different enrollment formats. The assumption is that one pledge supports only one enrollment format. The pledge-enrollment-request format can be signaled via the content type header in the pledge's response. If other formats for the pledge-enrollment-request are used like CMP, it would require additional logic at the registrar-agent to be able to select the corresponding endpoints at the registrar. We have not included this so far, but if the pledge would support CMP, we could reference use case 1 from use case 2 for the communication from the registrar-agent to the registrar.
Best 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://www.ietf.org/mailman/listinfo/anima
