Draft: draft-ietf-anima-brski-prm

Commentary: I have started my shepherd review on this draft . The main overall impression is that it is still a very complex draft that is thus hard to read . Hence , this is work - in - progress and will need more iterations before completion and merging . My high - level comments are : A lot of redundancy : many statements are made several times without adding information or making hard - to - understand points clearer . Up to Section 4 , I tried to clean this up already . Motivation not clearly given : The motivation uses " the pledge is in server role " as argument , although this is part of the design decision of the solution to solve the actual requirements . To my understanding , these are : Pledges have no direct connection to the registrar ( e.g. , offline or non - IP connectivity ) Pledges have only limited connectivity ( e.g. , time - wise or over constrained networks ) and requests need to be coordinated Pledge need to be bootstrapped in bulk ( e.g. , building automation scenarios ) I tried to improve on this , but another pass to improve the abstract and introduction could improve the document . Contains requirements discussion : Usually this happens in separate , information documents . The reasoning can be helpful to the reader , but it is currently not very concise . Do we need the level of detail in Section 4 ? Very few normative assertions : The text is rather descriptive and it is hard for implementers to find the important passages . This is connected to the current structure of Section 5 : There is already a split into components , data objects , and exchanges , which distributes normative statements . However , Section 5 again splits into rough component descriptions , concepts , and behavior . For the next iteration , I recommend to remove heading 5.1 ( Registrar - Agent Communication with Pledges ) , get rid of the redundancy above and below this heading , and to make " Pledge [ in Responder  ] " , " Registrar - Agent " , " Domain Registrar " , and " Vendor Services " new subsections , as these are the main components of the architecture . " Agent - Proximity Assertion " is an important section and also needs to have a prominent place ; unclear if rather subsection or sibling section . Detailed comments are with the GitHub review feature per line . 
   , I see you were eager to merge . Happy to see my proposals were straight - forward to accept . However , I thought we can use the WIP pull request to do iterations of discussion and also allow me to complete proposals for the second half ( note : usually WiP or WIP prefixed pull requests are not intended to merge , as they are still work - in - progress ;) ) . Let 's wrap up the first part of my review by adding and eventually resolving comments to this already merged PR . The main answer I need for my second half of the review : How to proceed with the restructuring of Section 5 . Will you do this and ping me , so I continue then , or should I help by making a concrete proposal ? I feel I currently have the benefit if being new to this draft , so for me it is clearer where context or details are missing ... Hence , I am happy to make a proposal ; just let me know about roadmap / deadlines . 
   , sorry for reacting too fast . Yes , I was eager to get the changes in the draft , before the deadline next Monday . Specifically as most of them were straight forward and did not require much discussion . Your proposal sounds fine to me . Lets wrap up the first part as you suggested and proceed with the restructuring of section 5 . For the restructuring , I think it would be great if you could come up with a proposal , since your are digesting the approach right now and see gaps much better . I may be already too deep into the approach to actually miss information in certain places , which is provided later in the document . Thank you .
This document defines enhancements to bootstrapping a remote secure
key infrastructure (BRSKI, RFC8995) to facilitate bootstrapping in
domains featuring no or only time limited connectivity between a
pledge and the domain registrar.  It specifically targets situations
in which the interaction model changes from a pledge-initiated-mode,
as used in BRSKI, to a pledge-responding-mode as described in this
document.  To support the pledge-responding mode, BRSKI-PRM
introduces a new component, the registrar-agent, which facilitates
the communication between pledge and registrar during the
bootstrapping phase.  To establish the trust relation between pledge
and domain registrar, BRSKI-PRM relies on object security rather than
transport security.
The approach defined here is agnostic with respect to the underlying
enrollment protocol which connects the pledge and the domain
registrar to the Domain CA.
This document defines enhancements to Bootstrapping a Remote Secure
Key Infrastructure (BRSKI) RFC8995 to enable bootstrapping in domains
featuring no or only limited connectivity between a pledge and the
domain registrar.  It specifically changes the interaction model from
a pledge-initiated mode, as used in BRSKI, to a pledge-responding
mode, where the pledge is in server role.  For this, BRSKI with
Pledge in Responder Mode (BRSKI-PRM) introduces a new component, the
registrar-agent, which facilitates the communication between pledge
and registrar during the bootstrapping phase.  To establish the trust
relation between pledge and registrar, BRSKI-PRM relies on object
security rather than transport security.  The approach defined here
is agnostic to the underlying enrollment protocol that connects the
pledge and the domain registrar to the domain CA.
Security information about the customer site/domain, specifically the
customer site/domain certificate,are exchanged and authenticated
utilizing voucher request objects and voucher response objects as
defined in RFC8995.  Voucher objects are specified in RFC8366.
Vouchers are signed objects from the Manufacturer's Authorized
Signing Authority (MASA).  The MASA issues the voucher object and
provides it via the domain registrar to the pledge.
Security information about the customer site/domain, specifically the
customer site/domain certificate, are exchanged and authenticated
utilizing voucher-request and voucher-response artifacts as defined
in RFC8995.  Vouchers are signed objects from the Manufacturer's
Authorized Signing Authority (MASA).  The MASA issues the voucher and
provides it via the domain registrar to the pledge.  RFC8366
specifies the format of the voucher artifacts.
introduces the registrar-agent as new component to facilitate the
communication between the pledge and the registrar, as the pledge
is in responder mode, and acts as server.  For the interaction
with the domain registrar the registrar-agent will use existing
BRSKI RFC8995 endpoints as well as additional endpoints defined in
this document.  The registrar-agent may be implemented as an
integrated functionality of a commissioning tool or be co-located
with the registrar itself.
specifies the interaction (data exchange and data objects) between
a pledge acting as server and a registrar-agent and the domain
registrar.  The security is addressed on the application layer
only to enable usage of arbitrary transport means between the
pledge and the domain registrar via the registrar-agent.
Connectivity between the pledge and the registrar-agent may be via
IP-based networks (wired or wireless) but also others like
Bluetooth or NFC.
allows the application of registrar-agent credentials to establish
TLS connections to the domain registrar.  These registrar-agent
credentials are different from the pledge's IDevID.
The term endpoint used in the context of this document is similar to
resources in CoAP RFC7252 and also in HTTP RFC9110.  It is not used
to describe a device.  Endpoints are accessible via .well-known URIs.
To utilize the EST server endpoints on the domain registrar, the
registrar-agent will act as client towards the domain registrar.
The registrar-agent also acts as a client when communicating with a
pledge in responder mode.  Here, TLS with server-side, certificate-
based authentication is not directly applicable, as the pledge only
possesses an IDevID certificate.  The IDevID does not contain any
anchor for which any kind of RFC6125 validation can be done.  Second,
the registrar-agent may not be aware of manufacturer trust anchors to
validate the IDevIDs.  Finally, IDevIDs do not typically set Extended
Key Usage (EKU) for TLS WWW Server authentication.
The inability to effectively do TLS in responder mode is one reason
for relying on object security.  Another reason is the application on
different transports channels, for which TLS may not be available,
such as Bluetooth and NFC.
Therefore, BRSKI-PRM relies on an additional signature wrapping of
the exchanged data objects involving the registrar-agent for
transport.  For EST RFC7030 the registrar then needs to do some pre-
processing to verify this signature, which is not present in EST.
introduces the registrar-agent as new component to facilitate the
communication between the pledge and the domain registrar; the
registrar-agent may be implemented as an integrated functionality
of a commissioning tool or be co-located with the registrar
itself.
specifies the interaction (data exchange and data objects) between
a pledge acting as server, the registrar-agent acting as client,
and the domain registrar.
enables the usage of arbitrary transports between the pledge and
the domain registrar via the registrar-agent; security is
addressed at the application layer, and both IP-based and non-IP
connectivity can be used between pledge and registrar-agent.
allows the application of registrar-agent credentials to establish
TLS connections to the domain registrar; these are different from
the IDevID of the pledge.
The term endpoint used in the context of this document is equivalent
to resource in HTTP RFC9110 and CoAP RFC7252; it is not used to
describe a device.  Endpoints are accessible via Well-Known URIs
RFC8615.  For the interaction with the domain registrar, the
registrar-agent will use existing BRSKI RFC8995 endpoints as well as
additional endpoints defined in this document.  To utilize the EST
server endpoints on the domain registrar, the registrar-agent will
act as client toward the registrar.
The registrar-agent also acts as a client when communicating with a
pledge in responder mode.  Here, TLS with server-side, certificate-
based authentication is not directly applicable, as the pledge only
possesses an IDevID certificate.  First, the IDevID does not contain
any anchor for which any kind of RFC6125 validation can be done.
Second, the registrar-agent may not be aware of manufacturer trust
anchors to validate the IDevIDs.  Finally, IDevIDs do not typically
set Extended Key Usage (EKU) for TLS WWW Server authentication.
The inability to effectively do TLS in responder mode is one reason
for relying on object security at the application layer.  Another
reason is the support for alternative transports for which TLS may
not be available, e.g., Bluetooth or NFC.  Therefore, BRSKI-PRM
relies on an additional signature wrapping of the exchanged data
objects involving the registrar-agent for transport.  For EST RFC7030
the domain registrar then needs to do some pre-processing to verify
this signature, which is not present in EST.
There may be pledges which can support both modes, initiator and
responder mode.  In these cases BRSKI-PRM can be combined with BRSKI
as defined in RFC8995 or BRSKI-AE I-D.ietf-anima-brski-ae to allow
for more bootstrapping flexibility.
BRSKI-PRM is applicable to environments where pledges are in pledge-
responder-mode and may have no continuous connection to a domain
registrar.  Either way pledges are expected to be managed by the same
registrar.
This can be motivated by pledges deployed in environments not yet
connected to the operational customer site/domain network, e.g., at a
construction site where a building is going up.
Another environment relates to the assembly of cabinets, which are
prepared in advance to be installed on a customer site/domain.
As there is no direct connection to the registrar available in these
environments the solution specified allows the pledges to act in a
server role so they can be triggered for bootstrapping e.g., by a
commissioning tool.
As BRSKI defines the pledge in a client role, initiating the
bootstrapping (pledge-initiated-mode), BRSKI-PRM in contrast defines
pledges acting as a server (pledge-responder-mode) responding to PVR
and PER and consumption of the results.
The following examples motivate support of BRSKI-PRM to support
pledges acting as server as well as pledges with limited connectivity
to the registrar.
While BRSKI-PRM defines support for pledges in responder mode, there
may be pledges which can act as both initiator or responder.  In
these cases BRSKI-PRM can be combined with BRSKI as defined in
RFC8995 or BRSKI-AE I-D.ietf-anima-brski-ae to allow for more
bootstrapping flexibility.
A pledge in pledge-initiator-mode should listen for announcement
messages as described in RFC8995.  Upon discovery of a potential
Registrar, it initiates the bootstrapping to that Registrar.  At the
same time (so as to avoid the Slowloris-attack described in RFC8995),
it SHOULD also respond to the pledge-responder-mode connections
described in this document.
Once a pledge with such combined functionality has been bootstrapped,
it MAY act as client for enrollment of further certificates needed,
e.g., using the enrollment protocol of choice.  If it still acts as
server, the defined BRSKI-PRM endpoints to trigger a Pledge-
Enrollment-Request (PER) or to provide a enrollment response can be
used for further certificates.
In building automation a typical use case exists where a detached
building (or a cabinet) or the basement of a building is equipped
with sensors, actuators and controllers, but with only limited or no
connection to the central building management system.  This limited
connectivity may exist during installation time or also during
operation time.
During the installation, for instance, in the basement, a service
technician collects the device specific information from the basement
network and provides them to the central building management system.
This could be done using a laptop, common mobile device, or dedicated
commissioning tool to transport the information.  The service
technician may visit every new building in a subdivision collecting
device specific information before connecting to the Registrar.
A domain registrar may be part of the central building management
system and already be operational in the installation network.  The
central building management system can then provide operational
parameters for the specific devices in the basement.  These
operational parameters may comprise values and settings required in
the operational phase of the sensors/actuators, among them a
certificate issued by the operator to authenticate against other
components and services.  These operational parameters are then
provided to the devices in the basement facilitated by the service
technician's laptop.  The registrar-agent, defined in this document,
may be run on the technician's laptop to interact with pledges.
This protocol unavoidably has a mix of both base64 encoded data (as
is normal for many JSON encoded protocols), and also BASE64URL
encoded data, as specified by JWS.  The latter is indicated by a
string like "BASE64URL(content-name)".
BRSKI-PRM is applicable to scenarios where pledges have no direct
connection to the domain registrar, have no continuous connection, or
require coordination of the pledge requests (e.g., to work in
constrained environments).  Either way, such pledges are expected to
be managed by the same domain registrar as other BRSKI pledges.
This can be motivated by pledges deployed in environments not yet
connected to the operational customer site/domain network, e.g., at a
building construction site, or environments intentionally
disconnected from the Internet, e.g., critical idustrial facilities.
Another example is the assembly of electrical cabinets, which are
prepared in advance before the installation at a customer site/
domain.
In building automation a typical use case exists where a detached
building or the basement is equipped with sensors, actuators, and
controllers, but with only limited or no connection to the central
building management system.  This limited connectivity may exist
during installation time or also during operation time.
During the installation, for instance, a service technician collects
the device-specific information from the basement network and
provides them to the central building management system.  This could
be done using a laptop, common mobile device, or dedicated
commissioning tool to transport the information.  The service
technician may successively collect device-specific information in
different parts of the building before connecting to the domain
registrar for bulk bootstrapping.
A domain registrar may be part of the central building management
system and already be operational in the installation network.  The
central building management system can then provide operational
parameters for the specific devices in the basement or other detached
areas.  These operational parameters may comprise values and settings
required in the operational phase of the sensors/actuators, among
them a certificate issued by the operator to authenticate against
other components and services.  These operational parameters are then
provided to the devices in the basement facilitated by the service
technician's laptop.  The registrar-agent, defined in this document,
may be run on the technician's laptop to interact with pledges.
Based on the intended target environment described in sup-env the
following requirements are derived to support bootstrapping of
pledges in responder mode (acting as server).
To facilitate the communication between a pledge in responder mode
and registrar, additional functionality is needed either on the
registrar or as a stand-alone component.  This new functionality
is defined as registrar-agent and acts as an agent of the
registrar to trigger the pledge to generate requests for voucher
and enrollment.  These requests are then provided by the
registrar-agent to the registrar.  This requires the definition of
pledge endpoints to allow interaction with the registrar-agent.
The communication between the registrar-agent and the pledge MUST
NOT rely on transport layer security (TLS) because the pledge does
not have a certificate that can easily be verified by RFC6125
methods.  It is also more difficult to use TLS over other
technology stacks (e.g., BTLE).
The use of authenticated self-contained objects provides a work
around for both the TLS challenges, and the technology stack
challenge.
To facilitate the communication between a pledge in responder mode
and the registrar, additional functionality is needed either on
the registrar or as a stand-alone component.  This new
functionality is defined as registrar-agent and acts as an agent
of the registrar to trigger the pledge to generate requests for
voucher and enrollment.  These requests are then provided by the
registrar-agent to the registrar.  This requires the definition of
pledge endpoints to allow interaction with the registrar-agent.
The communication between the registrar-agent and the pledge must
not rely on Transport Layer Security (TLS) because the pledge does
not have a certificate that can easily be verified by RFC6125
methods.  It is also more difficult to use TLS over other
technology stacks (e.g., NFC).
The use of authenticated self-contained objects provides a work
around for both the TLS challenges and the technology stack
challenge.
It would be inaccurate for the voucher request and voucher
response to use an assertion with value "proximity" in the
voucher, as the pledge was not in direct contact with the
registrar for bootstrapping.  Therefore, a new "agent-proximity"
assertion value is necessary for distinguishing assertions the
MASA can state.
It would be inaccurate for the voucher-request and voucher-
response to use an assertion with value "proximity" in the
voucher, as the pledge was not in direct contact with the
registrar for bootstrapping.  Therefore, a new "agent-proximity"
assertion value is necessary for distinguishing assertions the
MASA can state.
POI: provides data-origin authentication of a data object, e.g., a
voucher request or an enrollment request, utilizing an existing
IDevID.  Certificate updates may utilize the certificate that is
to be updated.
POI: provides data-origin authentication of a data object, e.g., a
voucher-request or an enrollment-request, utilizing an existing
IDevID.  Certificate updates may utilize the certificate that is
to be updated.
Voucher requests and responses as used in RFC8995 already provide
both, POP and POI, through a digital signature to protect the
integrity of the voucher, while the corresponding signing
certificate contains the identity of the signer.
Voucher-requests and -responses as used in RFC8995 already provide
both, POP and POI, through a digital signature to protect the
integrity of the voucher, while the corresponding signing
certificate contains the identity of the signer.
For BRSKI with pledge in responder mode, the base system architecture
defined in BRSKI RFC8995 is enhanced to facilitate the new use cases
in which the pledge acts as server.  The pledge-responder-mode allows
delegated bootstrapping using a registrar-agent instead of a direct
connection between the pledge and the domain registrar.
For BRSKI with pledge in responder mode, the base system architecture
defined in BRSKI RFC8995 is enhanced to facilitate the 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.
To support mutual trust establishment between the domain registrar
and pledges not directly connected to the customer site/domain, this
document specifies the exchange of authenticated self-contained
objects (the voucher request/response as known from BRSKI and the
enrollment request/response as introduced by BRSKI-PRM) with the help
of a registrar-agent.
To support mutual trust establishment between the domain registrar
and pledges not directly connected to the customer site/domain, this
document specifies the exchange of authenticated self-contained
objects (the voucher-request/response as known from BRSKI and the
enrollment-request/response as introduced by BRSKI-PRM) with the help
of a registrar-agent.
uses existing endpoints where the required functionality is
provided.
enhances existing endpoints with new supported media types, e.g.,
for JWS voucher.
The registrar-agent MAY provide additional data to the pledge
in the context of the voucher triggering request, that the
pledge includes into the PVR.  This allows the registrar to
identify, with which registrar-agent the pledge was in contact.
Order of exchanges in the call flow may be different as the
registrar-agent collects both, PVR and PER, at once and
provides them to the registrar.  This approach is used in order
to allow for bulk bootstrapping of several devices in a single
pass through a new site by the commissioning personnel.
The registrar-agent MAY provide additional data to the pledge
in the context of the voucher-request trigger, which the pledge
includes into the PVR.  This allows the registrar to identify,
with which registrar-agent the pledge was in contact.
Order of exchanges in the call flow may be different as the
registrar-agent collects both, PVR and PER, at once and
provides them to the registrar.  This enables bulk
bootstrapping of several devices.
The registrar-agent as a new component provides connectivity between
the pledge and the domain registrar.  It facilitates the exchange of
data between the pledge and the domain registrar, which are the
voucher request/response, the enrollment request/response, as well as
related telemetry and status information.
The registrar-agent as a new component provides connectivity between
the pledge and the domain registrar.  It facilitates the exchange of
data between the pledge and the domain registrar, which are the
voucher-request/response, the enrollment-request/response, as well as
related telemetry and status information.
Pledges MAY support both initiator or responder mode.
A pledge in initiator mode should listen for announcement messages as
described in RFC8995.  Upon discovery of a potential registrar, it
initiates the bootstrapping to that registrar.  At the same time (so
as to avoid the Slowloris-attack described in RFC8995), it SHOULD
also respond to the triggers for responder mode described in this
document.
Once a pledge with combined functionality has been bootstrapped, it
MAY act as client for enrollment of further certificates needed,
e.g., using the enrollment protocol of choice.  If it still acts as
server, the defined BRSKI-PRM endpoints to trigger a pledge
enrollment-request (PER) or to provide an enrollment-response can be
used for further certificates.
The pledge SHOULD include this Content-Type header field indicating
the included media type for the PVR.  Note that this is also an
indication regarding the acceptable format of the voucher response.
This format is included by the registrar as described in
exchanges_uc2_2.
The pledge SHOULD include this Content-Type header field indicating
the included media type for the PVR.  Note that this is also an
indication regarding the acceptable format of the voucher-response.
This format is included by the registrar as described in
exchanges_uc2_2.
Upon receiving the enrollment-trigger, the pledge SHALL construct the
PER as authenticated self-contained object.  The CSR already assures
POP of the private key corresponding to the contained public key.  In
addition, based on the additional signature using the IDevID, POI is
provided.  Here, a JOSE object is being created in which the body
utilizes the YANG module ietf-ztp-types with the grouping for csr-
grouping for the CSR as defined in I-D.ietf-netconf-sztp-csr.
Upon receiving the enrollment trigger, the pledge SHALL construct the
PER as authenticated self-contained object.  The CSR already assures
POP of the private key corresponding to the contained public key.  In
addition, based on the additional signature using the IDevID, POI is
provided.  Here, a JOSE object is being created in which the body
utilizes the YANG module ietf-ztp-types with the grouping for csr-
grouping for the CSR as defined in I-D.ietf-netconf-sztp-csr.
Depending on the capability of the pledge, it constructs the
enrollment request (PER) as plain PKCS#10.  Note, the focus in this
use case is placed on PKCS#10 as PKCS#10 can be transmitted in
different enrollment protocols in the infrastructure like EST, CMP,
CMS, and SCEP.  If the pledge has already implemented an enrollment
protocol, it may leverage that functionality for the creation of the
CSR.  Note, I-D.ietf-netconf-sztp-csr also allows for inclusion of
certification requests in different formats used by CMP or CMC.
Depending on the capability of the pledge, it constructs the pledge
enrollment-request (PER) as plain PKCS#10.  Note, the focus in this
use case is placed on PKCS#10 as PKCS#10 can be transmitted in
different enrollment protocols in the infrastructure like EST, CMP,
CMS, and SCEP.  If the pledge has already implemented an enrollment
protocol, it may leverage that functionality for the creation of the
CSR.  Note, I-D.ietf-netconf-sztp-csr also allows for inclusion of
certification requests in different formats used by CMP or CMC.
This signature provides POP of the private key corresponding to the
registrar EE certificate the pledge received in the trigger for the
PVR (see pavrt).  The registrar MUST use the same registrar EE
credentials used for authentication in the TLS handshake to
authenticate towards the registrar-agent.  This ensures that the same
registrar EE certificate can be used to verify the signature as
transmitted in the voucher request as also transferred in the PVR in
the "agent-provided-proximity-registrar-cert".  MASA-REG-vr below
provides an example of the voucher with two signatures.
This signature provides POP of the private key corresponding to the
registrar EE certificate the pledge received in the trigger for the
PVR (see pavrt).  The registrar MUST use the same registrar EE
credentials used for authentication in the TLS handshake to
authenticate towards the registrar-agent.  This ensures that the same
registrar EE certificate can be used to verify the signature as
transmitted in the voucher-request as also transferred in the PVR in
the "agent-provided-proximity-registrar-cert".  MASA-REG-vr below
provides an example of the voucher with two signatures.
If both succeed, the registrar utilizes the PKCS#10 request
contained in the JWS object body as "P10" parameter of "ietf-sztp-
csr:csr" for further processing of the enrollment request with the
corresponding domain CA.  It creates a registrar-enrollment-
request (RER) by utilizing the protocol expected by the domain CA.
The domain registrar may either directly forward the provided
PKCS#10 request to the CA or provide additional information about
attributes to be included by the CA into the requested LDevID
certificate.  The approach of sending this information to the CA
depends on the utilized certificate management protocol between
the RA and the CA and is out of scope for this document.
If both succeed, the registrar utilizes the PKCS#10 request
contained in the JWS object body as "P10" parameter of "ietf-sztp-
csr:csr" for further processing of the enrollment-request with the
corresponding domain CA.  It creates a registrar enrollment-
request (RER) by utilizing the protocol expected by the domain CA.
The domain registrar may either directly forward the provided
PKCS#10 request to the CA or provide additional information about
attributes to be included by the CA into the requested LDevID
certificate.  The approach of sending this information to the CA
depends on the utilized certificate management protocol between
the RA and the CA and is out of scope for this document.
"enroll-error": Pledge enrollment response processing terminated
with error.  Additional information may be provided in the reason
or reason-context.  The pledge signs the response message using
its IDevID(Pledge).
"enroll-error": Pledge enrollment-response processing terminated
with error.  Additional information may be provided in the reason
or reason-context.  The pledge signs the response message using
its IDevID(Pledge).
A DoS attack with a faked registrar-agent may block the bootstrapping
of the pledge due to state creation 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, or a
single onboarding state may expire after a certain time.
A DoS attack with a faked registrar-agent may block the bootstrapping
of the pledge due to state creation 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, or a
single onboarding state may expire after a certain time.