BRSKI with Pledge in Responder Mode (BRSKI-PRM)

3.1. Supported Environments and Use Case Examples

BRSKI-PRM is applicable to scenarios where pledges may have no direct connection to the domain registrar, may have no continuous connection, or require coordination of the pledge requests to be provided to a domain registrar.¶

This can be motivated by pledges deployed in environments not yet connected to the operational customer domain network, e.g., at a building construction site, or environments intentionally disconnected from the Internet, e.g., critical industrial facilities. Another example is the assembly of electrical cabinets, which are prepared in advance before the installation at a customer domain.¶

3.2. Limitations

The mechanism described in this document presumes the ability of the pledge and the Registrar-Agent to communicate with another. This may not be possible in constrained environments where, in particular, power must be conserved. In these situations, it is anticipated that the transceiver will be powered down most of the time. This presents a rendezvous problem: the pledge is unavailable for certain periods of time, and the Registrar-Agent is similarly presumed to be unavailable for certain periods of time. To overcome this situation, the pledges may need to be powered on, either manually or by sending a trigger signal.¶

5.1. Overview

For BRSKI with Pledge in Responder Mode (BRSKI-PRM), the base system architecture defined in BRSKI [RFC8995] is enhanced to facilitate new use cases in which the pledge acts as server. The responder mode allows delegated bootstrapping using a Registrar-Agent instead of a direct connection between the pledge and the domain registrar.¶

Necessary enhancements to support authenticated self-contained objects for certificate enrollment are kept at a minimum to enable reuse of already defined architecture elements and interactions. The format of the bootstrapping objects produced or consumed by the pledge is usually based on JSON Web Signature (JWS) [RFC7515] and further specified in Section 7 to address the requirements stated in Section 4 above. In constrained environments, it may be based on COSE [RFC9052].¶

An abstract overview of the BRSKI-PRM protocol can be found on slide 8 of [BRSKI-PRM-abstract].¶

To support mutual trust establishment between the domain registrar and pledges not directly connected to the customer domain, this document specifies the exchange of authenticated self-contained objects with the help of the Registrar-Agent.¶

This leads to extensions of the logical components in the BRSKI architecture as shown in Figure 1.¶

Note that the Join Proxy is not shown in the figure. In certain situations the Join Proxy may still be present and could be used by the Registrar-Agent to connect to the Registrar. For example, a Registrar-Agent application on a smartphone often can connect to local Wi-Fi without giving up their cellular network connection [androidnsd], but only can make link-local connections.¶

The Registrar-Agent interacts with the pledge to transfer the required data objects for bootstrapping, which are then also exchanged between the Registrar-Agent and the domain registrar. The addition of the Registrar-Agent influences the sequences of the data exchange between the pledge and the domain registrar described in [RFC8995]. To enable reuse of BRSKI defined functionality as much as possible, BRSKI-PRM:¶

• uses existing endpoints where the required functionality is provided.¶

• enhances existing endpoints with new supported media types, e.g., for JWS voucher.¶

• defines new endpoints where additional functionality is required, e.g., for wrapped certification request, wrapped CA certificates, and new status information.¶

Figure 1 shows the relations between the following main components:¶

• Pledge: Is expected to respond with the necessary data objects for bootstrapping to the Registrar-Agent. The protocol used between the pledge and the Registrar-Agent is assumed to be HTTP(S) in the context of this document. Any other protocol can be used as long as it supports the exchange of the necessary artifacts. This includes CoAP or protocol to be used over Bluetooth or NFC connections. A pledge acting as server leads to the following differences compared to BRSKI [RFC8995]:¶

  • The pledge no longer initiates bootstrapping, but is discovered and triggered by the Registrar-Agent as defined in Section 6.1.2.¶

  • The pledge offers additional endpoints as defined in Section 6.2, so that the Registrar-Agent can request data required for bootstrapping the pledge.¶

  • The pledge includes additional data in the PVR, which is provided and signed by the Registrar-Agent as defined in Section 7.1. This allows the registrar to identify with which Registrar-Agent the pledge was in contact (see Section 5.4).¶

  • The artifacts exchanged between the pledge and the registrar via the Registrar-Agent are authenticated self-contained objects (i.e., signature-wrapped artifacts).¶

• Registrar-Agent: Is a new component defined in Section 6.1 that provides a store and forward communication path to exchange data objects between the pledge and the domain registrar. This is for situations in which the domain registrar is not directly reachable by the pledge, which may be due to a different technology stacks or due to missing connectivity. A Registrar-Agent acting as client leads to the following new aspects:¶

  • The order of exchanges in the BRSKI-PRM call flow is different from that in BRSKI [RFC8995], as the Registrar-Agent can trigger one or more pledges and collects the PVR and PER artifacts simultaneously as defined in Section 7. This enables bulk bootstrapping of several devices.¶

  • There is no trust assumption between the pledge and the Registrar-Agent as only authenticated self-contained objects are used, which are transported via the Registrar-Agent and provided either by the pledge or the domain registrar.¶

  • The trust assumption between the Registrar-Agent and the domain registrar may be based on EE certificates that are both signed by the domain owner.¶

  • The Registrar-Agent may be realized as stand-alone component supporting nomadic activities of a service technician moving between different installation sites.¶

  • Alternatively, the Registrar-Agent may also be realized as co-located functionality for a registrar, to support pledges in responder mode.¶

• Join Proxy (not shown): Has the same functionality as described in [RFC8995] if needed. Note that a Registrar-Agent may use a join proxy to facilitate the TLS connection to the registrar in the same way that a BRSKI pledge would use a join proxy. This is useful in cases where the Registrar-Agent does not have full IP connectivity via the domain network or cases where it has no other means to locate the registrar on the network.¶

• Domain registrar: In general fulfills the same functionality regarding the bootstrapping of the pledge in a customer domain by facilitating the communication of the pledge with the MASA service and the domain key infrastructure (PKI). However, there are also differences compared to BRSKI [RFC8995]:¶

  • A BRSKI-PRM domain registrar does not interact with a pledge directly, but through the Registrar-Agent as defined in Section 7.¶

  • A BRSKI-PRM domain registrar offers additional endpoints as defined in Section 6.3 to support the signature-wrapped artifacts used by BRSKI-PRM.¶

• Vendor services: Encompass MASA and Ownership Tracker and are used as defined in [RFC8995]. A MASA responsible for pledges that implement BRSKI-PRM is expected to support BRSKI-PRM extensions:¶

  • The default format for voucher artifacts (incl. voucher-request) is JWS-signed JSON as defined in [I-D.ietf-anima-jws-voucher].¶

  • The Agent Proximity Assertion (see Section 5.4) requires additional validation steps as defined in Section 7.3.1.¶

5.2. Nomadic Connectivity

In one example instance of the PRM architecture as shown in Figure 2, there is no connectivity between the location in which the pledge is installed and the location of the domain registrar. This is often the case in the aforementioned building automation use case (Section 3.1.1).¶

PRM enables support of this case through nomadic connectivity of the Registrar-Agent. To perform enrollment in this setup, multiple round trips of the Registrar-Agent between the pledge installation location and the domain registrar are required.¶

1. Connectivity to domain registrar: preparation tasks for pledge bootstrapping not part of the BRSKI-PRM protocol definition, like retrieval of list of pledges to enroll.¶

2. Connectivity to pledge installation location: retrieve information about available pledges (IDevID), collect request objects (i.e., Pledge Voucher-Requests and Pledge Enroll-Requests using the BRSKI-PRM approach described in Section 7.1 and Section 7.2).¶

3. Connectivity to domain registrar, submit collected request information of pledges, retrieve response objects (i.e., Voucher and Enroll-Response) using the BRSKI-PRM approach described in Section 7.3 and Section 7.4.¶

4. Connectivity to pledge installation location, provide retrieved objects to the pledges to enroll pledges and collect status using the BRSKI-PRM approach described in Section 7.6, Section 7.7, and Section 7.8.¶

5. Connectivity to domain registrar, submit Voucher Status and Enrollment Status using the BRSKI-PRM approach described in Section 7.9 and Section 7.10.¶

Variations of this setup include cases where the Registrar-Agent uses for example WiFi to connect to the pledge installation network, and mobile network connectivity to connect to the domain registrar. Both connections may also be possible in a single location at the same time, based on installation building conditions.¶

5.3. Co-located Registrar-Agent and Domain Registrar

Compared to [RFC8995] BRSKI, pledges supporting BRSKI-PRM can be completely passive and only need to react when being requested to react by a Registrar-Agent. In [RFC8995], pledges instead need to continuously request enrollment from a domain registrar, which may result in undesirable communications pattern and possible overload of a domain registrar.¶

The benefits of BRSKI-PRM can be achieved even without the operational complexity of standalone Registrar-Agents by integrating the necessary functionality of the Registrar-Agent as a module into the domain registrar as shown in Figure 3 so that it can support the BRSKI-PRM communications to the pledge.¶

5.4. Agent Proximity Assertion

"Agent proximity" is a statement in the PVR and the voucher that the registrar communicated via the Registrar-Agent as defined in Section 7 and not directly to the pledge. It is therefore a different assertion than "network proximity", which is defined in Section 3 of [RFC8995]. Hence, [I-D.ietf-anima-rfc8366bis] defines the additional assertion type agent-proximity. This assertion type can be verified by the registrar and MASA during BRSKI-PRM voucher-request processing.¶

In BRSKI, the pledge verifies POP of the registrar end-entity (EE) credentials via the TLS handshake and pins that public key as the proximity-registrar-cert into the voucher request. This allows the MASA to verify the proximity of the pledge and registrar, facilitating a decision to assign the pledge to that domain owner. In BRSKI, the TLS session is considered provisional until the pledge receives the voucher to verify POI.¶

In contrast, in BRSKI-PRM the pledge has no direct connection to the registrar and MUST accept the supplied registrar EE certificate provisionally until it receives the voucher as described in Section 7.6 to verify both POP and POI. The provisional registrar EE certificate is used for the object security along the authenticated self-contained objects that in BRSKI-PRM replace the direct TLS connection to the registrar available in BRSKI [RFC8995]. See also Section 5 of [RFC8995] on "provisional state".¶

For the Agent Proximity Assertion, the Registrar-Agent EE certificate and registrar EE certificate must be signed by the same domain owner, i.e., MUST possess a common domain trust anchor in their certificate chain. Akin to the Network Proximity Assertion in BRSKI [RFC8995], the Agent Proximity Assertion provides pledge proximity evidence to the MASA. But additionally, the Agent Proximity Assertion allows the domain registrar to be sure that the PVR supplied by the Registrar-Agent was in fact collected by the Registrar-Agent to which the registrar is connected by utilizing an agent-signed data object.¶

6.1. Registrar-Agent

The Registrar-Agent is a new component in BRSKI-PRM that provides a store and forward communication path with secure message passing between pledges in responder mode and the domain registrar. It uses its own end-entity (EE) certificate and corresponding credentials (i.e., private key) for TLS client authentication and for signing agent-signed data objects.¶

The Registrar-Agent EE certificate MUST include a SubjectKeyIdentifier as defined in Section 4.2.1.2 of [RFC5280], which is used as a reference within agent-signed data objects as defined in Section 7.1.1.1. Note that this is an additional requirement for issuing the Registrar-Agent EE certificate. [RFC8995] has a similar requirement for the registrar EE certificate.¶

The SubjectKeyIdentifier is used in favor of providing the complete Registrar-Agent EE certificate in agent-signed data objects to accommodate also constrained environments and reduce bandwidth needed for communication with the pledge. In addition, it follows the recommendation from BRSKI to use SubjectKeyIdentifier in favor of a certificate fingerprint to avoid additional computations.¶

The provisioning of the Registrar-Agent EE certificate is out of scope for this document, but may be done using its own BRSKI run or by other means such as configuration. It is RECOMMENDED to use short lived Registrar-Agent EE certificates in the range of days or weeks as outlined in Section 11.3.¶

Further, the Registrar-Agent requires the registrar EE certificate to provide it to the pledge. It MAY use the certificate verified during server authentication within an initial TLS session with the registrar; in this case, the Registrar-Agent MUST possess the domain trust anchor (i.e., CA certificate) for the registrar EE certificate to verify the certificate chain. Alternatively, the registrar EE certificate MAY be provided via configuration or a repository. The registrar IP address or hostname is provided either by configuration or by using the discovery mechanism defined in [RFC8995] (see Section 6.1.1).¶

In addition to the certificates, the Registrar-Agent is provided with the product-serial-number(s) of the pledge(s) to be bootstrapped. This is necessary to allow for the discovery of pledges by the Registrar-Agent using DNS-SD with mDNS (see Section 6.1.2). The list may be provided by prior administrative means or the Registrar-Agent may get the information via an (out-of-band) interaction with the pledge. For instance, [RFC9238] describes scanning of a QR code, where the product-serial-number would be initialized from the 12N B005 Product Serial Number data record.¶

In summary, the following information MUST be available at the Registrar-Agent before the interaction with a pledge:¶

• Registrar-Agent EE certificate and corresponding private key: own operational credentials to authenticate and sign agent-signed data¶

• Registrar EE certificate: certificate of the domain registrar to be provided to the pledge¶

• Serial number(s): product-serial-number(s) of pledge(s) to be bootstrapped; used for discovery¶

Further, the Registrar-Agent SHOULD have synchronized time.¶

Finally, the Registrar-Agent MAY possess the IDevID (root or issuing) CA certificate of the pledge manufacturer/vendor to validate the IDevID certificate on returned PVR or in case of optional TLS usage for pledge communication (see Appendix B). The distribution of IDevID CA certificates to the Registrar-Agent is out of scope of this document and may be done by a manual configuration.¶

6.2. Pledge in Responder Mode

In BRSKI-PRM, the pledge is triggered by the Registrar-Agent to create the PVR and PER. It is also triggered for processing of the responses and the generation of status information once the Registrar-Agent has received the responses from the registrar later in the process.¶

To enable interaction as responder with the Registrar-Agent, pledges in responder mode MUST act as servers and MUST provide the endpoints defined in Table 1 within the BRSKI-defined /.well-known/brski/ URI path, except for the OPTIONAL endpoint "qps". The endpoints are defined with short names to also accommodate for resource-constrained devices.¶

HTTP(S) uses the Host header field (or :authority in HTTP/2) to allow for name-based virtual hosting as explained in Section 7.2 of [RFC9110]. This header field is mandatory, and so a compliant HTTP(S) client is going to insert it, which may be just an IP address. The pledge MUST respond to all requests regardless of the Host header field provided by the client (i.e., ignore it). Note that there is no requirement for the pledge to operate its BRSKI-PRM service on port 80 or port 443, so there is no reason for name-based virtual hosting.¶

For instance, when the Registrar-Agent reaches out to the "tpvr" endpoint on a pledge in responder mode with the full URI http://pledge.example.com/.well-known/brski/tpvr, it sets the Host header field to pledge.example.com and the absolute path /.well-known/brski/tpbr. In practice, however, the pledge is usually known by a .local hostname or only its IP address as returned by a discovery protocol, which will be included in the Host header field.¶

As BRSKI-PRM uses authenticated self-contained objects between the pledge and the domain registrar, the binding of the pledge identity to the voucher-requests is provided by the wrapping signature employing the pledge IDevID credential. Hence, pledges MUST have an Initial Device Identifier (IDevID) installed in them at the factory.¶

6.3. Domain Registrar

In BRSKI-PRM, the domain registrar provides the endpoints already specified in [RFC8995] (derived from EST [RFC7030]) where suitable. In addition, it MUST provide the endpoints defined in Table 2 within the BRSKI-defined /.well-known/brski/ Well-Known URI path. These endpoints accommodate for the authenticated self-contained objects used by BRSKI-PRM to provide Pledge Enroll-Request (PER) artifacts and signature-wrapped CA certificates via the Registrar-Agent.¶

The registrar possesses its own EE certificate and corresponding private key for authenticating and signing. It MUST use the same certificate/credentials for authentication in the TLS session with a Registrar-Agent and for signing artifacts for that Registrar-Agent and its pledges (see Section 7.3.6). Overall, this may have operational implications when the registrar is part of a scalable framework as described in Section 1.3.1 of [I-D.richardson-anima-registrar-considerations].¶

According to Section 5.3 of [RFC8995], the domain registrar performs the pledge authorization for bootstrapping within its domain based on the Pledge Voucher-Request. For this, it MUST possess the IDevID trust anchor(s) (i.e., root or issuing CA certificate(s)) of the pledge vendor(s)/manufacturer(s). This behavior is retained in BRSKI-PRM.¶

In its role as EST server [RFC7030], the domain registrar MUST also possess the domain CA certificates as defined in Section 5.9 of [RFC8995].¶

Finally, the domain registrar MUST possess the Registrar-Agent EE certificate(s) to validate agent-signed data and to provide it to the MASA. The registrar MAY use the certificate verified during client authentication within the TLS sessions with the Registrar-Agent; in this case, the registrar MUST possess the domain trust anchor (i.e., domain CA certificate) for the Registrar-Agent EE certificate to verify the certificate chain. Alternatively, the Registrar-Agent EE certificate(s) MAY be provided via configuration or a repository.¶

6.4. MASA

The Manufacturer Authorized Signing Authority (MASA) is a vendor service that generates and signs voucher artifacts for pledges by the same vendor. When these pledges support BRSKI-PRM, the MASA needs to implement the following functionality in addition to BRSKI [RFC8995].¶

A MASA for pledges in responder mode MUST support the voucher format defined in [I-D.ietf-anima-jws-voucher] to parse and process JWS-signed voucher-request artifacts and generate JWS-signed voucher artifacts.¶

Further, a MASA for pledges in responder mode MUST support the Agent Proximity Assertion (see Section 5.4) through the validation steps defined in Section 7.3.1 based on the Pledge Voucher-Request (PVR) and Registrar Voucher-Request (RVR) artifact fields defined in Section 7.1.2 and Section 7.3.4, resp.¶

7.1. Trigger Pledge Voucher-Request

The Registrar-Agent MUST begin the sequence of exchanges by sending the Pledge Voucher-Request Trigger (tPVR). This assumes that the Registrar-Agent has already discovered the pledge, for instance as described in Section 6.1.2 based on DNS-SD or similar.¶

Optionally, TLS MAY be used to provide privacy for this exchange between the Registrar-Agent and the pledge (see Appendix B).¶

Figure 5 shows the acquisition of the Pledge Voucher-Request (PVR) and the following subsections describe the corresponding artifacts.¶

The Registrar-Agent SHALL trigger the pledge to create a PVR via HTTP(S) POST to the pledge endpoint at /.well-known/brski/tpvr. The request body MUST contain the JSON-based Pledge Voucher-Request Trigger (tPVR) artifact as defined in Section 7.1.1. In the request header, the Content-Type field MUST be set to application/json and the Accept field SHOULD be set to application/voucher-jws+json as defined in [I-D.ietf-anima-jws-voucher].¶

Upon receiving a valid tPVR, the pledge MUST reply with the PVR artifact as defined in Section 7.1.2 in the body of an HTTP 200 OK response. In the response header, the Content-Type field MUST be set to application/voucher-jws+json as defined in [I-D.ietf-anima-jws-voucher].¶

Note that the pledge provisionally accepts the registrar EE certificate contained in the tPVR until it receives the voucher (see Section 5.4).¶

If the pledge is unable to create the PVR, it SHOULD respond with an HTTP error status code to the Registrar-Agent. The following client error status codes SHOULD be used:¶

• 400 Bad Request: if the pledge detects an error in the format of the request, e.g., missing field, wrong data types, etc. or if the request is not valid JSON even though the Content-Type request header field was set to application/json¶

• 406 Not Acceptable: if the Accept request header field indicates a type that is unknown or unsupported, e.g., a type other than application/voucher-jws+json¶

• 415 Unsupported Media Type: if the Content-Type request header field indicates a type that is unknown or unsupported, e.g., a type other than application/json¶

The pledge MAY use the response body to signal success/failure details to the service technician operating the Registrar-Agent.¶

  pledgevoucherrequesttrigger = {
    "agent-provided-proximity-registrar-cert": bytes,
    "agent-signed-data": bytes
  }

{
  "agent-provided-proximity-registrar-cert": "base64encodedvalue==",
  "agent-signed-data": BASE64(UTF8(JWS Agent-Signed Data))
}

{
  "payload": BASE64URL(UTF8(JSON Agent-Signed Data)),
  "signatures": [
    {
      "protected": BASE64URL(UTF8(JWS Protected Header)),
      "signature": BASE64URL(JWS Signature)
    }
  ]
}

  prmasd = {
    "created-on": tdate,
    "serial-number": text
  }

{
  "created-on": "2021-04-16T00:00:01.000Z",
  "serial-number": "vendor-pledge4711"
}

{
  "alg": "ES256",
  "kid": "base64encodedvalue=="
}

{
  "payload": BASE64URL(UTF8(JSON PVR Data)),
  "signatures": [
    {
      "protected": BASE64URL(UTF8(JWS Protected Header)),
      "signature": BASE64URL(JWS Signature)
    }
  ]
}

{
  "ietf-voucher-request:voucher": {
     "created-on": "2021-04-16T00:00:02.000Z",
     "nonce": "eDs++/FuDHGUnRxN3E14CQ==",
     "serial-number": "vendor-pledge4711",
     "assertion": "agent-proximity",
     "agent-provided-proximity-registrar-cert": "base64encodedvalue==",
     "agent-signed-data": "base64encodedvalue=="
  }
}

7.2. Trigger Pledge Enroll-Request

Once the Registrar-Agent has received the PVR it can trigger the pledge to generate a Pledge Enroll-Request (PER).¶

Optionally, TLS MAY be used to provide privacy for this exchange between the Registrar-Agent and the pledge (see Appendix B).¶

Figure 14 shows the acquisition of the PER and the following subsections describe the corresponding artifacts.¶

The Registrar-Agent SHALL trigger the pledge to create the PER via HTTP(S) POST to the pledge endpoint at /.well-known/brski/tper. The request body MUST contain the JSON-based Pledge Enroll-Request Trigger (tPER) artifact as defined in Section 7.2.1. In the request header, the Content-Type field MUST be set to application/json and the Accept field SHOULD be set to application/jose+json.¶

Upon receiving a valid tPER, the pledge MUST reply with the PER artifact as defined in Section 7.2.2 in the body of an HTTP 200 OK response. In the response header, the Content-Type field MUST be set to application/jose+json.¶

If the pledge is unable to create the PER, it SHOULD respond with an HTTP error status code to the Registrar-Agent. The following client error status codes MAY be used:¶

• 400 Bad Request: if the pledge detects an error in the format of the request¶

• 406 Not Acceptable: if the Accept request header field indicates a type that is unknown or unsupported, e.g., a type other than application/jose+json¶

• 415 Unsupported Media Type: if the Content-Type request header field indicates a type that is unknown or unsupported, e.g., a type other than application/json¶

The pledge MAY use the response body to signal success/failure details to the service technician operating the Registrar-Agent.¶

pledgeenrollrequesttrigger = {
        "enroll-type": $enroll-type
}

$enroll-type /= "enroll-generic-cert"

{
  "payload": BASE64URL(UTF8(JSON CSR Data)),
  "signatures": [
    {
      "protected": BASE64URL(UTF8(JWS Protected Header)),
      "signature": BASE64URL(JWS Signature)
    }
  ]
}

{
  "ietf-ztp-types": {
     "p10-csr": "base64encodedvalue=="
   }
}

{
  "alg": "ES256",
  "x5c": [
    "base64encodedvalue==",
    "base64encodedvalue=="
  ],
  "crit": ["created-on"],
  "created-on": "2022-09-13T00:00:02.000Z"
}

7.3. Supply PVR to Registrar (including MASA interaction)

Once the Registrar-Agent has acquired one or more PVR and PER object pairs, it starts the interaction with the domain registrar. Collecting multiple pairs allows bulk bootstrapping of several pledges using the same session with the registrar.¶

The Registrar-Agent MUST establish a TLS session to the registrar with mutual authentication. In contrast to BRSKI [RFC8995], the TLS client authentication uses the Registrar-Agent EE certificate instead of the pledge IDevID certificate. Consequently, the domain registrar can distinguish BRSKI (pledge-initiator-mode) from BRSKI-PRM (pledge-responder-mode).¶

The registrar SHOULD verify the TLS client authentication of the Registrar-Agent, in particular if the TLS session is used to obtain the Registrar-Agent EE certificate (see Section 6.3). Note that authentication and authorization is of the pledge verified during the TLS session based on the signatures inside the PVR artifact.¶

As already stated in [RFC8995], the use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is REQUIRED on the Registrar-Agent side. TLS 1.3 (or newer) SHOULD be available on the registrar, but TLS 1.2 MAY be used. TLS 1.3 (or newer) SHOULD be available on the MASA, but TLS 1.2 MAY be used.¶

Figure 19 shows the voucher-request processing and the following subsections describe the corresponding artifacts.¶

As a first step of the interaction with the domain registrar, the Registrar-Agent SHALL supply the PVR artifact(s) to the registrar via HTTP-over-TLS POST to the registrar endpoint at /.well-known/brski/requestvoucher. Note that this is the same endpoint as for BRSKI described in Section 5.2 of [RFC8995]. The request body MUST contain one previously acquired PVR artifact as defined in Section 7.1.2. In the request header, the Content-Type field MUST be set to application/voucher-jws+json and the Accept field SHOULD be set to application/voucher-jws+json as defined in [I-D.ietf-anima-jws-voucher].¶

Upon receiving a PVR artifact, the registrar accepts or declines the request to join the domain. For this, it MUST perform pledge authorization as defined in Section 5.3 of [RFC8995]. Due to the Registrar-Agent in the middle, the registrar MUST verify in addition that¶

• the agent-provided-proximity-registrar-cert field of the PVR contains a registrar EE certificate signed by the same domain owner as the registrar EE certificate used to sign the RVR; note that this check allows for installations with multiple domain registrars and for registrar EE certificate renewal between exchanges with the Registrar-Agent (see Section 5.2); in many installations with a single registrar the contained certificate is identical to the signing certificate¶

• the agent-signed-data field of the PVR is signed with the private key corresponding to the Registrar-Agent EE certificate as known by the registrar (see Section 6.3); this is done via the SubjectKeyIdentifier of the certificate in the kid Header Parameter of the JWS Protected Header of the agent-signed-data field.¶

• the product-serial-number inside the agent-signed-data is equal to the serial-number field of the PVR as well as the X520SerialNumber field of the pledge IDevID certificate, which is contained in the JWS Protected Header of the PVR.¶

• the Registrar-Agent EE certificate is still valid; this is necessary to avoid that a rogue Registrar-Agent generates agent-signed-data objects to onboard arbitrary pledges at a later point in time, see also Section 11.3.¶

If the registrar is unable to process the request or validate the PVR, it MUST respond with an HTTP client error status code to the Registrar-Agent. The following client error status codes SHOULD be used:¶

• 400 Bad Request: if the registrar detects an error in the format of the request¶

• 403 Forbidden: if the registrar detected that one or more security related fields are not valid or if the pledge-provided information could not be used with automated allowance¶

• 406 Not Acceptable: if the Accept request header field indicates a type that is unknown or unsupported¶

• 415 Unsupported Media Type: if the Content-Type request header field indicates a type that is unknown or unsupported¶

Otherwise, the registrar converts the PVR artifact to an Registrar Voucher-Request (RVR) artifact (see Section 7.3.4) and starts the backend interaction with the MASA.¶

Optionally, the domain registrar MAY respond with an HTTP 202 Accepted response status code to the Registrar-Agent at this point following Section 5.6 of [RFC8995], while the rules defined for the pledge also apply to the Registrar-Agent; in this case, the registrar still continues with the MASA interaction to provide the Voucher artifact to the retry request.¶

The registrar MAY use the response body to signal success/failure details to the service technician operating the Registrar-Agent.¶

{
  "payload": BASE64URL(UTF8(JSON RVR Data)),
  "signatures": [
    {
      "protected": BASE64URL(UTF8(JWS Protected Header)),
      "signature": BASE64URL(JWS Signature)
    }
  ]
}

{
  "ietf-voucher-request:voucher": {
     "created-on": "2022-01-04T02:37:39.235Z",
     "nonce": "eDs++/FuDHGUnRxN3E14CQ==",
     "serial-number": "vendor-pledge4711",
     "idevid-issuer": "base64encodedvalue==",
     "prior-signed-voucher-request": "base64encodedvalue==",
     "assertion": "agent-proximity",
     "agent-sign-cert": [
       "base64encodedvalue==",
       "base64encodedvalue==",
       "..."
     ]
  }
}

{
  "ietf-voucher:voucher": {
    "created-on": "2022-01-04T00:00:02.000Z",
    "nonce": "base64encodedvalue==",
    "assertion": "agent-proximity",
    "pinned-domain-cert": "base64encodedvalue==",
    "serial-number": "vendor-pledge4711"
  }
}

{
  "payload": BASE64URL(JSON Voucher Data),
  "signatures": [
    {
      "protected": BASE64URL(UTF8(JWS Protected Header (MASA))),
      "signature": BASE64URL(JWS Signature (MASA))
    },
    {
      "protected": BASE64URL(UTF8(JWS Protected Header (Registrar))),
      "signature": BASE64URL(JWS Signature (Registrar))
    }
  ]
}

7.4. Supply PER to Registrar (including Key Infrastructure interaction)

After receiving the Voucher artifact, the Registrar-Agent sends the PER to the domain registrar within the same TLS session.¶

In case the TLS session to the registrar is already closed, the Registrar-Agent establishes a new session as described in Section 7.3. The registrar is able to correlate the PVR and PER artifacts based on the signatures and the contained product-serial-number. Note that this also addresses situations in which a nonceless voucher is used and may be pre-provisioned to the pledge.¶

Figure 24 depicts exchanges for the PER request handling and the following subsections describe the corresponding artifacts. Note that "Request" and "Certificate" do not denote BRSKI-PRM defined artifacts, but are data objects depending on the certificate management protocol used by the domain Key Infrastructure.¶

As a second step of the interaction with the domain registrar, the Registrar-Agent SHALL supply the PER artifact(s) to the registrar via HTTP-over-TLS POST to the registrar endpoint at /.well-known/brski/requestenroll. The request body MUST contain one previously acquired PER artifact as defined in Section 7.2.2. In the request header, the Content-Type field MUST be set to application/jose+json and the Accept field SHOULD be set to application/jose+json.¶

Note that this is different from the EST [RFC7030] endpoint used in BRSKI, as the PER artifact is signature-wrapped. Hence, upon receiving a PER artifact, the registrar MUST verify that¶

• the PER was signed signed with the private key corresponding to the pledge EE certificate, which is contained in the JWS Protected Header of the PER.¶

• the pledge identified by its EE certificate is accepted to join the domain after successful validation of the corresponding PVR.¶

If the registrar is unable to process the request or validate the PER, it MUST respond with an HTTP client error status code to the Registrar-Agent. The following client error status codes SHOULD be used:¶

• 400 Bad Request: if the registrar detects an error in the format of the request¶

• 401 Unauthorized: if the signature of the PER cannot be verified¶

• 404 Not Found: if the PER is for a device that is not known to the registrar¶

• 406 Not Acceptable: if the Accept request header field indicates a type that is unknown or unsupported, e.g., a type other than application/jose+json¶

• 415 Unsupported Media Type: if the PER uses an artifact format that is not supported by the registrar, e.g., a type other than application/jose+json¶

Otherwise, the registrar extracts the PKCS#10 Certificate Signing Request (CSR) inside the PER (see Section 7.2.2) and uses the CSR to request a new pledge EE certificate from the domain Key Infrastructure. The exact interaction and exchanged data objects depends on the certificate management protocol used by the Key Infrastructure, and is out of scope for this document.¶

A successful interaction with the Key Infrastructure will result in a pledge EE certificate singed by the domain owner (e.g., LDevID certificate). The registrar MUST reply to the Registrar-Agent with the Enroll-Response (Enroll-Resp) as defined in Section 7.4.2 in the body of an HTTP 200 OK response. In the response header, the Content-Type field MUST be set to application/pkcs7-mime.¶

If the domain registrar is unable to return the Enroll-Resp, it MUST respond with an HTTP server error status code to the Registrar-Agent. The following server error status codes SHOULD be used:¶

• 500 Internal Server Error: if the Key Infrastructure response is valid, but the registrar still failed to return the Enroll-Resp, e.g., due to missing configuration or a program failure¶

• 502 Bad Gateway: if the registrar received an invalid response from the Key Infrastructure¶

• 503 Service Unavailable: if a simple retry of the Registrar-Agent request might lead to a successful response; this error response SHOULD include the Retry-After response header field with an appropriate value¶

• 504 Gateway Timeout: if the backend request to the Key Infrastructure timed out¶

Note that while BRSKI-PRM targets the initial enrollment, re-enrollment may be supported in a similar way with the exception that the current, potentially application-related pledge EE certificate is used instead of the IDevID certificate to sign the PER artifact (see also Section 7.2). Hence, there is no verification whether the pledge is accepted to join the domain, as the still valid EE certificate signed by the domain owner identifies the pledge as already accepted component of the domain.¶

7.5. Obtain CA Certificates

The pinned domain certificate in the voucher is only the initial trust anchor for only the domain registrar. To fully trust the domain and also to verify its own EE certificate, the pledge also needs the corresponding domain CA certificate(s). A bag of CA certificates signed by the registrar will allow the pledge to verify the authorization to install the received CA certificate(s) through the pinned domain certificate in the voucher.¶

Note that this is a deviation from EST [RFC7030] used in BRSKI [RFC8995].¶

The Registrar-Agent obtains this artifact within the same TLS session. In case the TLS session to the registrar is already closed, the Registrar-Agent establishes a new session as described in Section 7.3. The CA certificates do not need to be correlated to a specific voucher or Enroll-Response; they only need to be fresh.¶

Figure 25 shows the acquisition of the CA certificate(s) and the following subsections describe the corresponding artifact.¶

As a third step of the interaction with the domain registrar, the Registrar-Agent SHALL obtain the CA-Certificates artifact from the registrar via HTTP-over-TLS GET to the registrar endpoint at /.well-known/brski/wrappedcacerts. In the request header, the Accept field SHOULD be set to application/jose+json.¶

Upon receiving a GET request at /.well-known/brski/wrappedcacerts, the domain registrar MUST reply with the CA-Certificates artifact as defined in Section 7.5.2 in the body of an HTTP 200 OK response. In the response header, the Content-Type field MUST be set to application/jose+json.¶

{
  "payload": BASE64URL(UTF8(JSON CA Data)),
  "signatures": [
    {
      "protected": BASE64URL(UTF8(JWS Protected Header)),
      "signature": BASE64URL(JWS Signature)
    }
  ]
}

cacerts = {
        "x5bag": bytes / [+ bytes]
}

{
  "x5bag": [
    "base64encodedvalue==",
    "base64encodedvalue=="
  ]
}

{
  "alg": "ES256",
  "x5c": [
    "base64encodedvalue==",
    "base64encodedvalue=="
  ]
}

7.6. Supply Voucher to Pledge

Once the Registrar-Agent has acquired the following three bootstrapping artifacts, it can supply them to the pledge starting with the Voucher':¶

• Voucher': voucher countersigned by the registrar (from MASA via Registrar)¶

• Enroll-Resp: pledge EE certificate signed by the domain owner (from Key Infrastructure via registrar)¶

• caCerts: domain trust anchors (from Key Infrastructure via Registrar)¶

Reconnecting to the pledge might require to re-discover the pledge as described in Section 6.1.2. The Registrar-Agent MAY stored information from the first connection with the pledge to optimize.¶

Optionally, TLS MAY be used to provide privacy for this exchange between the Registrar-Agent and the pledge (see Appendix B).¶

Figure 30 shows the provisioning of the voucher to the pledge and the following subsections describe the corresponding artifacts.¶

The Registrar-Agent SHALL supply the voucher to the pledge via HTTP(S) POST to the pledge endpoint at /.well-known/brski/svr. The request body MUST contain the Registrar-Countersigned Voucher (Voucher') artifact previously acquired from the domain registrar as defined in Section 7.3.6. In the request header, the Content-Type field MUST be set to application/voucher-jws+json as defined in [I-D.ietf-anima-jws-voucher] and the Accept field SHOULD be set to application/jose+json.¶

Upon receiving the voucher, the pledge SHALL perform the signature verification in the following order:¶

1. Verify the MASA signature as described in Section 5.6.1 of [RFC8995] against the pre-installed manufacturer trust anchor (e.g., IDevID).¶

2. Provisionally install the initial domain trust anchor contained in the pinned-domain-cert field of the voucher.¶

3. Validate the registrar EE certificate received in the agent-provided-proximity-registrar-cert field of the previously received tPVR artifact using the pinned domain certificate; this terminates the "provisional state" for the object security within the authenticated self-contained objects that in BRSKI-PRM replace the direct TLS connection to the registrar in BRSKI [RFC8995] (see Section 5.4).¶

4. Verify registrar signature of the Voucher' artifact similar as described in Section 5.6.1 of [RFC8995], but use the pinned domain certificate instead of the MASA certificate for the verification.¶

If all steps above complete successfully, the pledge SHALL terminate the "provisional state" for the initial domain trust anchor (i.e., the pinned domain certificate).¶

A nonceless voucher MAY be accepted as in [RFC8995] if allowed by the pledge implementation of the manufacturer.¶

After voucher validation and verification, the pledge needs to reply with a status telemetry message as defined in Section 5.7 of [RFC8995]. The pledge MUST generate the Voucher Status (vStatus) artifact as defined in Section 7.6.2 and MUST provide it to the Registrar-Agent in the body of an HTTP 200 OK response. In the response header, the Content-Type field MUST be set to application/jose+json.¶

If the pledge is unable to validate or verify the voucher, it MUST report the reason in the corresponding field of the Voucher Status.¶

If the pledge did not did not provide voucher status telemetry information after processing the voucher, the Registrar-Agent MAY query the pledge status explicitly as described in Section 7.11. It MAY resend the voucher depending on the Pledge status following the same procedure.¶

{
  "payload": BASE64URL(UTF8(JSON Voucher Status Data)),
  "signatures": [
    {
      "protected": BASE64URL(UTF8(JWS Protected Header)),
      "signature": BASE64URL(JWS Signature)
    }
  ]
}

{
  "version": 1,
  "status": true,
  "reason": "Voucher successfully processed.",
  "reason-context": {
    "pvs-details": "Current date 5/23/2024"
  }
}

{
  "version": 1,
  "status": false,
  "reason": "Failed to authenticate MASA certificate.",
  "reason-context": {
    "pvs-details": "Current date 1/1/1970 < valid from 1/1/2023"
  }
}

{
  "alg": "ES256",
  "x5c": [
    "base64encodedvalue==",
    "base64encodedvalue=="
  ]
}

7.7. Supply CA Certificates to Pledge

Before supplying the pledge EE certificate, the Registrar-Agent supplies the domain CA certificates to the pledge, so the pledge can verify its EE certficate in the next exchange. As the CA certificate provisioning is crucial from a security perspective, this exchange SHOULD only be done, if supplying the voucher in the previous exchange (Section 7.6) has been successfully processed by pledge as reflected in the vStatus artifact.¶

Optionally, TLS MAY be used to provide privacy for this exchange between the Registrar-Agent and the pledge (see Appendix B).¶

Figure 35 shows the provisioning of the CA certificates to the pledge and the following subsections describe the corresponding artifacts.¶

The Registrar-Agent SHALL provide the bag of CA certificates requested from and signed by the registrar to the pledge by HTTP(S) POST to the pledge endpoint at /.well-known/brski/scac. The request body MUST contain the caCerts artifact as defined in Section 7.5.2. In the request header, the Content-Type field MUST be set to application/jose+json.¶

Upon receiving valid caCerts artifact, the pledge MUST first verify the signature of the registrar using the initial trust anchor (pinned domain certificate). In the case of success, the pledge MUST install the contained CA certificates as trust anchors as described in Section 4.1.3 of [RFC7030]. This includes the verification of all intermediate CA certificates (i.e., not self-signed CA certificates).¶

If the pledge is unable to process the caCerts, it SHOULD respond with an HTTP error status code to the Registrar-Agent. The following client error status codes SHOULD be used:¶

• 400 Bad Request: if the pledge detects an error in the format of the request¶

• 401 Unauthorized: if the signature of the registrar cannot be verified against the installed initial trust anchor (pinned domain certificate)¶

• 403 Forbidden: if one of the intermediate CA certificates cannot be verified against the available trust anchors (e.g., self-signed CA certificates)¶

• 415 Unsupported Media Type: if the Content-Type request header field indicates a type that is unknown or unsupported, e.g., a type other than application/jose+json¶

Otherwise, if processing completes successfully, the pledge SHOULD reply with HTTP 200 OK without a response body. The pledge MAY use the response body to signal success/failure details to the service technician operating the Registrar-Agent.¶

7.8. Supply Enroll-Response to Pledge

After supplying the CA certificates, the Registrar-Agent supplies the pledge EE certificate to the pledge.¶

Optionally, TLS MAY be used to provide privacy for this exchange between the Registrar-Agent and the pledge (see Appendix B).¶

Figure 36 shows the provisioning of the domain-owner signed EE certificate to the pledge and the following subsections describe the corresponding artifacts.¶

The Registrar-Agent SHALL send the domain-owner signed EE certificate to the pledge by HTTP(S) POST to the pledge endpoint at /.well-known/brski/ser. The request body MUST contain the Enroll-Response (Enroll-Resp) artifact previously acquired from the domain registrar as defined in Section 7.4.2. In the request header, the Content-Type field MUST be set to application/pkcs7-mime and the Accept field SHOULD be set to application/jose+json.¶

Upon reception, the pledge SHALL verify the received EE certificate using the installed trust anchors. After Enroll-Resp validation and verification, the pledge needs to reply with a status telemetry message as defined in Section 5.9.4 of [RFC8995]. The pledge MUST generate the Enroll Status (eStatus) artifact as defined in Section 7.8.2 and MUST provide it to the Registrar-Agent in the body of an HTTP 200 OK response. In the response header, the Content-Type field MUST be set to application/jose+json.¶

If the pledge is unable to validate or verify the Enroll-Response, it MUST report the reason in the corresponding field of the Enroll Status.¶

{
  "payload": BASE64URL(UTF8(JSON Enroll Status Data)),
  "signatures": [
    {
      "protected": BASE64URL(UTF8(JWS Protected Header)),
      "signature": BASE64URL(JWS Signature)
    }
  ]
}

{
  "version": 1,
  "status": true,
  "reason": "Enroll-Response successfully processed.",
  "reason-context": {
    "pes-details": "Success"
  }
}

{
  "version": 1,
  "status": false,
  "reason": "Enroll-Response could not be verified.",
  "reason-context": {
    "pes-details": "No matching trust anchor"
  }
}

{
  "alg": "ES256",
  "x5c": [
    "base64encodedvalue==",
    "base64encodedvalue=="
  ]
}

7.9. Voucher Status Telemetry (including MASA interaction)

Once the Registrar-Agent has collected both status artifacts from one or more pledges, it SHALL provide the status information to the domain registrar for further processing, beginning with the voucher status telemetry.¶

In case the TLS session to the registrar is closed, the Registrar-Agent establishes a new session as described in Section 7.3.¶

Figure 41 shows the provisioning of the voucher status information from the pledge(s) to the registrar and the following subsections describe the corresponding artifact and MASA interaction.¶

First, the Registrar-Agent SHALL supply the voucher status telemetry to the registrar via HTTP-over-TLS POST to the registrar endpoint at /.well-known/brski/voucher_status. The request body MUST contain one previously acquired vStatus artifact as defined in Section 7.6.2. In the request header, the Content-Type field MUST be set to application/jose+json.¶

Upon receiving a vStatus artifact, the registrar MUST process it as described in Section 5.7 of [RFC8995]. Due to the Registrar-Agent in the middle, the registrar MUST in addition verify the signature of the vStatus and that it belongs to an accepted device of the domain based on the serial-number field of the IDevID certificate contained in the JWS Protected Header of the vStatus.¶

According to Section 5.7 of [RFC8995], the registrar SHOULD respond with an HTTP 200 OK without a response body in the success case or fail with an HTTP error status code. The registrar MAY use the response body to signal success/failure details to the service technician operating the Registrar-Agent.¶

The registrar SHOULD proceed with the audit-log request to the MASA as in BRSKI described in Section 5.8 of [RFC8995].¶

7.10. Enroll Status Telemetry

The Registrar-Agent SHALL complete the sequence of exchanges for bootstrapping with providing the enroll status telemetry to the domain registrar. This status indicates whether the pledge could process the Enroll-Response (pledge EE certificate signed by the domain owner) and holds the corresponding private key.¶

In case the TLS session to the registrar is already closed, the Registrar-Agent establishes a new session as described in Section 7.3.¶

Figure 42 shows the provisioning of the enroll status information from the pledge(s) to the registrar and the following subsections describe the corresponding artifact.¶

Second, the Registrar-Agent SHALL supply the enroll status telemetry to the registrar via HTTP-over-TLS POST to the registrar endpoint at /.well-known/brski/enrollstatus. The request body MUST contain one previously acquired eStatus artifact as defined in Section 7.8.2. In the request header, the Content-Type field MUST be set to application/jose+json.¶

Upon receiving an eStatus artifact, the registrar MUST process it as described in Section 5.9.4 of [RFC8995]. Due to the Registrar-Agent in the middle, instead of the BRSKI TLS session with the pledge, the registrar MUST verify the signature of the eStatus artifact and that it belongs to an accepted device of the domain based on the serial-number field of the EE certificate contained in the JWS Protected Header of the eStatus. Note that if the Enroll Status indicates success, the eStatus artifact is signed with the new pledge EE credentials; if it indicates failure, the pledge was unable to process the supplied EE certificate and therefore signed with its IDevID credentials.¶

According to Section 5.9.4 of [RFC8995], the registrar SHOULD respond with an HTTP 200 OK in the success case or MAY fail with an HTTP 404 client error status code. The registrar MAY use the response body to signal success/failure details to the service technician operating the Registrar-Agent.¶

If the eStatus indicates failure, the registrar MAY decide that for security reasons the pledge is not allowed to reside in the domain. In this case, the registrar MUST revoke the pledge EE certificate. An example case for the registrar revoking the issued certificate is when the pledge was not able to verify the received EE certificate and therefore did not accept it for installation.¶

7.11. Query Pledge Status

The following assumes that a Registrar-Agent MAY need to query the overall status of a pledge. This information can be useful to solve errors, when the pledge was not able to connect to the target domain during bootstrapping. A pledge MAY omit the dedicated endpoint for the Query Pledge Status operation (see Section 6.2).¶

Optionally, TLS MAY be used to provide privacy for this exchange between the Registrar-Agent and the pledge (see Appendix B).¶

Figure 43 shows the query and response for the overall pledge status and the following subsections describe the corresponding artifacts.¶

The Registrar-Agent SHALL query the pledge via HTTP(S) POST to the pledge endpoint at /.well-known/brski/qps. The request body MUST contain the Status Trigger (tStatus) artifact as defined in Section 7.11.1. In the request header, the Content-Type field MUST be set to application/jose+json and the Accept field SHOULD be set to application/jose+json.¶

If the pledge implements the Query Pledge Status endpoint, it MUST first verify the signature of the tStatus artifact using its trust anchors. If the pledge does not possess any domain trust anchor yet, it MAY skip the signature verification and choose to reply without it. In the case of success, it MUST reply with the Pledge Status (pStatus) artifact as defined in Section 7.11.2 in the body of an HTTP 200 OK response. In the response header, the Content-Type field MUST be set to application/jose+json.¶

If the pledge is unable to create the pStatus artifact, the pledge SHOULD respond with an HTTP error status code to the Registrar-Agent. The following client error status codes SHOULD be used:¶

• 400 Bad Request: if the pledge detects an error in the format of the request¶

• 401 Unauthorized: if the signature of the Registrar-Agent cannot be verified using the installed trust anchors¶

• 406 Not Acceptable: if the Accept request header field indicates a type that is unknown or unsupported, e.g., a type other than application/jose+json¶

• 415 Unsupported Media Type: if the Content-Type request header field indicates a type that is unknown or unsupported, e.g., a type other than application/jose+json¶

The pledge MAY use the response body to signal failure details to the service technician operating the Registrar-Agent.¶

{
  "payload": BASE64URL(UTF8(JSON Status Trigger Data)),
  "signatures": [
    {
      "protected": BASE64URL(UTF8(JWS Protected Header)),
      "signature": BASE64URL(JWS Signature)
    }
  ]
}

  statustrigger = {
      "version": uint,
      "serial-number": text,
      "created-on": tdate,
      "status-type": $status-type
  }

  $status-type /= "bootstrap"
  $status-type /= "operation"

{
  "version": 1,
  "created-on": "2022-08-12T02:37:39.235Z",
  "serial-number": "vendor-pledge4711",
  "status-type": "bootstrap"
}

{
  "alg": "ES256",
  "x5c": [
    "base64encodedvalue==",
    "base64encodedvalue=="
  ]
}

{
  "payload": BASE64URL(UTF8(JSON Pledge Status Data)),
  "signatures": [
    {
      "protected": BASE64URL(UTF8(JWS Protected Header)),
      "signature": BASE64URL(JWS Signature)
    }
  ]
}

  pledgestatus = {
    "version": uint,
    "status": bool,
    ?"reason" : text,
    "reason-context": { * $$arbitrary-map }
  }

{
  "version": 1,
  "status": true,
  "reason": "Pledge processed enrollment exchange successfully.",
  "reason-context": {
    "pbs-details": "Pledge processed enrollment exchange successfully."
  }
}

{
  "version": 1,
  "status": "connect-error",
  "reason": "TLS certificate could not be verified.",
  "reason-context": {
    "connect-error" : "Connection establishment terminated with error."
  }
}

{
  "alg": "ES256",
  "x5c": [
    "base64encodedvalue==",
    "base64encodedvalue=="
  ]
}

9.1. BRSKI .well-known Registry

IANA is requested to enhance the Registry entitled: "BRSKI Well-Known URIs" with the following endpoints:¶

9.2. DNS Service Names

IANA has registered the following service names:¶

Service Name: brski-pledge
Transport Protocol(s): tcp
Assignee: IESG [email protected]
Contact: IESG [email protected]
Description: The Bootstrapping Remote Secure Key Infrastructure Pledge
Reference: [THISRFC]¶

11.1. Denial of Service (DoS) Attack on Pledge

Disrupting the pledge behavior by a DoS attack may prevent the bootstrapping of the pledge to a new domain. Because in BRSKI-PRM, the pledge responds to requests from real or illicit Registrar-Agents, pledges are more subject to DoS attacks from Registrar-Agents in BRSKI-PRM than they are from illicit registrars in [RFC8995], where pledges do initiate the connections.¶

A DoS attack with a faked Registrar-Agent may block the bootstrapping of the pledge due changing state on the pledge (the pledge may produce a voucher-request, and refuse to produce another one). One mitigation may be that the pledge does not limited the number of voucher-requests it creates until at least one has finished. An alternative may be that the onboarding state may expire after a certain time, if no further interaction has happened.¶

In addition, the pledge may assume that repeated triggering for PVR are the result of a communication error with the Registrar-Agent. In that case the pledge MAY simply resent the PVR previously sent. Note that in case of re-sending, a contained nonce and also the contained agent-signed-data in the PVR would consequently be reused.¶

11.2. Misuse of acquired PVR and PER by Registrar-Agent

A Registrar-Agent that uses previously requested PVR and PER for domain-A, may attempt to onboard the device into domain-B. This can be detected by the domain registrar while PVR processing. The domain registrar needs to verify that the proximity-registrar-cert field in the PVR matches its own registrar EE certificate. In addition, the domain registrar needs to verify the association of the pledge to its domain based on the product-serial-number contained in the PVR and in the pledge IDevID certificate. (This is just part of the supply chain integration). Moreover, the domain registrar verifies if the Registrar-Agent is authorized to interact with the pledge for voucher-requests and enroll-requests, based on the Registrar-Agent EE certificate data contained in the PVR.¶

Mis-binding of a pledge by a faked domain registrar is countered as described in BRSKI security considerations Section 11.4 of [RFC8995].¶

11.3. Misuse of Registrar-Agent Credentials

Concerns of misuse of a Registrar-Agent with a valid Registrar-Agent EE certificate may be addressed by utilizing short-lived certificates (e.g., valid for a day) to authenticate the Registrar-Agent against the domain registrar. The Registrar-Agent EE certificate may have been acquired by a prior BRSKI run for the Registrar-Agent, if an IDevID is available on Registrar-Agent. Alternatively, the Registrar-Agent EE certificate may be acquired by a service technician from the domain PKI system in an authenticated way.¶

In addition it is required that the Registrar-Agent EE certificate is valid for the complete bootstrapping phase. This avoids that a Registrar-Agent could be misused to create arbitrary "agent-signed-data" objects to perform an authorized bootstrapping of a rogue pledge at a later point in time. In this misuse "agent-signed-data" could be dated after the validity time of the Registrar-Agent EE certificate, due to missing trusted timestamp in the Registrar-Agents signature. To address this, the registrar SHOULD verify the certificate used to create the signature on "agent-signed-data". Furthermore the registrar also verifies the Registrar-Agent EE certificate used in the TLS handshake with the Registrar-Agent. If both certificates are verified successfully, the Registrar-Agent's signature can be considered as valid.¶

11.4. Misuse of DNS-SD with mDNS to obtain list of pledges

To discover a specific pledge a Registrar-Agent may query the Service Type in combination with the product-serial-number of a specific pledge, e.g., in the Service Instance Name or Service Subtype. The pledge reacts on this if its product-serial-number is part of the query message.¶

If the Registrar-Agent performs DNS-based Service Discovery without a specific product-serial-number, all pledges in the domain react if the functionality is supported. This functionality enumerates and reveals the information of devices available in the domain. The information about this is provided here as a feature to support the commissioning of devices. A manufacturer may decide to support this feature only for devices not possessing an LDevID or to not support this feature at all, to avoid an enumeration in an operative domain.¶

11.5. YANG Module Security Considerations

The enhanced voucher-request described in [I-D.ietf-anima-rfc8366bis] is based on [RFC8995], but uses a different encoding based on [I-D.ietf-anima-jws-voucher]. The security considerations as described in Section 11.7 of [RFC8995] (Security Considerations) apply.¶

The YANG module specified in [I-D.ietf-anima-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 guidelines do not follow the template described by Section 3.7 of [RFC8407] (Security Considerations).¶

13.1. Normative References

[I-D.ietf-anima-jws-voucher]

Werner, T. and M. Richardson, "JWS signed Voucher Artifacts for Bootstrapping Protocols", Work in Progress, Internet-Draft, draft-ietf-anima-jws-voucher-10, 18 June 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-anima-jws-voucher-10>.

[I-D.ietf-anima-rfc8366bis]

Watsen, K., Richardson, M., Pritikin, M., Eckert, T. T., and Q. Ma, "A Voucher Artifact for Bootstrapping Protocols", Work in Progress, Internet-Draft, draft-ietf-anima-rfc8366bis-12, 8 July 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-anima-rfc8366bis-12>.

[I-D.ietf-netconf-sztp-csr]

Watsen, K., Housley, R., and S. Turner, "Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request", Work in Progress, Internet-Draft, draft-ietf-netconf-sztp-csr-14, 2 March 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr-14>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC3339]

Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/rfc/rfc3339>.

[RFC5272]

Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, <https://www.rfc-editor.org/rfc/rfc5272>.

[RFC5280]

Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/rfc/rfc5280>.

[RFC6762]

Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <https://www.rfc-editor.org/rfc/rfc6762>.

[RFC6763]

Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <https://www.rfc-editor.org/rfc/rfc6763>.

[RFC7030]

Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, October 2013, <https://www.rfc-editor.org/rfc/rfc7030>.

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/rfc/rfc7515>.

[RFC7951]

Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, August 2016, <https://www.rfc-editor.org/rfc/rfc7951>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8259]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/rfc/rfc8259>.

[RFC8610]

Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.

[RFC8615]

Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, <https://www.rfc-editor.org/rfc/rfc8615>.

[RFC8995]

Pritikin, M., Richardson, M., Eckert, T., Behringer, M., and K. Watsen, "Bootstrapping Remote Secure Key Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, May 2021, <https://www.rfc-editor.org/rfc/rfc8995>.

[RFC9360]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing X.509 Certificates", RFC 9360, DOI 10.17487/RFC9360, February 2023, <https://www.rfc-editor.org/rfc/rfc9360>.

13.2. Informative References

[androidnsd]

"Android Developer: Connect devices wirelessly", archived at https://web.archive.org/web/20230000000000*/https://developer.android.com/training/connect-devices-wirelessly, n.d., <https://developer.android.com/training/connect-devices-wirelessly>.

[androidtrustfail]

"Security with Network Protocols", archived at https://web.archive.org/web/20230326153937/https://developer.android.com/training/articles/security-ssl, n.d., <https://developer.android.com/training/articles/security-ssl>.

[BRSKI-PRM-abstract]

"Abstract BRSKI-PRM Protocol Overview", March 2022, <https://datatracker.ietf.org/meeting/113/materials/slides-113-anima-update-on-brski-with-pledge-in-responder-mode-brski-prm-00>.

[I-D.ietf-anima-brski-ae]

von Oheimb, D., Fries, S., and H. Brockhaus, "BRSKI-AE: Alternative Enrollment Protocols in BRSKI", Work in Progress, Internet-Draft, draft-ietf-anima-brski-ae-12, 5 July 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-ae-12>.

[I-D.ietf-anima-brski-discovery]

Eckert, T. T. and E. Dijk, "Discovery for BRSKI variations", Work in Progress, Internet-Draft, draft-ietf-anima-brski-discovery-04, 25 July 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-anima-brski-discovery-04>.

[I-D.irtf-t2trg-taxonomy-manufacturer-anchors]

Richardson, M., "A Taxonomy of operational security considerations for manufacturer installed keys and Trust Anchors", Work in Progress, Internet-Draft, draft-irtf-t2trg-taxonomy-manufacturer-anchors-03, 30 January 2024, <https://datatracker.ietf.org/doc/html/draft-irtf-t2trg-taxonomy-manufacturer-anchors-03>.

[I-D.richardson-anima-registrar-considerations]

Richardson, M. and W. Pan, "Operational Considerations for BRSKI Registrar", Work in Progress, Internet-Draft, draft-richardson-anima-registrar-considerations-08, 14 February 2024, <https://datatracker.ietf.org/doc/html/draft-richardson-anima-registrar-considerations-08>.

[I-D.richardson-emu-eap-onboarding]

DeKok, A. and M. Richardson, "EAP defaults for devices that need to onboard", Work in Progress, Internet-Draft, draft-richardson-emu-eap-onboarding-03, 2 April 2023, <https://datatracker.ietf.org/doc/html/draft-richardson-emu-eap-onboarding-03>.

[IEEE-802.1AR]

Institute of Electrical and Electronics Engineers, "IEEE 802.1AR Secure Device Identifier", IEEE 802.1AR, June 2018.

[onpath]

"can an on-path attacker drop traffic?", n.d., <https://mailarchive.ietf.org/arch/msg/saag/m1r9uo4xYznOcf85Eyk0Rhut598/>.

[RFC2986]

Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, DOI 10.17487/RFC2986, November 2000, <https://www.rfc-editor.org/rfc/rfc2986>.

[RFC3629]

Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/rfc/rfc3629>.

[RFC4648]

Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/rfc/rfc4648>.

[RFC6241]

Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/rfc/rfc6241>.

[RFC7252]

Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/rfc/rfc7252>.

[RFC8040]

Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/rfc/rfc8040>.

[RFC8407]

Bierman, A., "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", BCP 216, RFC 8407, DOI 10.17487/RFC8407, October 2018, <https://www.rfc-editor.org/rfc/rfc8407>.

[RFC8792]

Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, "Handling Long Lines in Content of Internet-Drafts and RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, <https://www.rfc-editor.org/rfc/rfc8792>.

[RFC8971]

Pallagatti, S., Ed., Mirsky, G., Ed., Paragiri, S., Govindan, V., and M. Mudigonda, "Bidirectional Forwarding Detection (BFD) for Virtual eXtensible Local Area Network (VXLAN)", RFC 8971, DOI 10.17487/RFC8971, December 2020, <https://www.rfc-editor.org/rfc/rfc8971>.

[RFC8990]

Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic Autonomic Signaling Protocol (GRASP)", RFC 8990, DOI 10.17487/RFC8990, May 2021, <https://www.rfc-editor.org/rfc/rfc8990>.

[RFC9052]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, <https://www.rfc-editor.org/rfc/rfc9052>.

[RFC9110]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.

[RFC9238]

Richardson, M., Latour, J., and H. Habibi Gharakheili, "Loading Manufacturer Usage Description (MUD) URLs from QR Codes", RFC 9238, DOI 10.17487/RFC9238, May 2022, <https://www.rfc-editor.org/rfc/rfc9238>.

[RFC9483]

Brockhaus, H., von Oheimb, D., and S. Fries, "Lightweight Certificate Management Protocol (CMP) Profile", RFC 9483, DOI 10.17487/RFC9483, November 2023, <https://www.rfc-editor.org/rfc/rfc9483>.

[RFC9525]

Saint-Andre, P. and R. Salz, "Service Identity in TLS", RFC 9525, DOI 10.17487/RFC9525, November 2023, <https://www.rfc-editor.org/rfc/rfc9525>.

A.1. Example Pledge Voucher-Request (PVR) - from Pledge to Registrar-Agent

The following is an example request sent from a Pledge to the Registrar-Agent, in "General JWS JSON Serialization". The message size of this PVR is: 2973 bytes¶

=============== NOTE: '\' line wrapping per RFC 8792 ================

{
  "payload": "eyJpZXRmLXZvdWNoZXItcmVxdWVzdC1wcm06dm91Y2hlciI6eyJhc3\
NlcnRpb24iOiJhZ2VudC1wcm94aW1pdHkiLCJzZXJpYWwtbnVtYmVyIjoiMDEyMzQ1Nj\
c4OSIsIm5vbmNlIjoia2hOeUtwTXRoY2NpYTFyWHc0NC92UT09IiwiY3JlYXRlZC1vbi\
I6IjIwMjQtMDYtMjRUMDk6MDE6MjQuNTU2WiIsImFnZW50LXByb3ZpZGVkLXByb3hpbW\
l0eS1yZWdpc3RyYXItY2VydCI6Ik1JSUI0akNDQVlpZ0F3SUJBZ0lHQVhZNzJiYlpNQW\
9HQ0NxR1NNNDlCQU1DTURVeEV6QVJCZ05WQkFvTUNrMTVRblZ6YVc1bGMzTXhEVEFMQm\
dOVkJBY01CRk5wZEdVeER6QU5CZ05WQkFNTUJsUmxjM1JEUVRBZUZ3MHlNREV5TURjd0\
5qRTRNVEphRncwek1ERXlNRGN3TmpFNE1USmFNRDR4RXpBUkJnTlZCQW9NQ2sxNVFuVn\
phVzVsYzNNeERUQUxCZ05WQkFjTUJGTnBkR1V4R0RBV0JnTlZCQU1NRDBSdmJXRnBibE\
psWjJsemRISmhjakJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFCQmsxNk\
svaTc5b1JrSzVZYmVQZzhVU1I4L3VzMWRQVWlaSE10b2tTZHFLVzVmbldzQmQrcVJMN1\
dSZmZlV2t5Z2Vib0pmSWxsdXJjaTI1d25oaU9WQ0dqZXpCNU1CMEdBMVVkSlFRV01CUU\
dDQ3NHQVFVRkJ3TUJCZ2dyQmdFRkJRY0RIREFPQmdOVkhROEJBZjhFQkFNQ0I0QXdTQV\
lEVlIwUkJFRXdQNElkY21WbmFYTjBjbUZ5TFhSbGMzUXVjMmxsYldWdWN5MWlkQzV1Wl\
hTQ0huSmxaMmx6ZEhKaGNpMTBaWE4wTmk1emFXVnRaVzV6TFdKMExtNWxkREFLQmdncW\
hrak9QUVFEQWdOSUFEQkZBaUJ4bGRCaFpxMEV2NUpMMlByV0N0eVM2aERZVzF5Q08vUm\
F1YnBDN01hSURnSWhBTFNKYmdMbmdoYmJBZzBkY1dGVVZvL2dHTjAvand6SlowU2wyaD\
R4SVhrMSIsImFnZW50LXNpZ25lZC1kYXRhIjoiZXlKd1lYbHNiMkZrSWpvaVpYbEtjRn\
BZVW0xTVdGcDJaRmRPYjFwWVNYUmpiVlo0WkZkV2VtUkRNWGRqYlRBMldWZGtiR0p1VV\
hSak1teHVZbTFXYTB4WFVtaGtSMFZwVDI1emFWa3pTbXhaV0ZKc1drTXhkbUpwU1RaSm\
FrbDNUV3BKZEUxRWEzUk5ha3BWVFVSVk5rNUVUVFpPVkVGMVRWUkpNVmRwU1hOSmJrNX\
NZMjFzYUdKRE1YVmtWekZwV2xoSmFVOXBTWGROVkVsNlRrUlZNazU2WnpWSmJqRTVJaX\
dpYzJsbmJtRjBkWEpsY3lJNlczc2ljSEp2ZEdWamRHVmtJam9pWlhsS2NtRlhVV2xQYV\
VwVlZFZE5NMWRZYUV4V2JGWldaVzVLTTFKVVRsSlhWRlpEV2xaa2IyTXlNVVZOTW1NNV\
NXbDNhVmxYZUc1SmFtOXBVbFpOZVU1VVdXbG1VU0lzSW5OcFoyNWhkSFZ5WlNJNklrd3\
lZVEJsY3pWZkxXZHNZVjkwTjFVME1VbFJXRmxJU1RSQlMxVldVRkZmTTFSbGQxUTFiMF\
ZWWVVOdFVIQktaMmRyU0c1d09WTk1aVFZ1YWkxbldGbFRiMk5sT1RoeFFXSnROa0YwZF\
MxRlIxUkxZMDVSSW4xZGZRMEsifX0",
  "signatures": [
    {
      "protected": "eyJ4NWMiOlsiTUlJQitUQ0NBYUNnQXdJQkFnSUdBWG5WanNV\
NU1Bb0dDQ3FHU000OUJBTUNNRDB4Q3pBSkJnTlZCQVlUQWtGUk1SVXdFd1lEVlFRS0RB\
eEthVzVuU21sdVowTnZjbkF4RnpBVkJnTlZCQU1NRGtwcGJtZEthVzVuVkdWemRFTkJN\
Q0FYRFRJeE1EWXdOREExTkRZeE5Gb1lEems1T1RreE1qTXhNak0xT1RVNVdqQlNNUXN3\
Q1FZRFZRUUdFd0pCVVRFVk1CTUdBMVVFQ2d3TVNtbHVaMHBwYm1kRGIzSndNUk13RVFZ\
RFZRUUZFd293TVRJek5EVTJOemc1TVJjd0ZRWURWUVFEREE1S2FXNW5TbWx1WjBSbGRt\
bGpaVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFCQzc5bGlhUmNCalpj\
RUVYdzdyVWVhdnRHSkF1SDRwazRJNDJ2YUJNc1UxMWlMRENDTGtWaHRVVjIxbXZhS0N2\
TXgyWStTTWdROGZmd0wyM3ozVElWQldqZFRCek1Dc0dDQ3NHQVFVRkJ3RWdCQjhXSFcx\
aGMyRXRkR1Z6ZEM1emFXVnRaVzV6TFdKMExtNWxkRG81TkRRek1COEdBMVVkSXdRWU1C\
YUFGRlFMak56UC9TL2tvdWpRd2pnNUU1ZnZ3Y1liTUJNR0ExVWRKUVFNTUFvR0NDc0dB\
UVVGQndNQ01BNEdBMVVkRHdFQi93UUVBd0lIZ0RBS0JnZ3Foa2pPUFFRREFnTkhBREJF\
QWlCdTN3UkJMc0pNUDVzTTA3MEgrVUZyeU5VNmdLekxPUmNGeVJST2xxcUhpZ0lnWENt\
SkxUekVsdkQycG9LNmR4NmwxL3V5bVRuYlFERGZKbGF0dVgyUm9PRT0iXSwidHlwIjoi\
dm91Y2hlci1qd3MranNvbiIsImFsZyI6IkVTMjU2In0",
      "signature": "ntAgC7GT7xIDYcHBXoYej8uIUI6WR2Iv-7T1CaR-J6-xS60D\
iWS1-vfc5Uu5INZS1dyWZ4vVH6uaoPceRxNc8g"
    }
  ]
}

A.2. Example Parboiled Registrar Voucher-Request (RVR) - from Registrar to MASA

The term parboiled refers to food which is partially cooked. In [RFC8995], the term refers to a pledge-voucher-request (PVR) which has been received by the Registrar, and then has been processed by the Registrar ("cooked"), and is now being forwarded to the MASA.¶

The following is an example registrar-voucher-request (RVR) sent from the Registrar to the MASA, in "General JWS JSON Serialization". Note that the previous PVR can be seen in the payload as "prior-signed-voucher-request". The message size of this RVR is: 7533 bytes¶

=============== NOTE: '\' line wrapping per RFC 8792 ================

{
  "payload": "eyJpZXRmLXZvdWNoZXItcmVxdWVzdC1wcm06dm91Y2hlciI6eyJhc3\
NlcnRpb24iOiJhZ2VudC1wcm94aW1pdHkiLCJzZXJpYWwtbnVtYmVyIjoiMDEyMzQ1Nj\
c4OSIsImlkZXZpZC1pc3N1ZXIiOiJCQmd3Rm9BVVZBdU0zTS85TCtTaTZORENPRGtUbC\
svQnhocz0iLCJub25jZSI6ImtoTnlLcE10aGNjaWExclh3NDQvdlE9PSIsInByaW9yLX\
NpZ25lZC12b3VjaGVyLXJlcXVlc3QiOiJleUp3WVhsc2IyRmtJam9pWlhsS2NGcFlVbT\
FNV0ZwMlpGZE9iMXBZU1hSamJWWjRaRmRXZW1SRE1YZGpiVEEyWkcwNU1Wa3lhR3hqYV\
VrMlpYbEthR016VG14amJsSndZakkwYVU5cFNtaGFNbFoxWkVNeGQyTnRPVFJoVnpGd1\
pFaHJhVXhEU25wYVdFcHdXVmQzZEdKdVZuUlpiVlo1U1dwdmFVMUVSWGxOZWxFeFRtcG\
pORTlUU1hOSmJUVjJZbTFPYkVscWIybGhNbWhQWlZWMGQxUllVbTlaTWs1d1dWUkdlVm\
RJWXpCT1F6a3lWVlF3T1VscGQybFpNMHBzV1ZoU2JGcERNWFppYVVrMlNXcEpkMDFxVV\
hSTlJGbDBUV3BTVlUxRWF6Wk5SRVUyVFdwUmRVNVVWVEpYYVVselNXMUdibHBYTlRCTV\
dFSjVZak5hY0ZwSFZtdE1XRUo1WWpOb2NHSlhiREJsVXpGNVdsZGtjR016VW5sWldFbD\
BXVEpXZVdSRFNUWkphekZLVTFWSk1HRnJUa1JSVm14d1dqQkdNMU5WU2tKYU1HeElVVl\
pvV2s1NlNtbFpiSEJPVVZjNVNGRXdUbmhTTVU1T1RrUnNRMUZWTVVSVVZWSldaVVZXTm\
xGV1NrTmFNRFZYVVd0R2RsUlZUbkpOVkZaU1lteGFObGxXWXpGaVIwMTZWRmhvUlZaRl\
JrMVJiV1JQVm10S1Fsa3dNVU5TYXpWM1drVmtWbVZGVWpaUlZUVkRXakExVjFGclJrNV\
VWVXB6VlcxNGFrMHhTa1ZWVmxKQ1dsVmFNMDFJYkU1U1JWWTFWRlZTYW1Rd05YRlNWRk\
pPVmtWd2FGSnVZM2RsYXpGRlVsaHNUbEpIVGpOVWJYQkdUa1V4VlZOdFJrNVNSRkkwVW\
xod1FsVnJTbTVVYkZwRFVWYzVUbEV5YzNoT1ZrWjFWbTV3YUZaNlZuTlplazVPWlVWU1\
ZWRlZlRU5hTURWWFVXdEdhbFJWU2tkVWJrSnJVakZXTkZJd1VrSldNRXB1Vkd4YVExRl\
ZNVTVTUkVKVFpHMUtXRkp1UW1saVJYQnpWMnBLYzJWdFVrbFRiV2hxWVd0S1lWUlZTaz\
VTTUVvMVkxVmtWRlJVVVRWUlYyUkdVakJPUkdOVlpGUlVWRkUxVVZoa1JsTkZSWGRUVl\
VaRFVXMXplRTVyYzNaaFZHTTFZakZLY2xONlZscFpiVlpSV25wb1ZsVXhTVFJNTTFaNl\
RWZFNVVlpYYkdGVFJURXdZakowVkZwSVJreFdlbFp0WW14a2VsRnRVWEpqVmtwTlRqRm\
tVMXB0V214V01uUTFXakpXYVdJd2NHMVRWM2h6WkZoS2FtRlVTVEZrTWpWdllWVTVWMU\
V3WkhGYVdIQkRUbFV4UTAxRlpFSk5WbFpyVTJ4R1VsWXdNVU5WVldSRVVUTk9TRkZXUm\
xaU2Ewb3pWRlZLUTFveVpIbFJiV1JHVW10S1Vsa3dVa2xTUlVaUVVXMWtUMVpyYUZKUF\
JVcENXbXBvUmxGclJrNVJNRWt3VVZoa1ZGRldiRVZXYkVsM1ZXdEtSbEpZWkZGT1JXeH\
JXVEl4VjJKdFJsbFVha0pxWWxWYU5WUkdhRk5pUjAxNlZWaFdhazF0ZUhOWmJHUlhaRm\
RPTlUxWGJHdFJlbFl4VjJ4b1ZGRXdhSFZUYlhoaFRXMTRObHBGYUV0aFIwNXdUVlJDWV\
ZkRk5IZFViV3N4WlcxR1dGWnVVbUZXZWxZMlZFWmtTMDFGZUhST1YzaHJVa1ZHVEZGdF\
pHNWpWMmh5WVdzNVVWVldSa1ZSVjJSUFUxVkdSVkZyV2tKaFZVbzBZa2RTUTJGR2NIaE\
5SVll5VGxWd1RVMXNRbmxXTUU0d1pWWk5NbUZGVWxwV2VrWTFVVEE0ZGxWdFJqRlpia0\
pFVGpBeGFGTlZVbTVUVjJoQ1ZFWk9TMWx0WkUxaWJXUnZXVzFLUWxwNlFtdFpNV1JIVm\
xaYWRrd3laRWhVYWtGMllXNWtObE5zYjNkVk1uZDVZVVJTTkZOV2FISk5VMGx6U1cxR2\
JscFhOVEJNV0U1d1dqSTFiRnBETVd0WldGSm9TV3B2YVZwWWJFdGtNV3haWWtoT2FVMX\
JXbkpUVjNCMllWWndXV0pGZEdwU2JrSmFWbGN3ZUZSV1pFZGpSRXBoVW0xU1VGbHFSbm\
RYVms1WlZXMXdhVlpzYnpCWGExcHJWakpXZEZWclVrNVhSMUp4V1d4U1FrMXNaRmRhUj\
NScFVqQndNVlpXYUZOaGF6RjBaVWhXV21KVVJsaFpWRUkwVjBaV2RHRkhkRk5OUmxwM1\
ZrUkpNV1Z0UmxkaE0zQlVZbGhvWVZZd1drdGpNV1J5VkZob2EySlZjSGRWTVZKaFUyMU\
djbUpFVGxWV00wSkxXa1ZWZUZKWFJYcFZhelZvWVROQ1YxWkdWbE5XYXpWeVRsVldWVl\
pHY0ZCV2ExWkhUVlpTVjFWcmNFNVdiVkozVlRGb1QxTnRTbkpPV0U1YVRXcEdlbGxWWk\
V0U1JURlpWbTEwVjJWclduZFdNbmh2VTIxR1ZrOVlRbFJYUjFKUFZtdFdjMDVzVW5KVm\
JGcE9ZWHBWTWxkdWNGZFRiVXB4VWxSV1NtRllaSEJaZWtwelltMUtkRkpxUW10WFJYQn\
pXVE5zU2s1c1kzcGpNbXhxVTBWd01scEZaRmRoYlZKSVZtMTBTbUZ0T1hCWGJHaHpVek\
pPZEZKc2FGWldNbmhSV1ZaV2QxWnNXa1phUlRWT1RWZFNXbGxWVmpSV01rcEhWMnhrWV\
ZaNlZreFVWRVpMVmxaU2MxTnNhRmRTYkhCRlZqSjRZV0V5U1hsVVdHeE9WbFphVDFSWE\
1VNU9WazVZWWtST2FGWnRlRmxhVldNeFUyMUdkRTlZUWxaaVJuQlBXbFpWTVZaV1pGaG\
lSekZXVlRCc2VsTlhOVTlqUm05NVRsZG9hMU5HV2pWWGJFNUtUbXRzY21RemJGcFdSVX\
B6V1ROd1YxcHJlRmhhU0U1YVZtcHJkMVJxUmxaTlJURldZa1pLV0ZKdGVFcFZNVkpUVV\
d4TmVGWnNaRlpTYTFwdFZGUkdVMkpIVVhoVlZFWnBUVVphVjFkV1ZrOWtSbFpKVVd0MF\
lVMXRVbmxWTUdNeFpEQTVWMVJyTVdGV1Jsb3hXVmRyZUdKc1pFZGlSbEpwVFdzMWMxUX\
hVbTlsUmtaWVUyNVNUMkV3V1hkYVJrMTRVbXhKZUZWcmVGcE5SRlpUVTFjMGVGcEhXbE\
pOUlhOcFpsZ3dJaXdpYzJsbmJtRjBkWEpsY3lJNlczc2ljSEp2ZEdWamRHVmtJam9pWl\
hsS05FNVhUV2xQYkhOcFZGVnNTbEZwZEZWUk1FNUNXVlZPYmxGWVpFcFJhMFp1VTFWa1\
FsZEhOVmRoYms1V1RsVXhRbUl3WkVSUk0wWklWVEF3TUU5VlNrSlVWVTVPVWtSQ05GRX\
pjRUpUYTBwdVZHeGFRMUZXYkZWUlYzUkhWV3N4VTFaWVpFWmtNV3hGVm14R1VsTXdVa0\
psUlhSb1ZucFdkVlV5TVhOa1ZtOTNWRzVhYW1KclJqUlNibkJDVm10S2JsUnNXa05SVl\
RGT1VrZDBkMk5IU25SYVJYUm9WbnBXZFZaclpGZGxiVkpHVkd0S1RsRXdSbGxTUmxKS1\
pVVXhSVmRZWkU5U1JVVjRWR3RTV21WRk5VZGlNV3hGWlcxek1WUXhVbkpsUlRGeFZGaG\
9UbUZyTUhoVU1WSldUbFprY1ZGc1RrNVZXRTR6VVRGR1dsSkdXbEpWVldSR1pEQndRMV\
pXVWtaV2F6RkRWRlZrUWsxV1ZrWlJNbVF6VkZaT2RHSklWbUZOU0VKM1dXMHhhMUpIU1\
hwVGJtUk9WV3N4TTFKV1JscFNSbHBTVlZWYVJtUXlPVE5VVmxKS1pXczFSVlpVU2s5bG\
JXTXhWRlpLYW1Rd1dsSlhWVkpYVlZaR1JWSkZSVEZUTWtaWVRsYzFWR0pYZURGWGFrSl\
RZa2RTZEdKSGNHRldSVXBoVkZWS1RsSXdTalZqVldSVVZGUlJOVkZYWkVaU01FNUVZMV\
ZrVkZSVVVUVlJXR1JHVTBWRmQxTlZSa05SZW1NMVlrZHNhRlZ0VGtOaGJIQnFVbFZXV1\
dSNlpIbFdWMVpvWkc1U1NGTnJSakZUUkZKM1lYcFNTazVFU2pKWlZVcE9ZekZWZUUxWG\
JFMVNSVTVFVkVkMFYyRklVbFpXYWtsNFlsaGFhRk13VGpKVVdHZDVWMU4wVkZSWFpGSl\
BSMXB0WkRCM2VVMHpiM3BXUld4WFVXeGtjVnBHVWtObGF6RkVZekJrUkZFelRraFJWa1\
pXVW10S00xSlhaRU5SYW1oWVUwWmplR0ZIVFhsU1dGSnJVakZhTmxwRlRURmxiVVpZVm\
01U1lWWjZWalpVUm1STFRVVjRkRTVYZUd0U1J6Z3hWR3RTVW1Wck1VTlBSV1JDVFZaV2\
ExTllaRkpYVlRGRFdWVkdSMUpzUmsxaGF6VTJWVU01VkV3eWRIWmtWM0JTWkRKd2JrNV\
ZWVEZhYmxveldURnNhVlJWU2s1U01FVjRWbGRTUzFWV1JrNVVWVVoyVWpCT1JHTXdaRU\
pWVmxaSFVXNWtUbEV3TVVKT1JXUkNUVlpXYTFKSVpFWlJhVGt6VlZWV1FtUXdiRWxhTU\
ZKQ1V6QktibG96Um05aE1uQlFWVVpHVWxKRlJtNVVhMmhDVWtWS1JsRlhiRU5rVkU0el\
ZXdEtUV013Y0U1VlJGWjZWRlJCTTAxRlozSldWVnA1WlZVMVZrNXRaRXhsYTNoUVZXMU\
9SMlZXU2xOVU1uaDRZMVZvY0Zvd2JHNVhSVTUwVTJ0NFZXVnJWbk5rYTFGNVkwYzVURT\
V0VWpST2JYZDRURE5XTldKV1VuVlpiRVpGVWtkYVMySkhSakJrVm1kNVZXMDVVRkpVTU\
dsWVUzZHBaRWhzZDBscWIybGtiVGt4V1RKb2JHTnBNWEZrTTAxeVlXNU9kbUpwU1hOSm\
JVWnpXbmxKTmtsclZsUk5hbFV5U1c0d0lpd2ljMmxuYm1GMGRYSmxJam9pYm5SQlowTT\
NSMVEzZUVsRVdXTklRbGh2V1dWcU9IVkpWVWsyVjFJeVNYWXROMVF4UTJGU0xVbzJMWG\
hUTmpCRWFWZFRNUzEyWm1NMVZYVTFTVTVhVXpGa2VWZGFOSFpXU0RaMVlXOVFZMlZTZU\
U1ak9HY2lmVjE5IiwiY3JlYXRlZC1vbiI6IjIwMjQtMDYtMjRUMDk6MDI6MTUuNTczWi\
IsImFnZW50LXNpZ24tY2VydCI6WyJNSUlCOWpDQ0FaMmdBd0lCQWdJRVl4WHM3VEFLQm\
dncWhrak9QUVFEQWpBK01STXdFUVlEVlFRS0RBcE5lVUoxYzJsdVpYTnpNUTB3Q3dZRF\
ZRUUhEQVJUYVhSbE1SZ3dGZ1lEVlFRRERBOVVaWE4wVUhWemFFMXZaR1ZzUTBFd0hoY0\
5Nakl3T1RBMU1USXpORFV6V2hjTk1qVXdPVEExTVRJek5EVXpXakJnTVFzd0NRWURWUV\
FHRXdKQlVURVNNQkFHQTFVRUNnd0pUWGxEYjIxd1lXNTVNUlV3RXdZRFZRUUxEQXhOZV\
ZOMVluTnBaR2xoY25reEpqQWtCZ05WQkFNTUhVMTVVMmwwWlZCMWMyaE5iMlJsYkZKbF\
oybHpkSEpoY2tGblpXNTBNRmt3RXdZSEtvWkl6ajBDQVFZSUtvWkl6ajBEQVFjRFFnQU\
V4aHZuYWtDSmVpZ3pqWkFVYU5adVAwMWUrUWxVY1E5UjJMSWs2UkI2dmtjdFdMS3BaWC\
85TGthNEdxckFWWmhhM3ZKcmhGc0l4OEdUQkhqWnZLMVd1Nk5uTUdVd0RnWURWUjBQQV\
FIL0JBUURBZ09JTUI4R0ExVWRJd1FZTUJhQUZHK2hQVzUxN1ovb3NSQ0ZUc2NlUDY4bj\
kzc2pNQjBHQTFVZERnUVdCQlJNdHp0akVwVlJUT3ZBVGRCamtGNWFHeVlQZURBVEJnTl\
ZIU1VFRERBS0JnZ3JCZ0VGQlFjREFqQUtCZ2dxaGtqT1BRUURBZ05IQURCRUFpQmJoRG\
pwbDJ2cWNONnBSVjRuZVU0dFFsWWFOTit4ZjNnSnUrMHBKblNBL1FJZ0ljcXpsZmhYaU\
Qxc0g3VTVQdUtwVVpzSWpkRjRSenhzQTZxSnRFTEQyUHM9Il19fQ",
  "signatures": [
    {
      "protected": "eyJ4NWMiOlsiTUlJQm96Q0NBVXFnQXdJQkFnSUdBVzBlTHVJ\
Rk1Bb0dDQ3FHU000OUJBTUNNRFV4RXpBUkJnTlZCQW9NQ2sxNVFuVnphVzVsYzNNeERU\
QUxCZ05WQkFjTUJGTnBkR1V4RHpBTkJnTlZCQU1NQmxSbGMzUkRRVEFlRncweE9UQTVN\
VEV3TWpNM016SmFGdzB5T1RBNU1URXdNak0zTXpKYU1GUXhFekFSQmdOVkJBb01DazE1\
UW5WemFXNWxjM014RFRBTEJnTlZCQWNNQkZOcGRHVXhMakFzQmdOVkJBTU1KVkpsWjJs\
emRISmhjaUJXYjNWamFHVnlJRkpsY1hWbGMzUWdVMmxuYm1sdVp5QkxaWGt3V1RBVEJn\
Y3Foa2pPUFFJQkJnZ3Foa2pPUFFNQkJ3TkNBQVQ2eFZ2QXZxVHoxWlVpdU5XaFhwUXNr\
YVB5N0FISFFMd1hpSjBpRUx0NnVOUGFuQU4wUW5XTVlPLzBDREVqSWtCUW9idzhZS3Fq\
dHhKSFZTR1RqOUtPb3ljd0pUQVRCZ05WSFNVRUREQUtCZ2dyQmdFRkJRY0RIREFPQmdO\
VkhROEJBZjhFQkFNQ0I0QXdDZ1lJS29aSXpqMEVBd0lEUndBd1JBSWdZcjJMZnFvYUNL\
REY0UkFjTW1KaStOQ1pxZFNpdVZ1Z0lTQTdPaEtScTNZQ0lEeG5QTU1ucFhBTVRyUEp1\
UFd5Y2VFUjExUHhIT24rMENwU0hpMnFncFdYIl0sInR5cCI6InZvdWNoZXItandzK2pz\
b24iLCJhbGciOiJFUzI1NiJ9",
      "signature": "_mcsO5vo0g2rFmBvTb-UsOWkEmhYNfQ5XmbuKHKH0ZLjea-7\
911BilAMdFORmT4vCzWKBSH6HSqtpIRcSSxx7Q"
    }
  ]
}

A.3. Example Voucher - from MASA to Pledge, via Registrar and Registrar-Agent

The following is an example voucher-response from MASA to Pledge via Registrar and Registrar-Agent, in "General JWS JSON Serialization". The message size of this Voucher is: 1916 bytes¶

=============== NOTE: '\' line wrapping per RFC 8792 ================

{
  "payload":"eyJpZXRmLXZvdWNoZXI6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJhZ2V\
udC1wcm94aW1pdHkiLCJzZXJpYWwtbnVtYmVyIjoiMDEyMzQ1Njc4OSIsIm5vbmNlIjo\
iTDNJSjZocHRIQ0lRb054YWFiOUhXQT09IiwiY3JlYXRlZC1vbiI6IjIwMjItMDQtMjZ\
UMDU6MTY6MjguNzI2WiIsInBpbm5lZC1kb21haW4tY2VydCI6Ik1JSUJwRENDQVVtZ0F\
3SUJBZ0lHQVcwZUx1SCtNQW9HQ0NxR1NNNDlCQU1DTURVeEV6QVJCZ05WQkFvTUNrMTV\
RblZ6YVc1bGMzTXhEVEFMQmdOVkJBY01CRk5wZEdVeER6QU5CZ05WQkFNTUJsUmxjM1J\
EUVRBZUZ3MHhPVEE1TVRFd01qTTNNekphRncweU9UQTVNVEV3TWpNM016SmFNRFV4RXp\
BUkJnTlZCQW9NQ2sxNVFuVnphVzVsYzNNeERUQUxCZ05WQkFjTUJGTnBkR1V4RHpBTkJ\
nTlZCQU1NQmxSbGMzUkRRVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUF\
CT2t2a1RIdThRbFQzRkhKMVVhSTcrV3NIT2IwVVMzU0FMdEc1d3VLUURqaWV4MDYvU2N\
ZNVBKaWJ2Z0hUQitGL1FUamdlbEhHeTFZS3B3Y05NY3NTeWFqUlRCRE1CSUdBMVVkRXd\
FQi93UUlNQVlCQWY4Q0FRRXdEZ1lEVlIwUEFRSC9CQVFEQWdJRU1CMEdBMVVkRGdRV0J\
CVG9aSU16UWRzRC9qLytnWC83Y0JKdWNIL1htakFLQmdncWhrak9QUVFEQWdOSkFEQkd\
BaUVBdHhRMytJTEdCUEl0U2g0YjlXWGhYTnVocVNQNkgrYi9MQy9mVllEalE2b0NJUUR\
HMnVSQ0hsVnEzeWhCNThUWE1VYnpIOCtPbGhXVXZPbFJEM1ZFcURkY1F3PT0ifX0",
  "signatures":[{
    "protected":"eyJ4NWMiOlsiTUlJQmt6Q0NBVGlnQXdJQkFnSUdBV0ZCakNrWU1\
Bb0dDQ3FHU000OUJBTUNNRDB4Q3pBSkJnTlZCQVlUQWtGUk1SVXdFd1lEVlFRS0RBeEt\
hVzVuU21sdVowTnZjbkF4RnpBVkJnTlZCQU1NRGtwcGJtZEthVzVuVkdWemRFTkJNQjR\
YRFRFNE1ERXlPVEV3TlRJME1Gb1hEVEk0TURFeU9URXdOVEkwTUZvd1R6RUxNQWtHQTF\
VRUJoTUNRVkV4RlRBVEJnTlZCQW9NREVwcGJtZEthVzVuUTI5eWNERXBNQ2NHQTFVRUF\
3d2dTbWx1WjBwcGJtZERiM0p3SUZadmRXTm9aWElnVTJsbmJtbHVaeUJMWlhrd1dUQVR\
CZ2NxaGtqT1BRSUJCZ2dxaGtqT1BRTUJCd05DQUFTQzZiZUxBbWVxMVZ3NmlRclJzOFI\
wWlcrNGIxR1d5ZG1XczJHQU1GV3diaXRmMm5JWEgzT3FIS1Z1OHMyUnZpQkdOaXZPS0d\
CSEh0QmRpRkVaWnZiN294SXdFREFPQmdOVkhROEJBZjhFQkFNQ0I0QXdDZ1lJS29aSXp\
qMEVBd0lEU1FBd1JnSWhBSTRQWWJ4dHNzSFAyVkh4XC90elVvUVwvU3N5ZEwzMERRSU5\
FdGNOOW1DVFhQQWlFQXZJYjNvK0ZPM0JUbmNMRnNhSlpSQWtkN3pPdXNuXC9cL1pLT2F\
FS2JzVkRpVT0iXSwiYWxnIjoiRVMyNTYifQ",
    "signature":"0TB5lr-cs1jqka2vNbQm3bBYWfLJd8zdVKIoV53eo2YgSITnKKY\
TvHMUw0wx9wdyuNVjNoAgLysNIgEvlcltBw"
  }]
}

A.4. Example Voucher, MASA issued Voucher with additional Registrar signature (from MASA to Pledge, via Registrar and Registrar-Agent)

The following is an example voucher-response from MASA to Pledge via Registrar and Registrar-Agent, in "General JWS JSON Serialization". The message size of this Voucher is: 2994 bytes¶

=============== NOTE: '\' line wrapping per RFC 8792 ================

{
  "payload": "eyJpZXRmLXZvdWNoZXI6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJhZ2\
VudC1wcm94aW1pdHkiLCJzZXJpYWwtbnVtYmVyIjoiMDEyMzQ1Njc4OSIsIm5vbmNlIj\
oia2hOeUtwTXRoY2NpYTFyWHc0NC92UT09IiwiY3JlYXRlZC1vbiI6IjIwMjQtMDYtMj\
RUMDk6MDI6MTYuMjQ0WiIsInBpbm5lZC1kb21haW4tY2VydCI6Ik1JSUJwRENDQVVtZ0\
F3SUJBZ0lHQVcwZUx1SCtNQW9HQ0NxR1NNNDlCQU1DTURVeEV6QVJCZ05WQkFvTUNrMT\
VRblZ6YVc1bGMzTXhEVEFMQmdOVkJBY01CRk5wZEdVeER6QU5CZ05WQkFNTUJsUmxjM1\
JEUVRBZUZ3MHhPVEE1TVRFd01qTTNNekphRncweU9UQTVNVEV3TWpNM016SmFNRFV4RX\
pBUkJnTlZCQW9NQ2sxNVFuVnphVzVsYzNNeERUQUxCZ05WQkFjTUJGTnBkR1V4RHpBTk\
JnTlZCQU1NQmxSbGMzUkRRVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSU\
FCT2t2a1RIdThRbFQzRkhKMVVhSTcrV3NIT2IwVVMzU0FMdEc1d3VLUURqaWV4MDYvU2\
NZNVBKaWJ2Z0hUQitGL1FUamdlbEhHeTFZS3B3Y05NY3NTeWFqUlRCRE1CSUdBMVVkRX\
dFQi93UUlNQVlCQWY4Q0FRRXdEZ1lEVlIwUEFRSC9CQVFEQWdJRU1CMEdBMVVkRGdRV0\
JCVG9aSU16UWRzRC9qLytnWC83Y0JKdWNIL1htakFLQmdncWhrak9QUVFEQWdOSkFEQk\
dBaUVBdHhRMytJTEdCUEl0U2g0YjlXWGhYTnVocVNQNkgrYi9MQy9mVllEalE2b0NJUU\
RHMnVSQ0hsVnEzeWhCNThUWE1VYnpIOCtPbGhXVXZPbFJEM1ZFcURkY1F3PT0ifX0",
  "signatures": [
    {
      "protected": "eyJ4NWMiOlsiTUlJQmt6Q0NBVGlnQXdJQkFnSUdBV0ZCakNr\
WU1Bb0dDQ3FHU000OUJBTUNNRDB4Q3pBSkJnTlZCQVlUQWtGUk1SVXdFd1lEVlFRS0RB\
eEthVzVuU21sdVowTnZjbkF4RnpBVkJnTlZCQU1NRGtwcGJtZEthVzVuVkdWemRFTkJN\
QjRYRFRFNE1ERXlPVEV3TlRJME1Gb1hEVEk0TURFeU9URXdOVEkwTUZvd1R6RUxNQWtH\
QTFVRUJoTUNRVkV4RlRBVEJnTlZCQW9NREVwcGJtZEthVzVuUTI5eWNERXBNQ2NHQTFV\
RUF3d2dTbWx1WjBwcGJtZERiM0p3SUZadmRXTm9aWElnVTJsbmJtbHVaeUJMWlhrd1dU\
QVRCZ2NxaGtqT1BRSUJCZ2dxaGtqT1BRTUJCd05DQUFTQzZiZUxBbWVxMVZ3NmlRclJz\
OFIwWlcrNGIxR1d5ZG1XczJHQU1GV3diaXRmMm5JWEgzT3FIS1Z1OHMyUnZpQkdOaXZP\
S0dCSEh0QmRpRkVaWnZiN294SXdFREFPQmdOVkhROEJBZjhFQkFNQ0I0QXdDZ1lJS29a\
SXpqMEVBd0lEU1FBd1JnSWhBSTRQWWJ4dHNzSFAyVkh4L3R6VW9RL1NzeWRMMzBEUUlO\
RXRjTjltQ1RYUEFpRUF2SWIzbytGTzNCVG5jTEZzYUpaUkFrZDd6T3Vzbi8vWktPYUVL\
YnNWRGlVPSJdLCJ0eXAiOiJ2b3VjaGVyLWp3cytqc29uIiwiYWxnIjoiRVMyNTYifQ",
      "signature": "SFtc2xqK8xN2KVqkYKJl7EUU8UJAai3VvCuK8LIfH8HZFvrr\
hqGiY8vK5cbQHQCjVcroFLn7IyhH708XAdstAQ"
    },
    {
      "protected": "eyJ4NWMiOlsiTUlJQjRqQ0NBWWlnQXdJQkFnSUdBWFk3MmJi\
Wk1Bb0dDQ3FHU000OUJBTUNNRFV4RXpBUkJnTlZCQW9NQ2sxNVFuVnphVzVsYzNNeERU\
QUxCZ05WQkFjTUJGTnBkR1V4RHpBTkJnTlZCQU1NQmxSbGMzUkRRVEFlRncweU1ERXlN\
RGN3TmpFNE1USmFGdzB6TURFeU1EY3dOakU0TVRKYU1ENHhFekFSQmdOVkJBb01DazE1\
UW5WemFXNWxjM014RFRBTEJnTlZCQWNNQkZOcGRHVXhHREFXQmdOVkJBTU1EMFJ2YldG\
cGJsSmxaMmx6ZEhKaGNqQlpNQk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VIQTBJQUJC\
azE2Sy9pNzlvUmtLNVliZVBnOFVTUjgvdXMxZFBVaVpITXRva1NkcUtXNWZuV3NCZCtx\
Ukw3V1JmZmVXa3lnZWJvSmZJbGx1cmNpMjV3bmhpT1ZDR2plekI1TUIwR0ExVWRKUVFX\
TUJRR0NDc0dBUVVGQndNQkJnZ3JCZ0VGQlFjREhEQU9CZ05WSFE4QkFmOEVCQU1DQjRB\
d1NBWURWUjBSQkVFd1A0SWRjbVZuYVhOMGNtRnlMWFJsYzNRdWMybGxiV1Z1Y3kxaWRD\
NXVaWFNDSG5KbFoybHpkSEpoY2kxMFpYTjBOaTV6YVdWdFpXNXpMV0owTG01bGREQUtC\
Z2dxaGtqT1BRUURBZ05JQURCRkFpQnhsZEJoWnEwRXY1SkwyUHJXQ3R5UzZoRFlXMXlD\
Ty9SYXVicEM3TWFJRGdJaEFMU0piZ0xuZ2hiYkFnMGRjV0ZVVm8vZ0dOMC9qd3pKWjBT\
bDJoNHhJWGsxIl0sInR5cCI6InZvdWNoZXItandzK2pzb24iLCJhbGciOiJFUzI1NiJ9\
",
      "signature": "0Q7_a7L4ahn2vmfSxxkKg1xsOMMc8_D7B_Ilzqv5DKzCMkc7\
8YeeezDsuh4Z5JNVQUYHPp7LsK_AS_WH8TdVzA"
    }
  ]
}