Change:
move YANG to RFC8366bis
Some corrections are necessary regarding the referenced fields defined. BRSKI-PRM specifies the agent-provided-registrar-certificate in contrast to the registar-proximity-certificate. Will be addressed in the next commit.

Discussion:
excluding the ASN.1 encoding of "OCTET STRING" of the LDevID(RegAgt) certificate. <del> The body of the agent-signed-data contains an "ietf-voucher-request- prm:agent-signed-data" element (defined in voucher-request-prm-yang): </del> <ins> The body of the agent-signed-data contains an "ietf-voucher- request:agent-signed-data" element (defined in RFC8366bis): </ins> created-on: MUST contain the creation date and time in yang:date- and-time format.

data (as defined in asd) and provided as trigger parameter. The enhancements of the YANG module for the ietf-voucher-request with <del> these new leaves are defined in voucher-request-prm-yang. </del> <ins> these new leaves are defined in RFC8366bis. </ins> The PVR is signed using the pledge's IDevID credential contained as x5c parameter of the JOSE header.

prior-signed-voucher-request: PVR as in The RVR MUST be enhanced with the following parameter, when the <del> assertion "agent-proximity" is requested, as defined in voucher- request-prm-yang: </del> <ins> assertion "agent-proximity" is requested, as defined in RFC8366bis: </ins> agent-sign-cert: LDevID(RegAgt) certificate or the LDevID(RegAgt) certificate including certificate chain.  In the context of this

7.1. <del> The following enhancement extends the voucher-request as defined in RFC8995 to include additional fields necessary for handling bootstrapping in the pledge-responder-mode. 7.1.1. The following tree diagram is mostly a duplicate of the contents of RFC8995, with the addition of the fields agent-signed-data, registrar-proximity-certificate, and agent-signing certificate.  The tree diagram is described in RFC8340.  Each node in the diagram is fully described by the YANG module in Section voucher-request-prm- yang-module. 7.1.2. The following YANG module extends the RFC8995 Voucher Request to include a signed artifact from the registrar-agent (agent-signed- data) as well as the registrar-proximity-certificate and the agent- signing certificate. </del> <ins> RFC8366bis extends the voucher-request as defined in RFC8995 to include additional fields necessary for handling bootstrapping in the pledge-responder-mode.  They are: agent-signed-data, registrar- proximity-certificate, and agent-signing certificate. </ins> Examples for the PVR are provided in exchanges_uc2_2.

10.5. <del> The enhanced voucher-request described in section voucher-request- prm-yang is bases on RFC8995, but uses a different encoding based on I-D.ietf-anima-jws-voucher.  Therefore similar considerations as described in RFC8995 section 11.7 (Security Considerations) apply. The YANG module specified in this document defines the schema for data that is subsequently encapsulated by a JOSE signed-data Content- type as described in I-D.ietf-anima-jws-voucher.  As such, all of the YANG-modeled data is protected against modification.  The use of YANG to define data structures via the "yang-data" statement, is relatively new and distinct from the traditional use of YANG to define an API accessed by network management protocols such as NETCONF RFC6241 and RESTCONF RFC8040.  For this reason these </del> <ins> The enhanced voucher-request described in RFC8366bis is based on RFC8995, but uses a different encoding based on I-D.ietf-anima-jws- voucher.  The security considerations as described in RFC8995 section 11.7 (Security Considerations) apply. The YANG module specified in RFC8366bis defines the schema for data that is subsequently encapsulated by a JOSE signed-data Content-type as described in I-D.ietf-anima-jws-voucher.  As such, all of the YANG-modeled data is protected against modification. The use of YANG to define data structures via the RFC8971 "structure" statement, is relatively new and distinct from the traditional use of YANG to define an API accessed by network management protocols such as NETCONF RFC6241 and RESTCONF RFC8040.  For this reason these </ins> guidelines do not follow the template described by RFC8407 section 3.7 (Security Considerations Section).