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.
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
