[Anima] Reply3, Was: Re: Sheng/Robert/*: Re: Result//Re: WGLC for draft-ietf-anima-brski-prm-06, ends Feb. 15th, 2023

["Werner, Thomas" <[e-mail]>]

Hello Toerless,

thanks for your review and feedback, we finally managed to address your comments.
Low hanging fruits are done immediately, for other dedicated issues (https://github.com/anima-wg/anima-brski-prm/issues #94-#117) are created. (find details below inline: “• TW:”)

Best regards
Thomas

Von: Toerless Eckert <[e-mail]>
Datum: Dienstag, 28. Februar 2023 um 07:44
An: Sheng Jiang <[e-mail]>, [e-mail] <[e-mail]>
Cc: anima <[e-mail]>, anima-chairs <[e-mail]>, draft-ietf-anima-brski-prm <[e-mail]>, ietf <[e-mail]>
Betreff: Re: Sheng/Robert/*: Re: [Anima] Result//Re: WGLC for draft-ietf-anima-brski-prm-06, ends Feb. 15th, 2023

This is the second and final set of review feedbacks for draft-ietf-anima-brski-prm-06,
sorry for the long time it took.

I am continuing after where i stopped in the first review.

[major]

I am worried about the non-support for the mechanisms of CSRattr in this spec and
would like to see that functionality for this gets added. In BRSKI, support for
CSRattr, and hence the inclusion of Registrar determined attributes into the CSR
of the pledge is mandatory to support, and just because pledges are in PRM does
not seem to be a good enough reason for me to suspect that we could be successful
in the same breaths of flexible secure domain deployments without similar support.

I would like to request/propose to solve this issue through two complementary
options:

a) CSR attr in PER trigger

Do: The PER trigger messages agent-signed data should be extended to include an optional
field that can be filled with a Content-Transfer-Encoding of "base64" [RFC2045] encoded
CsrAttr structure according to RFC7030 and clarified by I-D.ietf-lamps-rfc7030-csrattrs.
Unfortunately, i think the inclusion of this data may make it prudent to also sign
the PER trigger then in the same fashion as the PVR trigger is signed. So maybe
this means to define the following into section 6.1.3:

   # The PER in General JWS Serialization syntax
   {
     "payload": "BASE64URL(ietf-pledge-enrolment-request:prm")",
     "signatures": [
       {
         "protected": "BASE64URL(UTF8(JWS Protected Header))",
         "signature": "base64encodedvalue=="
       }
     ]
   }

   # Decoded Payload "ietf-pledge-enrolment-request:prm" Representation
     in JSON syntax
   "ietf-pledge-enrolment-request:prm": {
      "enroll-type" : "enroll-generic-cert",
      "csr-attributes": "base64encodedvalue==",
   }

   # Decoded "JWS Protected Header" Representation in JSON syntax
   {
       "alg": "ES256",
       "x5c": [
         "base64encodedvalue==",
         "base64encodedvalue=="
       ],
       "typ": "per-trigger-jws+json"
   }

Write: The optional "cs-attributes" field of the PER trigger message
is intended to include those CSR attributes according to [EST] as clarified
by I-D.ietf-lamps-rfc7030-csrattrs, that can be known by the registrar-agent
before authenticating the pledge. This can includes attributes which are
common across the domain such as, such as allowed type(s) and length(s)
of the public key of the pledge. Attributes depending on the pledge or its
identity can be included as well, as long as the registrar-agent can be
made to know them. Mechanisms for how the registrar-agent can learn these
attributes are out-of-scope in this document but expected to use the same
or derived mechanisms to those by which the registrar-agent may learn the
list of pledges serial-number to attempt to enroll.

And in 6.1.4 write:

Thes "csr-attributes" of the PER trigger MUST be handled by the pledge in
forming the PER CSR ("p10-csr") according to [EST], Section 4.5.2 and
clarified by I-D.ietf-lamps.rfc7030-csrattrs.

b) Overriding and extending CSR attributes

The following text should go in an appropriate section, not clear which one:

When using BRSKI-PRM, additional protocol roundtrips between pledge, registrar-agent
and registrar beyond the two specified in this document are prohibitive because
BRSKI-PRM is optimized for the case where the registrar agent needs to physically
move between connectivity to the pledge and connectivity to the registar.

In BRSKI, pledge specific CSR attributes can be determined after successful mutual
authentication between pledge and registar - including the existance/creation of a voucher
for the pledge through the MASA. For example, in [RFC8994], the registrar
(or a backend server that is consulted by the registar) can determine the exact details
of the AcpNodeName attribute after authentication of the pledge and applying policy
against the type (derived from the serial-number) and location of the pledge.
This AcpNodeName incurs allocation of an IPv6 address for the pledge which if
done before acceptance of the pledge into the domain (in conjunction with issuance of
a a voucher) could at best be tentative and might need to be undone later, and at worsti
it could be a new undesirable attack vector.

If CSR attributes such as these are needed to be included in the pledges LDevID
when using BRSKI-PRM, then the registrar SHOULD add/override the attributes provided
by the pledge in its PER and use a protocol such as full Certificate Management over CMS (CMC)
towards the CA, which provides mechanisms to override CSR Attributes. See also [BRSKI], Section 5.9.2.

---
overlooked fixes in first part:

1280       IDevID, proof of identity is provided.  Here, a JOSE object is being
1281       created in which the body utilizes the YANG module ietf-ztp-types
1282       with the grouping for csr-grouping for the CSR as defined in
1283       [I-D.ietf-netconf-sztp-csr].

1343       The body of the pledge enrollment-request SHOULD contain a P10
1344       parameter (for PKCS#10) as defined for ietf-ztp-types:p10-csr in
1345       [I-D.ietf-netconf-sztp-csr]:
1347       *  P10: contains the base64-encoded PKCS#10 of the pledge.

1343       The body of the pledge enrollment-request SHOULD contain a P10
1344       parameter (for PKCS#10) as defined for ietf-ztp-types:p10-csr in
1345       [I-D.ietf-netconf-sztp-csr]:
1347       *  P10: contains the base64-encoded PKCS#10 of the pledge.

[major]

I find the text sections referring to I-D.ietf-netconf-sztp-csr confusing and
i fear it is misleading:

The use of "ietf-ztp-types" in the PER JSON format, and the text saying this
is from I-D.ietf-netconf-sztp-csr makes it sound as if one could or
should be allowed to also form a PER JSON using any of the other
options defined in the I-D.ietf-netconf-sztp-csr YANG module. But its not
clear whether that is actually intended. It is also not clear how would
format the JSON, because the netconf draft does not specify any JSON, and
as far as i can tell, there is no well defined mapping from YANG to JSON
that would ensure that two independent implementations trying to do this
would be interoperable - or am i wrong ? Aka: If two implementation
(pledge, registrar/-agent) tried to use "cmp-csr" instead of "p10-csr".

I also fear that by claiming to inherit/refer to the netconf drafts specification,
we do incur more formal spec requirements (i may easily be wrong).

In any case, i think this document would be a lot easier if formal must/YANG
references to the netconf draft would be removed, and this draft would just
specify what is in the "p10-csr" JSON element standalone. Which i think
it already does mostly. One can still add a sentence that this definition
is in "the spirit" of what is also defined in the netconf draft (with reference).

Aka: The introduction and use of "ietf-ztp-types" on line 1364 does not
seem to be related to any registry, so it seems we do not need to do any
reference work to any registry or any netconf draft section, aka: this is
all about removing unnecessary text about the netconf text to make what
the draft specifies standaline, even if it is cloning ideas from the network
draft (like that string name).

Aka: no spec changes needed here.

I would like to see the text avoid rhe abbreviation P10 though, and just
refer to PKCS#10 and "p10-csr" to avoid introducing redundant terms/abbreviations.

[major - or not?]

I find the use or non-use of the media-types confusing. For example, there
is no "typ" field in the PER JWS header, and the media-types that this
draft does suggest/use feel like being all over the place.

I think PRM messages would be less confusing if they all used JWS
(i am making a point below to also do this for the PER trigger), and
all had media-types that would allow to identify each message,
and where all consistent. something like application/brski-<message-type>-jose+json
where message-type could be pvrt (pledge voucher request trigger),
pvr (pledge-voucher-request), rpvr (registrar pledge-voucher-request) - and
so on, for all of them.

Yes, i can not make a real strong functional argument for this except
maybe that at some point there would be a benefit that all these messages
would much better self-identify if they'd be on disk even without HTTP
header.

---
Following are inline comments/discusses.
---

1842       The Content-Type header of PER is: application/jose+json.

As top posted [major] discusses, i would suggest something like
"application/prm+jose+json"

1844       This is a deviation from the Content-Type header values used in
1845       [RFC7030] and results in additional processing at the domain
1846       registrar (as EST server).

1846       Note, the registrar is already aware that
1847       the bootstrapping is performed in a pledge-responder-mode due to the
1848       use of the LDevID(RegAgt) certificate for TLS and the provided PVR as
1849       JSON-in-JWS object.

As mentioned in before, i would like to remove the reliance on the certificate used
to authenticate the pledge, because it is unnecessary. Like in EST and BRSKI,
the purpose of a request should always only be deduced from operation path and
if necessary by media-type. So pls. remove.

1851       *  If the registrar receives a PER with Content-Type header:
1852          application/jose+json, it MUST verify the wrapping signature using
                         ^prm+
1853          the certificate indicated in the JOSE header.

Please specify which cert is used (pledge or agent).

1855       *  The registrar verifies that the pledge's certificate (here
1856          IDevID), carried in "x5c" header field, is accepted to join the
1857          domain

s/is accepted/is authorized/

1857          after successful validation of the PVR.

I would suggest to remove this. This is confusing, because it can be interpreted
to imply that the PVR/voucher have some impact on whether or not the domain
authorizes the pledge. Which it logically does not have (that would just be
an internal implementation optimization on the registrar, and would be an
additionals security issue).


1859       *  If both succeed, the registrar utilizes the PKCS#10 request

s/both succeed/this succeeds/

1860          contained in the JWS object body as "P10" parameter of "ietf-sztp-
                                                                    ^ the

s/"P10"/the "p10-csr"/

1861          csr:csr" for further processing of the enrollment request with the
1862          corresponding domain CA.  It creates a registrar-enrollment-
1863          request (RER) by utilizing the protocol expected by the domain CA.

1864          The domain registrar may either directly forward the provided
1865          PKCS#10 request to the CA or provide additional information about
1866          attributes to be included by the CA into the requested LDevID
1867          certificate.  The approach of sending this information to the CA
1868          depends on the utilized certificate management protocol between
1869          the RA and the CA and is out of scope for this document.

This text from 1864-1869 would be good to replace with the proposed text
for "Overriding and extending CSR attributes" i wrote earlier, except that
it is probably better to have here just a forward pointer and write this
in a later section about registrar behavior.

1871       The registrar-agent SHALL send the PER to the registrar by HTTP POST
1872       to the endpoint: "/.well-known/brski/requestenroll"

1874       The registrar SHOULD respond with an HTTP 200 OK in the success case
1875       or fail with HTTP 4xx/5xx status codes as defined by the HTTP
1876       standard.

replace "HTTP standard" with appropriate RFC reference.

1878       A successful interaction with the domain CA will result in a pledge
1879       LDevID certificate, which is then forwarded by the registrar to the

s/forwarded/returned/

1880       registrar-agent using the Content-Type header: application/
1881       pkcs7-mime.
                     ^ in response to the PER.

[major]

If retrieval of the CA certs is optional, then care must be taken that
the pkcs7-mime pledge certificate can be authenticated against the pinned
domain certificate from the voucher alone. This may not be the case,
for example if the pinned-domain cert is just the registrar cert.

This would be good to write down, unless:

In general, i would prefer if the cert repsonse is also signed
via JWS+JSON with the registrar-cert. This would also better mimic
BRSKI where the pledge does trust the cert because of the voucher
authenticated TLS connection. This wold make delivery of CA-certs completely
optional to get successfully an initial cert.

[major]

This step involves actual authorization of the pledge to be
enrolled (remember the voucher is really just to make the pledge trust the
domain and some initial invitation, but not a finalized invite for the
certificate - for example the actual issuance of a certificate could incur
additional checks, such as whether the device was encountered in the
correct location in the network designated for it.

Long story short: This enrolment / reply may take some time. I think in BRSKI, we have
some text about HTTP "come back later" or similar replies instead of "fail".
It would be helpfull if we would also be able to make BRSKI-PRM work in a way where the registrar-agent
would be able to repeat requests and specify whatever is easy to say about
these "wait" or "come back later" HTTP replies (ENOTIME to find this text right now
in BRSKI).

1883    6.2.7.  Request Wrapped-CA-certificate(s) (Registrar-Agent to Registrar)
                                   ^
pick upper or lower, but make it consistent troughout the document.

1885       As the pledge will verify it own certificate LDevID certificate when
                                       ^s

1886       received, it also needs the corresponding CA certificates.  This is

Confusing - this makes it sound as if the corresponding CA certificates are
required so the pledge can verify the LDevID. But this is not really necessary.
The pledge simply trusts the LDevID in BRSKI/EST because it is received over
the TLS connection that was authenticated by the voucher. The CA certificates
are only needed so the pledge can authenticate peers. One can create use-cases
where the pledge for example only needs to originate signed messages but not
authenticate peers, and in which it would therefore not need to receive CA
certificates.

1886       This is
1887       done in EST [RFC7030] using the "/.well-known/est/cacerts" endpoint,
1888       which provides the CA certificates over a TLS protected connection.
1889       BRSKI-PRM requires a signature wrapped CA certificate object, to
1890       avoid that the pledge can be provided with arbitrary CA certificates
1891       in an authorized way.  The registrar signed CA certificate object
1892       will allow the pledge to verify the authorization to install the
1893       received CA certificate(s).  As the CA certificate(s) are provided to
1894       the pledge after the voucher, the pledge has the required information
1895       (the domain certificate) to verify the wrapped CA certificate object.

Note: it may be useful to create the reference to RFC7030 so it will read [EST],
that way one avoids duplication like "EST [RFC7030]". Same for other commonly
used words in the draft, like [HTTP].

Suggest to replace 1885 - 1895 with:

In [EST], CA certificate(s) returned by the registrar to the pledge via
the /cacerts operation path are authenticated via the TLS connection to
the pledge which is authenticated by the pledge through the voucheer.
In BRSKI-PRM, this is achieved by the registar-agent retrieving the
CA certificates from the registrar wrapped with a registrar signature.

1897       To support registrar-agents requesting a signature wrapped CA
1898       certificate(s) object, a new endpoint for BRSKI-PRM is defined on the
1899       registrar: "/.well-known/brski/wrappedcacerts"

1901       The registrar-agent SHALL requests the EST CA trust anchor database
1902       information (in form of CA certificates) by HTTP GET.

This section so far has no context. Suggest to write that the registrar-agent
will request the wrapped CA certificates after the certificate request/reply with
the registrar. And i guess we can say "successful" (aka: only when registrar
has given registrar-agent a cert for the pledge).

[major - but weird]
there is a weird set of use cases i can imagine, where the pledge might not (yet)
receive a certificate, but just the trust-anchors. I don't think we ever fully
considered this in BRSKI explicitly (but it could work there), but in BRSKI-PRM
it may be more useful, because the trust-anchors may suffice for a pledge to do all or part of its job,
such as listenening and trusting other messages from the domain. And avoid
having to rely/cache the voucher if/when it is instructed to take a certificate
from the domain later.

but if you don't immediately see value in it, then ignore this thought.

1904       The Content-Type header of the response SHALL be: application/
1905       jose+json.

1907       This is a deviation from the Content-Type header values used in EST
1908       [RFC7030] and results in additional processing at the domain
                    ^ Section 4.1.3
1909       registrar (as EST server).  The additional processing is to sign the
1910       CA certificate(s) information using the registrar EE credentials.
... and encode it as JSON+JWS.

Also: why does this need to say "EE credentials" ? And is this not also wrong ?

Aka: Lets assume the voucher had just one (root) CA certificate, but the registrar
itself is enrolled via an intermediate CA. In this case the signature would not
only be the EE certicate of the registrar, but would also need to include the
intermediate CA certificate - otherwise the pledge could not authenticate the
CA certs.

Something like "The registrar certificate information included in the JWS header
needs to suffice to be authenticated against the pinned certificate in the voucher for the
pledge to authenticate the message. For example, it is not sufficient to include the
registrars EE certificate if it was signed by an intermediate CA but the voucher
has only the root certificate of the domain pinned. In this case, the JWS certificate
information also needs to contain the intermediate certificate."

1911       This results in a signed CA certificate(s) object (JSON-in-JWS), the
1912       CA certificates are provided as base64 encoded "x5b" in the JWS
1913       payload.

1915       # The CA certificates data with additional registrar signature in
1916         General JWS Serialization syntax
1917       {
1918         "payload": "BASE64URL(certs)",
1919         "signatures": [
1920           {
1921             "protected": "BASE64URL(UTF8(JWS Protected Header))",

Curious: Why do you use some "nice" textual string here instead of what looks
like a formal registered name in the other JWS+JSON headers. I would actually
prefer to reuse exactly this string "JWS Protected Header" in all JWS+JSON
messages in this document given how i think we never want to demultiplex/decide
anything  based on this field, but only based on the media-type, ... or do we ??

(that would eliminate confusion what the impact of those "looks like registered name" here is...).

1922             "signature": "base64encodedvalue=="
1923           }
1924         ]
1925       }

1927       # Decoded payload "certs" representation in JSON syntax
1928       {
1929         "x5b": [
1930           "base64encodedvalue==",
1931           "base64encodedvalue=="
1932         ]
1933       }

[major]

There is no "x5b" in RFC7515 and you have no explanation what the meaning of
those two base64 encoded values is. Could/should this not simply be "cert-pkcs7-mime"
with just one base64 encoded value (the pkcs7-mime base64 encoded CA certificate chain ?)

In any case - needs to be explained, and unless there is a good reason to use a
non-descriptive "x5b" term, i'd prefer a more prescriptive name.

1935       # Decoded "JWS Protected Header" representation in JSON syntax
1936       {
1937         "alg": "ES256",
1938         "x5c": [
1939           "base64encodedvalue==",
1940           "base64encodedvalue=="
1941         ]
1942       }

1944              Figure 13: Representation of CA certificate(s) data with
1945                           additional registrar signature

1947    6.3.  Response Object Supply by Registrar-Agent to Pledge

Response Objects supplied by the Registrar-Agent to the Pledge
--> TW:  accepted changed: “Response Objects supplied by the Registrar-Agent to the Pledge”


1949       It is assumed that the registrar-agent already obtained the
1950       bootstrapping response objects from the domain registrar and can
1951       supply them to the pledge:

1953       *  voucher-response - Voucher (from MASA via Registrar)

1955       *  wrapped-CA-certificate(s)-response - CA certificates
                                                                 ^(s)

1957       *  enrollment-response - LDevID(Pledge) certificate (from CA via
1958          Registrar)

1960       The registrar-agent will re-connect to the pledge.  To contact the

To deliver these response object, the registrar-agent will ...
--> TW: changed: “To deliver these response objects, the registrar-agent will re-connect to the pledge.”

1961       pledge, it may either discover the pledge as described in
1962       Section 5.4.2 or use stored information from the first contact with
1963       the pledge.

1965       Preconditions in addition to Section 6.2:

1967       *  Registrar-agent: possesses voucher and LDevID certificate and

s/possesses/has obtained/

(we have this special meaning for posesession such as for proof of possession,
 so i'd avoid it unless it's used in the context of something where you
 can create proof of possession).

--> TW: created issue #94

1968          optionally CA certificates.

Its nice that you reconfirm "optionally" here, but from the text leading here,
i have seen no description as to who or how determines whether or not
the CA certificates will be made available to the plegde. Any explanation
would be nice (whereever it fits best).

--> TW: created issue #95


1970       +--------+                        +-----------+
1971       | Pledge |                        | Registrar-|
1972       |        |                        | Agent     |
1973       |        |                        | (RegAgt)  |
1974       +--------+                        +-----------+
1975           |                          [voucher and enrollment]
1976           |                          [responses available]
1977           |                                   |
1978           |<------- supply voucher -----------|
1979           |                                   |
1980           |--------- voucher status --------->| - store
1981           |                                   |   pledge voucher status
1982           |<----- supply CA certificates  ----|
1983           |                                   |
1984           |<--- supply enrollment response ---|
1985           |                                   |
1986           |--------- enroll status ---------->| - store
1987           |                                   |   pledge enroll status
1988           |<--- supply CAcerts (optional) ----|
1989           |                                   |

1991            Figure 14: Responses and status handling between pledge and
1992                                  registrar-agent


Nice picture, but now i am confused what "supply CA certificates" is
versus "supply CAcerts (optional)" (cold read: this concern is written
without knowing whats written further down. But also the tree bullet
points above in this section didn't distinguish between
"CA certificates" and "CAcerts (optional)".

--> TW: created issue #96


1994       The content of the response objects is defined by the voucher
1995       [RFC8366] and the certificate [RFC5280].

I think this sentence is misleading here given how we know from prior text
in this document, that the format is much more specific, such as JWS+JSON
voucher and pkcs#7-mime certificate.

If this is meant as a more general excurse into how one could potentially
use all type of encodings in variations of a PRM which are not specified
in this document, then thats text for an appendix or something much further below,
but not here. Aka: delete sentence or make references specific to the actual
formats specified in this spec.

--> TW: created issue #97


1997       The registrar-agent provides the information via distinct pledge
1998       endpoints as following.

2000    6.3.1.  Pledge: Voucher Response Processing

2002       The registrar-agent SHALL send the voucher-response to the pledge by
2003       HTTP POST to the endpoint: "/.well-known/brski/sv".

2005       The registrar-agent voucher-response Content-Type header is
2006       application/voucher-jws+json and contains the voucher as provided by
2007       the MASA.  An example is given in Figure 11 for a MASA signed voucher
2008       and in Figure 12 for the voucher with the additional signature of the
2009       registrar.

The figure numbers 11/12 don't seem to be correct.

--> TW: Done, already addressed in latest version


2011       A nonceless voucher may be accepted as in [RFC8995] and may be
2012       allowed by a manufacture's pledge implementation.

Can a pledge that knows the voucher will be nonceless not include the
nonce in the JWS+JSON PVR message ? In that case it would be good to
mention thi earlier in the document where you specify the none message
element (e.g.: add (optional)).

--> TW: created issue #98


2014       To perform the validation of multiple signatures on the voucher

s/multiple/the different/ ??

--> TW: changed “To perform the validation of several signatures on the voucher object, …”

2015       object, the pledge SHALL perform the signature verification in the
2016       following order:

2018       1.  Verify MASA signature as described in section 5.6.1 in [RFC8995]

... against pre-installed vendor trust anchors.

--> TW: changed “1. Verify MASA signature as described in Section 5.6.1 in {{RFC8995}}, against pre-installed manufacturer trust anchor (IDevID).”

2020       2.  Install trust anchor contained in the voucher ("pinned-domain-
2021           cert") provisionally

2023       3.  Verify registrar signature as described in section 5.6.1 in
2024           [RFC8995], but take the registrar certificate instead of the MASA
2025           certificate for the verification

2027       4.  Validate the registrar certificate received in the agent-
2028           provided-proximity-registrar-cert in the pledge-voucher-request
2029           trigger request (in the field "agent-provided-proximity-
2030           registrar-cert").

[major]

I think this is in the wrong order or miswritten. Step 3 can not verify a signature
from a certificate that was not verified in before, and i do not see that the
registrar certificate mentioned in step 3 was verified in before. Or is this
assumed to be the pinned-domain-cert mentioned in step 2, and the text just
uses different words to make it impossible to match up terms ?

But be that as it may: i really don't know what steps 3 and 4 are good for.
I think they are not needed, but later when pledge-certificate and CA-certs
are received will those objects need to be authenticated against the
signature of the registrar, and that requires to first authenticate the
registrar certificate against the pinned-domain-cert from step 3.

If 3 and 4 can go, that also means that step 2 is not provisional, but
would per permanent, unless the pinned domain cert is later superceeded by
the CA certs.

--> TW: created issue #99


2032       If all steps stated above have been performed successfully, the
2033       pledge SHALL terminate the "PROVISIONAL accept" state for the domain
2034       trust anchor and the registrar EE certificate.

2036       If an error occurs during the verification and validation of the
2037       voucher, this SHALL be reported in the reason field of the pledge
2038       voucher status.

2040    6.3.2.  Pledge: Voucher Status Telemetry

2042       After voucher verification and validation the pledge MUST reply with
2043       a status telemetry message as defined in section 5.7 of [RFC8995].
2044       The pledge generates the voucher-status and provides it as signed
2045       JSON-in-JWS object in response to the registrar-agent.

2047       The response has the Content-Type application/jose+json and is signed
2048       using the IDevID of the pledge as shown in Figure 15.  As the reason
2049       field is optional (see [RFC8995]), it MAY be omitted in case of
2050       success.

2052       # The "pledge-voucher-status" telemetry in general JWS
2053         serialization syntax
2054       {
2055         "payload": "BASE64URL(pledge-voucher-status)",
2056         "signatures": [
2057           {
2058             "protected": "BASE64URL(UTF8(JWS Protected Header))",
2059             "signature": "base64encodedvalue=="
2060           }
2061         ]
2062       }

2064       # Decoded payload "pledge-voucher-status" representation in JSON
2065         syntax
2066       {
2067         "version": 1,
2068         "status": true,
2069         "reason": "Voucher successfully processed",
2070         "reason-context": {
2071           "additional": "JSON"
2072         }
2073       }

2075       # Decoded "JWS Protected Header" representation in JSON syntax
2076       {
2077         "alg": "ES256",
2078         "x5c": [
2079           "base64encodedvalue==",
2080           "base64encodedvalue=="
2081         ]
2082       }

2084            Figure 15: Representation of pledge voucher status telemetry

A second picture with an excerpt of a useful error message would be great.
( aka: only showing the dedodec payload.)

"failed to authenticate MASA certificate because it starts in the future (1/1/2023). Current date: 1/1/1970"
(typical local clock failure on pledges ;-))

--> TW: created issue #100


[major]

What happens if there is an interruption in the process, and the registrar-agent
does not get to record on disk the successful enrolment ? how does it restart ?
It could attempt to re-send the same voucher, but then it should also get
again success status instead of some errror it can't interpret "you already
gave me the voucher 5 minutes ago".

Aka: would be good to ensure that the sending of voucher and status can repeated
an result in the same positive status.

--> TW: created issue #101


2086    6.3.3.  Pledge: Wrapped-CA-Certificate(s) Processing

2088       The registrar-agent SHALL provide the set of CA certificates
2089       requested from the registrar to the pledge by HTTP POST to the
2090       endpoint: "/.well-known/brski/cc".

2092       As the CA certificate provisioning is crucial from a security
2093       perspective, this provisioning SHALL only be done, if the voucher-
2094       response has been successfully processed by pledge.

Well.... i don't think this is good text. The registrar-agent can always
try to provide CA certificates if it wants to enroll the pledge. Its the
pledge that would reject this if the voucher was not previously successfully
accepted by the pledge. Aka: there is no harm in the registrar-agent trying,
but if you accept the consideration from my major after line 2084, then one
could write that the registrar-agent SHOULD only send  the CA-certificates
(like the following pledge certificate) after having received a successful
voucher telemetry from the pledge.

--> TW: created issue #102


2096       The supply CA certificates message has the Content-Type application/

s/supply//
s/the/a/

--> TW: changed: “The CA certificates message has the Content-Type…”

2097       jose+json and is signed using the credential of the registrar pledge
2098       as shown in Figure 13.

"registrar pledge" ?

--> TW: changed: „…using the credential of the registrar as shown in … “

2100       The CA certificates are provided as base64 encoded "x5b".  The pledge
2101       SHALL install the received CA certificates as trust anchor after
2102       successful verification of the registrar's signature.

[major]

This i think is where to elaborate on the 5 verification steps:
- first authenticat registrar certificate against the pinned-domain-cert
- then authenticate the message signature.

-->  TW: created issue #103

2104       The following 4xx client error codes SHOULD be used by the pledge:

2106       *  403 Forbidden: if the validation of the wrapping signature or
2107          another security check fails.

2109       *  415 Unsupported Media Type: if the Content-Type of the request is
2110          in an unknown or unsupported format.

2112       *  400 Bad Request: if the pledge detects errors in the encoding of
2113          the payload.

2115    6.3.4.  Pledge: Enrollment Response Processing

2117       The registrar-agent SHALL send the enroll-response to the pledge by
2118       HTTP POST to the endpoint: "/.well-known/brski/se".

2120       The registrar-agent enroll-response Content-Type header, when using
2121       EST [RFC7030] as enrollment protocol between the registrar-agent and
2122       the infrastructure is: application/pkcs7-mime.  Note: It only
2123       contains the LDevID certificate for the pledge, not the certificate
2124       chain.

I think it is factually wrong that a pkcs7-mime does not contain a certificate chain.
AFAIK it can contain perfectly well not only the signing certificate but also
a chain of intermediate certificate in case those need to be supplied by the
owner of the certificate later knowing that the distributed trust-anchors are not
the signing certificates.

[major]

See my above comment about this only being sufficient if there was CA certificates
given to the pledge or the pinned-domain-cert of the voucher containing the
certificate chain sufficient to authenticate the pledges certificate later.
So if you do not want to wrap the certificate respnse into a registrar
signature, then i think those conditions need to be described here.

-->  TW: created issue #104

2126       Upon reception, the pledge SHALL verify the received LDevID
2127       certificate.  The pledge SHALL generate the enroll status and provide
2128       it in the response to the registrar-agent.  If the verification of
2129       the LDevID certificate succeeds, the status SHALL be set to true,
2130       otherwise to FALSE.

In JSON i guess it's "true" and "false", so lets not invent additional ways to write the
same (TRUE, FALSE).

--> TW: changed „the status property SHALL be set to "status": true, otherwise to "status": false“


2132    6.3.5.  Pledge: Enrollment Status Telemetry

2134       The pledge MUST reply with a status telemetry message as defined in
2135       section 5.9.4 of [RFC8995].  As for the other objects, the enroll-
2136       status is signed and results in a JSON-in-JWS object.  If the pledge
2137       verified the received LDevID certificate successfully it SHALL sign
2138       the response using its new LDevID credentials as shown in Figure 16.
2139       In the failure case, the pledge SHALL use the available IDevID
2140       credentials.  As the reason field is optional, it MAY be omitted in
2141       case of success.

2143       The response has the Content-Type application/jose+json.

2145       # The "pledge-enroll-status" telemetry in General JWS Serialization
2146         syntax
2147       {
2148         "payload": "BASE64URL(pledge-enroll-status)",
2149         "signatures": [
2150           {
2151             "protected": "BASE64URL(UTF8(JWS Protected Header))",
2152             "signature": "base64encodedvalue=="
2153           }
2154         ]
2155       }

2157       # Decoded payload "pledge-enroll-status" representation in
2158         JSON syntax
2159       {
2160         "version": 1,
2161         "status": true,
2162         "reason": "Enrollment response successfully processed",
2163         "reason-context": {
2164           "additional": "JSON"
2165         }
2166       }

2168       # Decoded "JWS Protected Header" representation in JSON syntax
2169       {
2170         "alg": "ES256",
2171         "x5c": [
2172           "base64encodedvalue==",
2173           "base64encodedvalue=="
2174         ]
2175       }

2177            Figure 16: Representation of pledge enroll status telemetry

negative example (only payload) would again be a fine addition.

-->  TW: created issue #105


2179       Once the registrar-agent has collected the information, it can
2180       connect to the registrar to provide it with the status responses.

2182    6.3.6.  Telemetry Voucher Status and Enroll Status Handling (Registrar-
2183            Agent to Domain Registrar)

2185       The following description requires that the registrar-agent has
2186       collected the status information from the pledge.  It SHALL provide
2187       the status information to the registrar for further processing.


2189       Preconditions in addition to Section 6.2:

2191       *  Registrar-agent: possesses voucher status and enroll status from
2192          pledge.

2194       +-----------+        +-----------+   +--------+   +---------+
2195       | Registrar |        | Domain    |   | Domain |   | Vendor  |
2196       | Agent     |        | Registrar |   | CA     |   | Service |
2197       | RegAgt)   |        |  (JRC)    |   |        |   | (MASA)  |
2198       +-----------+        +-----------+   +--------+   +---------+
2199           |                      |              |   Internet |
2200       [voucher + enroll ]        |              |            |
2201       [status info available]    |              |            |
2202           |                      |              |            |
2203           |<------- mTLS ------->|              |            |
2204           |                      |              |            |
2205           |--- Voucher Status -->|              |            |
2206           |                      |--- req-device audit log-->|
2207           |                      |<---- device audit log ----|
2208           |              [verify audit log ]
2209           |                      |              |            |
2210           |--- Enroll Status --->|              |            |
2211           |                      |              |            |

2213                      Figure 17: Bootstrapping status handling

2215       The registrar-agent MUST provide the collected pledge voucher status
2216       to the registrar.  This status indicates if the pledge could process
2217       the voucher successfully or not.

2219       If the TLS connection to the registrar was closed, the registrar-

closed after...(insert maybe section).

--> TW: changed, see below …

2220       agent establishes a TLS connection with the registrar as stated in

establishes a new TLS connection
              ^^^
--> TW: changed „In case the TLS connection to the registrar is already closed, the registrar-agent opens a new TLS connection with the registrar as stated in“

2221       Section 6.2.

2223       The registrar-agent sends the pledge voucher status without
2224       modification to the registrar with an HTTP-over-TLS POST using the
2225       registrar endpoint "/.well-known/brski/voucher_status".  The Content-
2226       Type header is kept as application/jose+json as described in
2227       Figure 14 and depicted in the example in Figure 15.

[major]

So, in the first part of the review i was trying to suggest positive spin text
around all the complexity of introducing registar-agent authentication in
some messages, such as being able to track on the registrar and the backend
behind it, who (which registstrar-agent) was assisting he enrollment and
hence also likely co-checks for the pledge.

But when you simply pass through the telementry without including an
identity of the registar-agent, then this benefit goes out the door, and
we could rather remove all other registrar-agent signatures from the spec
because they serve no purpose other than to track somewhere who was
sending messages back and forth between pledge and registrar.

Aka: either have a scheme where all the steps taken can be traced back to
a registrar-agent (aka: put the plege-responses into a registrar-agent
signed container), or get rid of all the then unnecessary registrar-agent
signatures...

-->  TW: created issue #106


2229       The registrar SHALL verify the signature of the pledge voucher status
2230       and validate that it belongs to an accepted device in his domain

s/an/the/ ??

--> TW: changed: „…of the domain…“

2231       based on the contained "serial-number" in the IDevID certificate
2232       referenced in the header of the voucher status.

2234       According to [RFC8995] section 5.7, the registrar SHOULD respond with
2235       an HTTP 200 OK in the success case or fail with HTTP 4xx/5xx status
2236       codes as defined by the HTTP standard.  The registrar-agent may use
2237       the response to signal success / failure to the service technician
2238       operating the registrar agent.  Within the server logs the server
2239       SHOULD capture this telemetry information.

2241       The registrar SHOULD proceed with collecting and logging status
2242       information by requesting the MASA audit-log from the MASA service as
2243       described in section 5.8 of [RFC8995].

2245       The registrar-agent MUST provide the pledge's enroll status to the
2246       registrar.  The status indicates the pledge could process the enroll-
2247       response (certificate) and holds the corresponding private key.

2249       The registrar-agent sends the pledge enroll status without
2250       modification to the registrar with an HTTP-over-TLS POST using the
2251       registrar endpoint "/.well-known/brski/enrollstatus".  The Content-
2252       Type header is kept as application/jose+json as described in
2253       Figure 14 and depicted in the example in Figure 16.

2255       The registrar MUST verify the signature of the pledge enroll status.
2256       Also, the registrar SHALL validate that the pledge is an accepted

s/an/the/

--> TW: changed: „…of the domain…“

2257       device in his domain based on the contained product-serial-number in
2258       the LDevID certificate referenced in the header of the enroll status.
2259       The registrar SHOULD log this event.  In case the pledge enroll
2260       status indicates a failure, the pledge was unable to verify the
2261       received LDevID certificate and therefore signed the enroll status
2262       with its IDevID credential.  Note that the verification of a
2263       signature of the status information is an addition to the described
2264       handling in section 5.9.4 of [RFC8995].

... and is replacing the pledges IDevID TLS authentication in [RFC8995].

--> TW: changed: „Note that the signature verification of the status information is an addition to the described handling in Section 5.9.4 of {{RFC8995}}, and is replacing the pledges TLS client authentication by DevID credentials in [RFC8995].“


2266       According to [RFC8995] section 5.9.4, the registrar SHOULD respond
2267       with an HTTP 200 OK in the success case or fail with HTTP 4xx/5xx
2268       status codes as defined by the HTTP standard.  Based on the failure

2268       status codes as defined by the HTTP standard.  Based on the failure
2269       case the registrar MAY decide that for security reasons the pledge is
2270       not allowed to reside in the domain.  In this case the registrar MUST
2271       revoke the certificate.  The registrar-agent may use the response to
2272       signal success / failure to the service technician operating the
2273       registrar agent.  Within the server log the registrar SHOULD capture
2274       this telemetry information.

[major]

This part (2268-2274) seems to be new compared to rfc8995. If there is a reference
to this revocation after enrolment in rfc8995, please add. Otherwise it would
be great to add an example. For example, if the pledge failed to install the
certificate because of clock messup, this does not mean that the registrar
MUST revoke the certificate. it could as well end up for the technician
having to replace NVram battery on the pledge or the like and re-send the
voucher/certificate to the pledge.

Aka: i fail to come up with an idea for the decision for the pledge not being
allowed to reside in the domain after the registrar did previously happily
provde a cert to the registrar-agent for the pledge.

-->  TW: created issue #107


2276    6.4.  Request Pledge-Status by Registrar-Agent from Pledge

2278       The following assumes that a registrar-agent may need to query the
2279       status of a pledge.  This information may be useful to solve errors,
2280       when the pledge was not able to connect to the target domain during
2281       the bootstrapping.  The pledge MAY provide a dedicated endpoint to
2282       accept status-requests.

2284       Preconditions:

2286       *  Registrar-agent: possesses LDevID (RegAgt), list of serial numbers
2287          of pledges to be queried and a list of corresponding manufacturer
2288          trust anchors to be able to verify signatures performed with the
2289          IDevID credential.

2291       *  Pledge: may already possess domain credentials and LDevID(Pledge),
2292          or may not possess one or both of these.

2294       +--------+                     +-----------+
2295       | Pledge |                     | Registrar-|
2296       |        |                     | Agent     |
2297       |        |                     | (RegAgt)  |
2298       +--------+                     +-----------+
2299           |                                |
2300           |<--- pledge-status request -----|
2301           |                                |
2302           |---- pledge-status response --->|
2303           |                                |

2305        Figure 18: Pledge-status handling between registrar-agent and pledge

2307    6.4.1.  Pledge-Status - Trigger (Registrar-Agent to Pledge)

I don't think "trigger" is a good name here. It made sense when the
reply are "requests", but in this case it should be called (IMHO) a Pledge Status Request,
because it's answered by a response.
-->  TW: created issue #108


2309       The registrar-agent requests the pledge-status via HTTP POST on the
2310       defined pledge endpoint: "/.well-known/brski/ps"

2312       The registrar-agent Content-Type header for the pledge-status request
2313       is: application/jose+json.  It contains information on the requested
2314       status-type, the time and date the request is created, and the
2315       product serial-number of the pledge contacted as shown in Figure 19.
2316       The pledge-status request is signed by registrar-agent using the
2317       LDevID(RegAgt) credential.

2319       The following Concise Data Definition Language (CDDL) [RFC8610]
2320       explains the structure of the format for the pledge-status request.
2321       It is defined following the status telemetry definitions in BRSKI
2322       [RFC8995].  Consequently, format and semantics of pledge-status
2323       requests below are for version 1.  The version field is included to
2324       permit significant changes to the pledge-status request and response
2325       in the future.  A pledge or a registrar-agent that receives a pledge-
2326       status request with a version larger than it knows about SHOULD log
2327       the contents and alert a human.

Seems like a lot of replicated text from RFC8995. See if you can cut it down
to just reference and whatever is new here.
-->  TW: created issue #109


2329       <CODE BEGINS>
2330         status-request = {
2331             "version": uint,
2332             "created-on": tdate ttime,
2333             "serial-number": text,
2334             "status-type": text
2335         }
2336       <CODE ENDS>

2338                     Figure 19: CDDL for pledge-status request

Its a bit weird using formal CDDL here when the whole document so far
was inventing a lot of JSON/JWS+JSON messages without an equivalent CDDL
specification. I don't want to ask for additional formalistic spec stuff
in CDDL here, just wanted to note the inconsistency.

-->  TW: created issue #110


2340       The status-type defined for BRSKI-PRM is "bootstrap".  This indicates
2341       the pledge to provide current status information regarding the
2342       bootstrapping status (voucher processing and enrollment of the pledge
2343       into the new domain).  As the pledge-status request is defined
2344       generic, it may be used by other specifications to request further
2345       status information, e.g., for onboarding to get further information
2346       about enrollment of application specific LDevIDs or other parameters.
2347       This is out of scope for this specification.

2349       Figure 20 below shows an example for querying pledge-status using
2350       status-type bootstrap.

2352       # The registrar-agent request of "pledge-status" in general JWS
2353         serialization syntax
2354       {
2355         "payload": "BASE64URL(status-request)",
2356         "signatures": [
2357           {
2358             "protected": "BASE64URL(UTF8(JWS Protected Header))",
2359             "signature": "base64encodedvalue=="
2360           }
2361         ]
2362       }

2364       # Decoded payload "status-request" representation in JSON syntax
2365       {
2366         "version": 1,
2367         "created-on": "2022-08-12T02:37:39.235Z",
2368         "serial-number": "pledge-callee4711",
2369         "status-type": "bootstrap"
2370       }

2372       # Decoded "JWS Protected Header" representation in JSON syntax
2373       {
2374         "alg": "ES256",
2375         "x5c": [
2376           "base64encodedvalue==",
2377           "base64encodedvalue=="
2378         ]
2379       }

2381           Figure 20: Example of registrar-agent request of pledge-status
2382                            using status-type bootstrap

2384    6.4.2.  Pledge-Status - Response (Pledge - Registrar-Agent)

2386       If the pledge receives the pledge-status request with status-type
2387       "bootstrap" it SHALL react with a status response message based on
2388       the telemetry information described in section Section 6.3.

2390       The pledge-status response Content-Type header is application/
2391       jose+json.

2393       The following CDDL explains the structure of the format for the
2394       status response, which is :

2396       <CODE BEGINS>
2397         status-response = {
2398           "version": uint,
2399           "status":
2400             "factory-default" /
2401             "voucher-success" /
2402             "voucher-error" /
2403             "enroll-success" /
2404             "enroll-error" /
2405             "connect-success" /
2406             "connect-error",
2407           ?"reason" : text,
2408           ?"reason-context" : { $$arbitrary-map }
2409         }
2410       <CODE ENDS>

2412                     Figure 21: CDDL for pledge-status response

2414       Different cases for pledge bootstrapping status may occur, which
2415       SHOULD be reflected using the status enumeration.  This document
2416       specifies the status values in the context of the bootstrapping
2417       process and credential application.  Other documents may enhance the
2418       above enumeration to reflect further status information.

2420       The pledge-status response message is signed with IDevID or LDevID,
2421       depending on bootstrapping state of the pledge.

I think earlier in the text in this section you said only LDevID.

There is also the question as to whether or not th pledge wants to divulge
the status to anybody. I remember that even as much as 5 years ago we had
to limit LLDP information from network devices to prohibit unauthenticated
status visibility. So it might make sense to say that pledge SHOULD
by default only answer to nodes that they can authenticate (such as registrar
agents), once the pledge is enrolled with CA certificates and matching
domain certificate.

-->  TW: created issue #111

n
2423       *  "factory-default": Pledge has not been bootstrapped.  Additional
2424          information may be provided in the reason or reason-context.  The
2425          pledge signs the response message using its IDevID(Pledge).

2427       *  "voucher-success": Pledge processed the voucher exchange
2428          successfully.  Additional information may be provided in the
2429          reason or reason-context.  The pledge signs the response message
2430          using its IDevID(Pledge).

2432       *  "voucher-error": Pledge voucher processing terminated with error.
2433          Additional information may be provided in the reason or reason-
2434          context.  The pledge signs the response message using its
2435          IDevID(Pledge).

2437       *  "enroll-success": Pledge has processed the enrollment exchange
2438          successfully.  Additional information may be provided in the
2439          reason or reason-context.  The pledge signs the response message
2440          using its LDevID(Pledge).

2442       *  "enroll-error": Pledge enrollment response processing terminated
2443          with error.  Additional information may be provided in the reason
2444          or reason-context.  The pledge signs the response message using
2445          its IDevID(Pledge).

2447       The reason and the reason-context SHOULD contain the telemetry
2448       information as described in section Section 6.3.

2450       As the pledge is assumed to utilize the bootstrapped credential

s/the bootstrapped credential/its LDevID(Pledge)/

--> TW: changed: „As the pledge is assumed to utilize its bootstrapped credentials (LDevID) in communication“

2451       information in communication with other peers, additional status
2452       information is provided for the connectivity to other peers, which
2453       may be helpful in analyzing potential error cases.

2455       *  "connect-success": Pledge could successfully establish a
2456          connection to another peer.  Additional information may be
2457          provided in the reason or reason-context.  The pledge signs the
2458          response message using its LDevID(Pledge).

2460       *  "connect-error": Pledge connection establishment terminated with
2461          error.  Additional information may be provided in the reason or
2462          reason-context.  The pledge signs the response message using its
2463          LDevID(Pledge).

2465       The pledge-status responses are cumulative in the sense that connect-
2466       success implies enroll-success, which in turn implies voucher-
2467       success.

2469       Figure 22 provides an example for the bootstrapping-status
2470       information.

2472       # The pledge "status-response" in General JWS Serialization syntax
2473       {
2474         "payload": "BASE64URL(status-response)",
2475         "signatures": [
2476           {
2477             "protected": "BASE64URL(UTF8(JWS Protected Header))",
2478             "signature": "base64encodedvalue=="
2479           }
2480         ]
2481       }

2483       # Decoded payload "status-response" representation in JSON syntax
2484       {
2485         "version": 1,
2486         "status": "enroll-success",
2487         "reason-context": {
2488           "additional" : "JSON"

s/JSON/example text/ ??

-->  TW: created issue #112

2489         }
2490       }

2492       # Decoded "JWS Protected Header" representation in JSON syntax
2493       {
2494         "alg": "ES256",
2495         "x5c": [
2496           "base64encodedvalue==",
2497           "base64encodedvalue=="
2498         ],
2499         "typ": "jose+json
2500       }

2502                    Figure 22: Example of pledge-status response

2504       In case "factory-default" the pledge does not possess the domain
2505       certificate resp. the domain trust-anchor.  It will not be able to
2506       verify the signature of the registrar-agent in the bootstrapping-
2507       status request.

and.... just provide the status reply without authentication ?!

-->  TW: created issue #113


new paraagraph.

--> TW: changed

2507       In cases "vouchered" and "enrolled" the pledge
2508       already possesses the domain certificate (has domain trust-anchor)
2509       and can therefore validate the signature of the registrar-agent.  If
2510       validation of the JWS signature fails, the pledge SHOULD respond with
2511       the HTTP 403 Forbidden status code.

Ok. great. this is what i was suggesting earlier.

new paragraph.

--> TW: changed


2511       The HTTP 406 Not Acceptable
2512       status code SHOULD be used, if the Accept header in the request
2513       indicates an unknown or unsupported format.  The HTTP 415 Unsupported
2514       Media Type status code SHOULD be used, if the Content-Type of the
2515       request is an unknown or unsupported format.  The HTTP 400 Bad
2516       Request status code SHOULD be used, if the Accept/Content-Type
2517       headers are correct but nevertheless the status-request cannot be
2518       correctly parsed.

2520    7.  Artifacts

not reviewing now, because i think this moves to rfc8366bis, right ?

--> TW: already adapted in latest version


2522    7.1.  Voucher Request Artifact

2524       The following enhancement extends the voucher-request as defined in
2525       [RFC8995] to include additional fields necessary for handling
2526       bootstrapping in the pledge-responder-mode.

2528    7.1.1.  Tree Diagram

2530       The following tree diagram is mostly a duplicate of the contents of
2531       [RFC8995], with the addition of the fields agent-signed-data,
2532       registrar-proximity-certificate, and agent-signing certificate.  The
2533       tree diagram is described in [RFC8340].  Each node in the diagram is
2534       fully described by the YANG module in Section Section 7.1.2.

2536       module: ietf-voucher-request-prm

2538        grouping voucher-request-prm-grouping
2539         +-- voucher
2540            +-- created-on?                               yang:date-and-time
2541            +-- expires-on?                               yang:date-and-time
2542            +-- assertion?                                enumeration
2543            +-- serial-number                             string
2544            +-- idevid-issuer?                            binary
2545            +-- pinned-domain-cert?                       binary
2546            +-- domain-cert-revocation-checks?            boolean
2547            +-- nonce?                                    binary
2548            +-- last-renewal-date?                        yang:date-and-time
2549            +-- prior-signed-voucher-request?             binary
2550            +-- proximity-registrar-cert?                 binary
2551            +-- agent-signed-data?                        binary
2552            +-- agent-provided-proximity-registrar-cert?  binary
2553            +-- agent-sign-cert?                          binary

2555    7.1.2.  YANG Module

2557       The following YANG module extends the [RFC8995] Voucher Request to
2558       include a signed artifact from the registrar-agent (agent-signed-
2559       data) as well as the registrar-proximity-certificate and the agent-
2560       signing certificate.

2562       <CODE BEGINS> file [e-mail]<mailto:[e-mail]>
2563       module ietf-voucher-request-prm {
2564         yang-version 1.1;

2566         namespace "urn:ietf:params:xml:ns:yang:ietf-voucher-request-prm";
2567         prefix vrprm;
2568         import ietf-restconf {
2569           prefix rc;
2570           description
2571             "This import statement is only present to access
2572              the yang-data extension defined in RFC 8040.";
2573           reference "RFC 8040: RESTCONF Protocol";
2574         }

2576         import ietf-voucher-request {
2577           prefix vcr;
2578           description
2579             "This module defines the format for a voucher request,
2580                 which is produced by a pledge as part of the RFC8995
2581                 onboarding process.";
2582           reference
2583             "RFC 8995: Bootstrapping Remote Secure Key Infrastructure";
2584         }

2586         organization
2587          "IETF ANIMA Working Group";

2589         contact
2590          "WG Web:   <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftools.ietf.org%2Fwg%2Fanima%2F&data=05%7C01%7Cthomas-werner%40siemens.com%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131634928167457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=KlY2j9nsOxfUfH8QmTU3BE6mpCKtF%2B03ZFTmWfPGwRA%3D&reserved=0<http://tools.ietf.org/wg/anima/>>
2591           WG List:  <mailto:[e-mail]>
2592           Author:   Steffen Fries
2593                     <mailto:[e-mail]>
2594           Author:   Eliot Lear
2595                     <mailto: [e-mail]<mailto:[e-mail]>>
2596           Author:   Thomas Werner
2597                     <mailto: [e-mail]<mailto:[e-mail]>>
2598           Author:   Michael Richardson
2599                     <mailto: [e-mail]<mailto:[e-mail]>>";

2601         description
2602          "This module defines the format for a voucher-request form the
2603           pledge in responder mode. It bases on the voucher-request
2604           defined in RFC 8995, which is a superset of the voucher itself.
2605           It provides content to the MASA for consideration
2606           during a voucher-request.

2608           The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
2609           NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
2610           'MAY', and 'OPTIONAL' in this document are to be interpreted as
2611           described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
2612           they appear in all capitals, as shown here.

2614           Copyright (c) 2021 IETF Trust and the persons identified as
2615           authors of the code. All rights reserved.

2617           Redistribution and use in source and binary forms, with or
2618           without modification, is permitted pursuant to, and subject
2619           to the license terms contained in, the Simplified BSD License
2620           set forth in Section 4.c of the IETF Trust's Legal Provisions
2621           Relating to IETF Documents
2622           (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustee.ietf.org%2Flicense-info&data=05%7C01%7Cthomas-werner%40siemens.com%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131634928167457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=PcliCKkUdRNcHFWoNrl0v9yPiqCmOSmjHj2WWmiaBgg%3D&reserved=0<https://trustee.ietf.org/license-info>).

2624           This version of this YANG module is part of RFC xxxx; see the
2625           RFC itself for full legal notices.";

2627         revision 2022-07-05 {
2628           description
2629            "Initial version";
2630           reference
2631            "RFC XXXX: BRSKI for Pledge in Responder Mode";
2632         }

2634         // Top-level statement
2635         rc:yang-data voucher-request-prm-artifact {
2636           // YANG data template for a voucher-request.
2637           uses voucher-request-prm-grouping;
2638         }
2639         // Grouping defined for future usage
2640         grouping voucher-request-prm-grouping {
2641           description
2642             "Grouping to allow reuse/extensions in future work.";
2643           uses vcr:voucher-request-grouping {

2645             augment voucher {
2646               description "Base the voucher-request-prm upon the
2647                 regular one";

2649               leaf agent-signed-data {
2650                 type binary;
2651                 description
2652                   "The agent-signed-data field contains a JOSE [RFC7515]
2653                    object provided by the Registrar-Agent to the Pledge.

2655                    This artifact is signed by the Registrar-Agent
2656                    and contains a copy of the pledge's serial-number.";
2657               }

2659               leaf agent-provided-proximity-registrar-cert {
2660                 type binary;
2661                 description
2662                   "An X.509 v3 certificate structure, as specified by
2663                    RFC 5280, Section 4, encoded using the ASN.1
2664                    distinguished encoding rules (DER), as specified
2665                    in ITU X.690.
2666                    The first certificate in the registrar TLS server
2667                    certificate_list sequence (the end-entity TLS
2668                    certificate; see RFC 8446) presented by the
2669                    registrar to the registrar-agent and provided to
2670                    the pledge.
2671                    This MUST be populated in a pledge's voucher-request
2672                    when an agent-proximity assertion is requested.";
2673                 reference
2674                   "ITU X.690: Information Technology - ASN.1 encoding
2675                    rules: Specification of Basic Encoding Rules (BER),
2676                    Canonical Encoding Rules (CER) and Distinguished
2677                    Encoding Rules (DER)
2678                    RFC 5280: Internet X.509 Public Key Infrastructure
2679                    Certificate and Certificate Revocation List (CRL)
2680                    Profile
2681                    RFC 8446: The Transport Layer Security (TLS)
2682                    Protocol Version 1.3";
2683               }

2685               leaf-list agent-sign-cert{
2686                 type binary;
2687                 min-elements 1;
2688                 description
2689                   "An X.509 v3 certificate structure, as specified by
2690                    RFC 5280, Section 4, encoded using the ASN.1
2691                    distinguished encoding rules (DER), as specified
2692                    in ITU X.690.
2693                    This certificate can be used by the pledge,
2694                    the registrar, and the MASA to verify the signature
2695                    of agent-signed-data. It is an optional component
2696                    for the pledge-voucher request.
2697                    This MUST be populated in a registrar's
2698                    voucher-request when an agent-proximity assertion
2699                    is requested.
2700                    It is defined as list to enable inclusion of further
2701                    certificates along the certificate chain if different
2702                    issuing CAs have been used for the registrar-agent
2703                    and the registrar.";
2704                 reference
2705                   "ITU X.690: Information Technology - ASN.1 encoding
2706                    rules: Specification of Basic Encoding Rules (BER),
2707                    Canonical Encoding Rules (CER) and Distinguished
2708                    Encoding Rules (DER)
2709                    RFC 5280: Internet X.509 Public Key Infrastructure
2710                    Certificate and Certificate Revocation List (CRL)
2711                    Profile";

2713               }
2714             }
2715           }
2716         }
2717       }
2718       <CODE ENDS>

2720       Examples for the PVR are provided in Section 6.2.

2722    8.  IANA Considerations

2724       This document requires the following IANA actions.

2726    8.1.  BRSKI .well-known Registry

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

2731      URI                        Description                       Reference
2732      tv                         create pledge-voucher-request     [THISRFC]
2733      te                         create pledge-enrollment-request  [THISRFC]
2734      sv                         supply voucher response           [THISRFC]
2735      se                         supply enrollment response        [THISRFC]
2736      cc                         supply CA certificates to pledge  [THISRFC]
2737      ps                         query pledge status               [THISRFC]
2738      requestenroll              supply PER to registrar           [THISRFC]
2739      wrappedcacerts             request wrapped CA certificates   [THISRFC]

2741    9.  Privacy Considerations

2743       In general, the privacy considerations of [RFC8995] apply for BRSKI-
2744       PRM also.  Further privacy aspects need to be considered for:

2746       *  the introduction of the additional component registrar-agent

2748       *  no transport layer security between registrar-agent and pledge

2750       The credential used by the registrar-agent to sign the data for the
2751       pledge should not contain any personal information.  Therefore, it is
2752       recommended to use an LDevID certificate associated with the
2753       commissioning device instead of an LDevID certificate associated with
2754       the service technician operating the device.  This avoids revealing
2755       potentially included personal information to Registrar and MASA.

Nice. I'd even try to go for SHOULD NOT (not quite clear with this couldn't
be normative, but someone from IESG review should complain if its not ok.).

--> TW: changed: „pledge SHOULD NOT contain any personal information“

2757       The communication between the pledge and the registrar-agent is
2758       performed over plain HTTP.  Therefore, it is subject to disclosure by
2759       a Dolev-Yao attacker (an "oppressive observer")[onpath].  Depending
2760       on the requests and responses, the following information is
2761       disclosed.

This of course raises the question why we're not using https between pledge
and registrar-agent to prohibit such mitm obervation (beyond other good reasons
to use https that i brought up in my first part of the review).

Remember that the registrar can always authenticate the IDevID of pledges,
so arguably the pledge vendors trust anchors can also be provisionined
onto registrar-agents (not more difficult than the serial numbers that you
assume to be provisionalbe - which i find much more difficult), and the
pledge simply does not even need to do any registrar-agent certificate
verification, but solely because of TLS PFS, this one-side verification
should suffice to prohibit passive observation.

--> TW: created issue #114

2763       *  the Pledge product-serial-number is contained in the trigger
2764          message for the PVR and in all responses from the pledge.  This
2765          information reveals the identity of the devices being bootstrapped
2766          and allows deduction of which products an operator is using in
2767          their environment.  As the communication between the pledge and
2768          the registrar-agent may be realized over wireless link, this
2769          information could easily be eavesdropped, if the wireless network
2770          is unencrypted.  Even if the wireless network is encrypted, if it
2771          uses a network-wide key, then layer-2 attacks (ARP/ND spoofing)
2772          could insert an on-path observer into the path.

2774       *  the Timestamp data could reveal the activation time of the device.

2776       *  the Status data of the device could reveal information about the
2777          current state of the device in the domain network.

I'll comment on whether this is complete after we have (hopefully not)
concluded that we cannot/should-not use http.

--> TW: created issue #115

2779    10.  Security Considerations

2781       In general, the security considerations of [RFC8995] apply for BRSKI-
2782       PRM also.  Further security aspects are considered here related to:

2784       *  the introduction of the additional component registrar-agent

2786       *  the reversal of the pledge communication direction (push mode,
2787          compared to BRSKI)

2789       *  no transport layer security between registrar-agent and pledge

2791    10.1.  Denial of Service (DoS) Attack on Pledge

2793       Disrupting the pledge behavior by a DoS attack may prevent the
2794       bootstrapping of the pledge to a new domain.

2796       A DoS attack with a faked registrar-agent may block the bootstrapping
2797       of the pledge due to state creation on the pledge (the pledge may
2798       produce a voucher-request, and refuse to produce another one).  One
2799       mitigation may be that the pledge does does not limited the number of
2800       voucher requests it creates until at least one has finished, or a
2801       single onboarding state may expire after a certain time.

The way i remember, the nonce is really only meant to protect against replay
attack from e.g. a prior owner: Owner generates voucher, then sells box,
new owner takes ownership with new voucher, then sneaky prior owner re-owns
pledge (after some partial reset) with prior voucher and then gains access
to some not-fully reset information about the second owner on the pledge.

The way to protect against this is IMHO to simply not issue new nonce values for
every voucher request thats is triggered, but only to generate a new nonce
after the pledge is presented with a successful voucher for the prior
nonce. and remember the prior nonce value as "do-not-reuse". For example
by having a persistent (e.g.: TPM based) RNG for the nonce. Thats just
one more persistent number to remember.

Maybe write something like that.

--> TW: created issue #116

2803    10.2.  Misuse of acquired PVR and PER by Registrar-Agent

2805       A registrar-agent that uses previously requested PVR and PER for
2806       domain-A, may attempt to onboard the device into domain-B.  This can
2807       be detected by the domain registrar while PVR processing.  The domain
2808       registrar needs to verify that the "proximity-registrar-cert" field
2809       in the PVR matches its own registrar EE certificate.  In addition,
2810       the domain registrar needs to verify the association of the pledge to
2811       its domain based on the product-serial-number contained in the PVR
2812       and in the IDevID certificate of the pledge.  (This is just part of
2813       the supply chain integration) Moreover, the domain registrar verifies
2814       if the registrar-agent is authorized to interact with the pledge for
2815       voucher-requests and enroll-requests, based on the LDevID(RegAgt)
2816       certificate data contained in the PVR.

2818       Misbinding of a pledge by a faked domain registrar is countered as
2819       described in BRSKI security considerations [RFC8995] (section 11.4).

2821    10.3.  Misuse of Registrar-Agent Credentials

2823       Concerns of misusage of a registrar-agent with a valid
2824       LDevID(RegAgt), may be addressed by utilizing short-lived
2825       certificates (e.g., valid for a day) to authenticate the registrar-
2826       agent against the domain registrar.  The LDevID(RegAgt) certificate
2827       may be acquired by a prior BRSKI run for the registrar-agent, if an
2828       IDevID is available on registrar-agent.  Alternatively, the LDevID
2829       may be acquired by a service technician from the domain PKI system in
2830       an authenticated way.

These problems would be eliminated with the LDevID of the registrar-agent
would as i suggested in part 1 of my review only be used for tracing on or
behind the registrar which registrar-agent was forwarding messages, but not
making any actual enrolment security decisions based on it. Which i tried to
outline how.

--> TW: created issue #117

2832       In addition it is required that the LDevID(RegAgt) certificate is
2833       valid for the complete bootstrapping phase.  This avoids that a
2834       registrar-agent could be misused to create arbitrary "agent-signed-
2835       data" objects to perform an authorized bootstrapping of a rogue
2836       pledge at a later point in time.  In this misuse "agent-signed-data"
2837       could be dated after the validity time of the LDevID(RegAgt)
2838       certificate, due to missing trusted timestamp in the registrar-agents
2839       signature.  To address this, the registrar SHOULD verify the
2840       certificate used to create the signature on "agent-signed-data".
2841       Furthermore the registrar also verifies the LDevID(RegAgt)
2842       certificate used in the TLS handshake with the registrar-agent.  If
2843       both certificates are verified successfully, the registrar-agent's
2844       signature can be considered as valid.

Same.

--> TW: created issue #117

2846    10.4.  Misuse of mDNS to obtain list of pledges

2848       To discover a specific pledge a registrar-agent may request the
2849       service name in combination with the product-serial-number of a
2850       specific pledge.  The pledge reacts on this if its product-serial-
2851       number is part of the request message.

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

2862    10.5.  YANG Module Security Considerations

2864       The enhanced voucher-request described in section Section 7.1 is
2865       bases on [RFC8995], but uses a different encoding based on
2866       [I-D.ietf-anima-jws-voucher].  Therefore similar considerations as
2867       described in [RFC8995] section 11.7 (Security Considerations) apply.
2868       The YANG module specified in this document defines the schema for
2869       data that is subsequently encapsulated by a JOSE signed-data Content-
2870       type as described in [I-D.ietf-anima-jws-voucher].  As such, all of
2871       the YANG-modeled data is protected against modification.  The use of
2872       YANG to define data structures via the "yang-data" statement, is
2873       relatively new and distinct from the traditional use of YANG to
2874       define an API accessed by network management protocols such as
2875       NETCONF [RFC6241] and RESTCONF [RFC8040].  For this reason these
2876       guidelines do not follow the template described by [RFC8407] section
2877       3.7 (Security Considerations Section).

2879    11.  Acknowledgments

2881       We would like to thank the various reviewers, in particular Brian E.
2882       Carpenter, Oskar Camenzind, Hendrik Brockhaus, and Ingo Wenda for
2883       their input and discussion on use cases and call flows.  Further
2884       review input was provided by Jesser Bouzid, Dominik Tacke, and
2885       Christian Spindler.  Special thanks to Esko Dijk for the in deep
2886       review and the improving proposals.  Support in PoC implementations
2887       and comments resulting from the implementation was provided by Hong
2888       Rui Li and He Peng Jia.

I'll stop here. Thanks a lot folks. Lot of good work, and a lot more security
relevant changes to BRSKI than the constrained work IMHO so don't be too annoyed
by the due diligence this requires.

• TW: thanks for your review and feedback.

Cheers
    Toerless

2890    12.  References

2892    12.1.  Normative References

2894       [I-D.ietf-anima-jws-voucher]
2895                  Werner, T. and M. Richardson, "JWS signed Voucher
2896                  Artifacts for Bootstrapping Protocols", Work in Progress,
2897                  Internet-Draft, draft-ietf-anima-jws-voucher-05, 24
2898                  October 2022, <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-&data=05%7C01%7Cthomas-werner%40siemens.com%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131634928167457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=YwrEg54k3hkZbc9bBz2E2qFE3mhRtaEhDPxrBiCjrD4%3D&reserved=0<https://www.ietf.org/archive/id/draft-ietf->
2899                  anima-jws-voucher-05.txt>.

2901       [I-D.ietf-anima-rfc8366bis]
2902                  Watsen, K., Richardson, M., Pritikin, M., Eckert, T. T.,
2903                  and Q. Ma, "A Voucher Artifact for Bootstrapping
2904                  Protocols", Work in Progress, Internet-Draft, draft-ietf-
2905                  anima-rfc8366bis-00, 31 January 2022,
2906                  <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-anima-&data=05%7C01%7Cthomas-werner%40siemens.com%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131634928167457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=REwLYziVh0sNVumr3sdZIJ0naQd6LO6aJTeRXVb1Qpo%3D&reserved=0<https://www.ietf.org/archive/id/draft-ietf-anima->
2907                  rfc8366bis-00.txt>.

2909       [I-D.ietf-netconf-sztp-csr]
2910                  Watsen, K., Housley, R., and S. Turner, "Conveying a
2911                  Certificate Signing Request (CSR) in a Secure Zero Touch
2912                  Provisioning (SZTP) Bootstrapping Request", Work in
2913                  Progress, Internet-Draft, draft-ietf-netconf-sztp-csr-14,
2914                  2 March 2022, <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-&data=05%7C01%7Cthomas-werner%40siemens.com%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131634928167457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=YwrEg54k3hkZbc9bBz2E2qFE3mhRtaEhDPxrBiCjrD4%3D&reserved=0<https://www.ietf.org/archive/id/draft-ietf->
2915                  netconf-sztp-csr-14.txt>.

2917       [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
2918                  Requirement Levels", BCP 14, RFC 2119,
2919                  DOI 10.17487/RFC2119, March 1997,
2920                  <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc2119&data=05%7C01%7Cthomas-werner%40siemens.com%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131634928167457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jkN61XtVLUHv4lZJaQhAhLmbavM59IO2ee%2BsofSSHnU%3D&reserved=0<https://www.rfc-editor.org/info/rfc2119>>.

2922       [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
2923                  Housley, R., and W. Polk, "Internet X.509 Public Key
2924                  Infrastructure Certificate and Certificate Revocation List
2925                  (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
2926                  <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc5280&data=05%7C01%7Cthomas-werner%40siemens.com%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131634928167457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=z5eLcSFnnD2rIu%2FqdSGNCEyj7c9jYLdjYUydWsvrrGU%3D&reserved=0<https://www.rfc-editor.org/info/rfc5280>>.

2928       [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
2929                  DOI 10.17487/RFC6762, February 2013,
2930                  <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc6762&data=05%7C01%7Cthomas-werner%40siemens.com%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131634928167457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GvA4Vy%2FHcSi6WgwnEQo4pjZIFtuUikBbS%2F1JRC9ERBY%3D&reserved=0<https://www.rfc-editor.org/info/rfc6762>>.

2932       [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
2933                  Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
2934                  <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc6763&data=05%7C01%7Cthomas-werner%40siemens.com%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131634928167457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wdeH%2BkFAWgJQ%2BSC0W0FLc9MPR5hcN2BbdLo3cW36cmE%3D&reserved=0<https://www.rfc-editor.org/info/rfc6763>>.

2936       [RFC7030]  Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
2937                  "Enrollment over Secure Transport", RFC 7030,
2938                  DOI 10.17487/RFC7030, October 2013,
2939                  <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc7030&data=05%7C01%7Cthomas-werner%40siemens.com%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131634928167457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=F3B91e5YR892KO5ZATV1GUHUn0cJOGwklnP%2Byapj5E4%3D&reserved=0<https://www.rfc-editor.org/info/rfc7030>>.

2941       [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
2942                  Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2943                  2015, <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc7515&data=05%7C01%7Cthomas-werner%40siemens.com%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131634928167457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=OIY8j3RU2FYtBkPv64bG%2FuIQcfKAJBi43UuNGbaPmV8%3D&reserved=0<https://www.rfc-editor.org/info/rfc7515>>.

2945       [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
2946                  Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
2947                  <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc8040&data=05%7C01%7Cthomas-werner%40siemens.com%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131634928167457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=NgrrHxhV8KO4bn7pPqnPlwfu7LU0I3zKiKxYAm2YlbM%3D&reserved=0<https://www.rfc-editor.org/info/rfc8040>>.

2949       [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2950                  2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
2951                  May 2017, <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc8174&data=05%7C01%7Cthomas-werner%40siemens.com%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131634928167457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BEL6rIDJCBepbnkpdVrbWq4Hbk8FbEWsk%2BlM2u5o3xk%3D&reserved=0<https://www.rfc-editor.org/info/rfc8174>>.

2953       [RFC8366]  Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
2954                  "A Voucher Artifact for Bootstrapping Protocols",
2955                  RFC 8366, DOI 10.17487/RFC8366, May 2018,
2956                  <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc8366&data=05%7C01%7Cthomas-werner%40siemens.com%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131634928167457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=byIw2Xez2VWor6YrcGTNgfl26%2F2eVjrDcdnnDWYf79k%3D&reserved=0<https://www.rfc-editor.org/info/rfc8366>>.

2958       [RFC8610]  Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
2959                  Definition Language (CDDL): A Notational Convention to
2960                  Express Concise Binary Object Representation (CBOR) and
2961                  JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
2962                  June 2019, <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc8610&data=05%7C01%7Cthomas-werner%40siemens.com%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131634928167457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Yw3oeLHoc59FR7wZtEknINXTrooXBwu46IUu8HvJ%2BAI%3D&reserved=0<https://www.rfc-editor.org/info/rfc8610>>.

2964       [RFC8995]  Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
2965                  and K. Watsen, "Bootstrapping Remote Secure Key
2966                  Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
2967                  May 2021, <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc8995&data=05%7C01%7Cthomas-werner%40siemens.com%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131634928167457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=vNzYm153nNbPhJce%2BR25a4V7zTyOER9otroiifGyhFE%3D&reserved=0<https://www.rfc-editor.org/info/rfc8995>>.

2969    12.2.  Informative References

2971       [BRSKI-PRM-abstract]
2972                  "Abstract BRSKI-PRM Protocol Overview", April 2022,
2973                  <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2Fanima-wg%2Fanima-brski-&data=05%7C01%7Cthomas-werner%40siemens.com%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131634928167457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=p3KstHtgJI6PXI1wj8F6nry4F0DtEsP2Kh4tBS4ilwI%3D&reserved=0<https://raw.githubusercontent.com/anima-wg/anima-brski->
2974                  prm/main/pics/brski_prm_overview.png>.

2976       [I-D.ietf-anima-brski-ae]
2977                  von Oheimb, D., Fries, S., and H. Brockhaus, "BRSKI-AE:
2978                  Alternative Enrollment Protocols in BRSKI", Work in
2979                  Progress, Internet-Draft, draft-ietf-anima-brski-ae-03, 24
2980                  October 2022, <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-&data=05%7C01%7Cthomas-werner%40siemens.com%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131634928167457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=YwrEg54k3hkZbc9bBz2E2qFE3mhRtaEhDPxrBiCjrD4%3D&reserved=0<https://www.ietf.org/archive/id/draft-ietf->
2981                  anima-brski-ae-03.txt>.

2983       [IEEE-802.1AR]
2984                  Institute of Electrical and Electronics Engineers, "IEEE
2985                  802.1AR Secure Device Identifier", IEEE 802.1AR, June
2986                  2018.

2988       [onpath]   "can an on-path attacker drop traffic?", n.d.,
2989                  <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fsaag%2F&data=05%7C01%7Cthomas-werner%40siemens.com%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131634928167457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jv3YXJuvJHU8kD8%2FKYyushZDjvbc5W8ydOEvqflI14Q%3D&reserved=0<https://mailarchive.ietf.org/arch/msg/saag/>
2990                  m1r9uo4xYznOcf85Eyk0Rhut598/>.

2992       [RFC2986]  Nystrom, M. and B. Kaliski, "PKCS #10: Certification
2993                  Request Syntax Specification Version 1.7", RFC 2986,
2994                  DOI 10.17487/RFC2986, November 2000,
2995                  <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc2986&data=05%7C01%7Cthomas-werner%40siemens.com%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131634928167457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=SC3zkmGUxy1c0xQpWl7QCKth9D61uRMxEFNa0yznYfc%3D&reserved=0<https://www.rfc-editor.org/info/rfc2986>>.

2997       [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
2998                  Verification of Domain-Based Application Service Identity
2999                  within Internet Public Key Infrastructure Using X.509
3000                  (PKIX) Certificates in the Context of Transport Layer
3001                  Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
3002                  2011, <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc6125&data=05%7C01%7Cthomas-werner%40siemens.com%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131634928167457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=BnMzfc0D7%2B17iDBoa2XSFOsP7%2F7MrVr7ubs5mMmpngQ%3D&reserved=0<https://www.rfc-editor.org/info/rfc6125>>.

3004       [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
3005                  and A. Bierman, Ed., "Network Configuration Protocol
3006                  (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
3007                  <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc6241&data=05%7C01%7Cthomas-werner%40siemens.com%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131634928167457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bvV8SPFpEYRobRihLzXsPriTyHxQe3I4Wup1zHGuRoY%3D&reserved=0<https://www.rfc-editor.org/info/rfc6241>>.

3009       [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
3010                  Application Protocol (CoAP)", RFC 7252,
3011                  DOI 10.17487/RFC7252, June 2014,
3012                  <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc7252&data=05%7C01%7Cthomas-werner%40siemens.com%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131634928167457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=9W4Tx9nQiK2uE2MFDy%2B1%2BUCtt39juAxOpswt7gjYpZM%3D&reserved=0<https://www.rfc-editor.org/info/rfc7252>>.

3014       [RFC8340]  Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
3015                  BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
3016                  <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc8340&data=05%7C01%7Cthomas-werner%40siemens.com%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131634928167457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4lPa0ny4fzctXA5sg4CYK8XvsUykTPpY8cS%2FE0338%2B8%3D&reserved=0<https://www.rfc-editor.org/info/rfc8340>>.

3018       [RFC8407]  Bierman, A., "Guidelines for Authors and Reviewers of
3019                  Documents Containing YANG Data Models", BCP 216, RFC 8407,
3020                  DOI 10.17487/RFC8407, October 2018,
3021                  <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc8407&data=05%7C01%7Cthomas-werner%40siemens.com%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131634928167457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=crLemEos6vyMmgwjtUdYjRLTe8NjN5ffbKer0HhhTe4%3D&reserved=0<https://www.rfc-editor.org/info/rfc8407>>.

3023       [RFC8792]  Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
3024                  "Handling Long Lines in Content of Internet-Drafts and
3025                  RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
3026                  <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc8792&data=05%7C01%7Cthomas-werner%40siemens.com%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131634928167457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=XxdP5IEKXhoVvLhKx3trf7Ls0AnuBD%2BJ34eHbSA3gEg%3D&reserved=0<https://www.rfc-editor.org/info/rfc8792>>.

3028       [RFC9052]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
3029                  Structures and Process", STD 96, RFC 9052,
3030                  DOI 10.17487/RFC9052, August 2022,
3031                  <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc9052&data=05%7C01%7Cthomas-werner%40siemens.com%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131634928167457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=vrStw4SJmGrlSLUDWAfcliQBow9FFAbYqIOPFnkR65Y%3D&reserved=0<https://www.rfc-editor.org/info/rfc9052>>.

3033       [RFC9053]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
3034                  Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
3035                  August 2022, <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc9053&data=05%7C01%7Cthomas-werner%40siemens.com%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131634928167457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ndwfTZg0QAuz79tD5QGjscsmyZX1O9HfuRJI4VA7%2BTY%3D&reserved=0<https://www.rfc-editor.org/info/rfc9053>>.

3037       [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
3038                  Ed., "HTTP Semantics", STD 97, RFC 9110,
3039                  DOI 10.17487/RFC9110, June 2022,
3040                  <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc9110&data=05%7C01%7Cthomas-werner%40siemens.com%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131634928167457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=VzMUcfBI6fVTZ%2F139uDOYvCV5GUBur5jPZQkN0ucyf4%3D&reserved=0<https://www.rfc-editor.org/info/rfc9110>>.

3042       [RFC9238]  Richardson, M., Latour, J., and H. Habibi Gharakheili,
3043                  "Loading Manufacturer Usage Description (MUD) URLs from QR
3044                  Codes", RFC 9238, DOI 10.17487/RFC9238, May 2022,
3045                  <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc9238&data=05%7C01%7Cthomas-werner%40siemens.com%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131634928167457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ZdcMc9XOthXwS%2FUOfGoDnsyiWYKvaiQHHdwUUDllJEk%3D&reserved=0<https://www.rfc-editor.org/info/rfc9238>>.

3047    Appendix A.  Examples

3049       These examples are folded according to [RFC8792] Single Backslash
3050       rule.

3052    A.1.  Example Pledge Voucher Request - PVR (from Pledge to Registrar-
3053          agent)

3055       The following is an example request sent from a Pledge to the
3056       Registrar-agent, in "General JWS JSON Serialization".
3057       The message size of this PVR is: 4649 bytes

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

3061       {
3062         "payload":
3063           "eyJpZXRmLXZvdWNoZXItcmVxdWVzdC1wcm06dm91Y2hlciI6eyJhc3NlcnRpb24\
3064       iOiJhZ2VudC1wcm94aW1pdHkiLCJzZXJpYWwtbnVtYmVyIjoiMDEyMzQ1Njc4OSIsIm5\
3065       vbmNlIjoiTDNJSjZocHRIQ0lRb054YWFiOUhXQT09IiwiY3JlYXRlZC1vbiI6IjIwMjI\
3066       tMDQtMjZUMDU6MTY6MTcuNzA5WiIsImFnZW50LXByb3ZpZGVkLXByb3hpbWl0eS1yZWd\
3067       pc3RyYXItY2VydCI6Ik1JSUI0akNDQVlpZ0F3SUJBZ0lHQVhZNzJiYlpNQW9HQ0NxR1N\
3068       NNDlCQU1DTURVeEV6QVJCZ05WQkFvTUNrMTVRblZ6YVc1bGMzTXhEVEFMQmdOVkJBY01\
3069       CRk5wZEdVeER6QU5CZ05WQkFNTUJsUmxjM1JEUVRBZUZ3MHlNREV5TURjd05qRTRNVEp\
3070       hRncwek1ERXlNRGN3TmpFNE1USmFNRDR4RXpBUkJnTlZCQW9NQ2sxNVFuVnphVzVsYzN\
3071       NeERUQUxCZ05WQkFjTUJGTnBkR1V4R0RBV0JnTlZCQU1NRDBSdmJXRnBibEpsWjJsemR\
3072       ISmhjakJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFCQmsxNksvaTc5b1J\
3073       rSzVZYmVQZzhVU1I4L3VzMWRQVWlaSE10b2tTZHFLVzVmbldzQmQrcVJMN1dSZmZlV2t\
3074       5Z2Vib0pmSWxsdXJjaTI1d25oaU9WQ0dqZXpCNU1CMEdBMVVkSlFRV01CUUdDQ3NHQVF\
3075       VRkJ3TUJCZ2dyQmdFRkJRY0RIREFPQmdOVkhROEJBZjhFQkFNQ0I0QXdTQVlEVlIwUkJ\
3076       FRXdQNElkY21WbmFYTjBjbUZ5TFhSbGMzUXVjMmxsYldWdWN5MWlkQzV1WlhTQ0huSmx\
3077       aMmx6ZEhKaGNpMTBaWE4wTmk1emFXVnRaVzV6TFdKMExtNWxkREFLQmdncWhrak9QUVF\
3078       EQWdOSUFEQkZBaUJ4bGRCaFpxMEV2NUpMMlByV0N0eVM2aERZVzF5Q08vUmF1YnBDN01\
3079       hSURnSWhBTFNKYmdMbmdoYmJBZzBkY1dGVVZvL2dHTjAvand6SlowU2wyaDR4SVhrMSI\
3080       sImFnZW50LXNpZ25lZC1kYXRhIjoiZXlKd1lYbHNiMkZrSWpvaVpYbEtjRnBZVW0xTVd\
3081       GcDJaRmRPYjFwWVNYUmpiVlo0WkZkV2VtUkRNWGRqYlRBMldWZGtiR0p1VVhSak1teHV\
3082       ZbTFXYTB4WFVtaGtSMFZwVDI1emFWa3pTbXhaV0ZKc1drTXhkbUpwU1RaSmFrbDNUV3B\
3083       KZEUxRVVYUk5hbHBWVFVSVk5rMUVZelpPUkVWMVRrUlJORmRwU1hOSmJrNXNZMjFzYUd\
3084       KRE1YVmtWekZwV2xoSmFVOXBTWGROVkVsNlRrUlZNazU2WnpWSmJqRTVJaXdpYzJsbmJ\
3085       tRjBkWEpsY3lJNlczc2ljSEp2ZEdWamRHVmtJam9pWlhsS2NtRlhVV2xQYVVwWlkwaHd\
3086       jMVJWZERSaVNFSkNUbXBvYWxaVVZrZFZWVEZaVmxoYWRWTldVVEpWV0dNNVNXbDNhVmx\
3087       YZUc1SmFtOXBVbFpOZVU1VVdXbG1VU0lzSW5OcFoyNWhkSFZ5WlNJNklrY3pWM2hHU0d\
3088       WMFdGQTRiR3hTVmkwNWRXSnlURmxxU25aUllUWmZlUzFRYWxGWk5FNWhkMW81Y0ZKaGI\
3089       yeE9TbTlFTm1SbFpXdHVTVjlGV0daemVWWlRZbmM0VTBONlRWcE1iakJoUVhWb2FVZFp\
3090       UakJSSW4xZGZRPT0iLCJhZ2VudC1zaWduLWNlcnQiOlsiTUlJQjFEQ0NBWHFnQXdJQkF\
3091       nSUVZbWQ0T1RBS0JnZ3Foa2pPUFFRREFqQStNUk13RVFZRFZRUUtEQXBOZVVKMWMybHV\
3092       aWE56TVEwd0N3WURWUVFIREFSVGFYUmxNUmd3RmdZRFZRUUREQTlVWlhOMFVIVnphRTF\
3093       2WkdWc1EwRXdIaGNOTWpJd05ESTJNRFEwTWpNeldoY05Nekl3TkRJMk1EUTBNak16V2p\
3094       BOU1STXdFUVlEVlFRS0RBcE5lVUoxYzJsdVpYTnpNUTB3Q3dZRFZRUUhEQVJUYVhSbE1\
3095       SY3dGUVlEVlFRRERBNVNaV2RwYzNSeVlYSkJaMlZ1ZERCWk1CTUdCeXFHU000OUFnRUd\
3096       DQ3FHU000OUF3RUhBMElBQkd4bHJOZmozaVJiNy9CUW9kVys1WWlvT3poK2pJdHlxdVJ\
3097       JTy9XejdZb1czaXdEYzNGeGV3TFZmekNyNU52RDEzWmFGYjdmcmFuK3Q5b3RZNVdMaEo\
3098       2alp6QmxNQTRHQTFVZER3RUIvd1FFQXdJSGdEQWZCZ05WSFNNRUdEQVdnQlJ2b1QxdWR\
3099       lMmY2TEVRaFU3SEhqK3ZKL2Q3SXpBZEJnTlZIUTRFRmdRVVhwemxNS3hscEE2OGNVNUZ\
3100       RTVhVdm5JVDZRd3dFd1lEVlIwbEJBd3dDZ1lJS3dZQkJRVUhBd0l3Q2dZSUtvWkl6ajB\
3101       FQXdJRFNBQXdSUUlnYzJ5NnhvT3RvUUJsSnNnbE9MMVZ4SEdvc1R5cEVxUmZ6MFF2NFp\
3102       FUHY0d0NJUUNWeWIyRjl6VjNuOTUrb2xnZkZKZ1pUV0V6NGRTYUYzaHpSUWIzWnVCMjl\
3103       RPT0iLCJNSUlCekRDQ0FYR2dBd0lCQWdJRVhYakhwREFLQmdncWhrak9QUVFEQWpBMU1\
3104       STXdFUVlEVlFRS0RBcE5lVUoxYzJsdVpYTnpNUTB3Q3dZRFZRUUhEQVJUYVhSbE1ROHd\
3105       EUVlEVlFRRERBWlVaWE4wUTBFd0hoY05NVGt3T1RFeE1UQXdPRE0yV2hjTk1qa3dPVEV\
3106       4TVRBd09ETTJXakErTVJNd0VRWURWUVFLREFwTmVVSjFjMmx1WlhOek1RMHdDd1lEVlF\
3107       RSERBUlRhWFJsTVJnd0ZnWURWUVFEREE5VVpYTjBVSFZ6YUUxdlpHVnNRMEV3V1RBVEJ\
3108       nY3Foa2pPUFFJQkJnZ3Foa2pPUFFNQkJ3TkNBQVRsRzBmd1QzM29leloxdmtIUWJldGV\
3109       ibWorQm9WK1pGc2pjZlF3MlRPa0pQaE9rT2ZBYnU5YlMxcVppOHlhRVY4b2VyS2wvNlp\
3110       YYmZ4T21CanJScmNYbzJZd1pEQVNCZ05WSFJNQkFmOEVDREFHQVFIL0FnRUFNQTRHQTF\
3111       VZER3RUIvd1FFQXdJQ0JEQWZCZ05WSFNNRUdEQVdnQlRvWklNelFkc0Qvai8rZ1gvN2N\
3112       CSnVjSC9YbWpBZEJnTlZIUTRFRmdRVWI2RTliblh0bitpeEVJVk94eDQvcnlmM2V5TXd\
3113       DZ1lJS29aSXpqMEVBd0lEU1FBd1JnSWhBUG5CMHcxTkN1cmhNeEp3d2ZqejdnRGlpeGt\
3114       VWUxQU1o5ZU45a29oTlFVakFpRUF3NFk3bHR4V2lQd0t0MUo5bmp5ZkRObDVNdUVEQml\
3115       teFIzQ1hvWktHUXJVPSJdfX0",
3116           "signatures":[{
3117             "protected":"eyJ4NWMiOlsiTUlJQitUQ0NBYUNnQXdJQkFnSUdBWG5WanNVN\
3118       U1Bb0dDQ3FHU000OUJBTUNNRDB4Q3pBSkJnTlZCQVlUQWtGUk1SVXdFd1lEVlFRS0RBe\
3119       EthVzVuU21sdVowTnZjbkF4RnpBVkJnTlZCQU1NRGtwcGJtZEthVzVuVkdWemRFTkJNQ\
3120       0FYRFRJeE1EWXdOREExTkRZeE5Gb1lEems1T1RreE1qTXhNak0xT1RVNVdqQlNNUXN3Q\
3121       1FZRFZRUUdFd0pCVVRFVk1CTUdBMVVFQ2d3TVNtbHVaMHBwYm1kRGIzSndNUk13RVFZR\
3122       FZRUUZFd293TVRJek5EVTJOemc1TVJjd0ZRWURWUVFEREE1S2FXNW5TbWx1WjBSbGRtb\
3123       GpaVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFCQzc5bGlhUmNCalpjR\
3124       UVYdzdyVWVhdnRHSkF1SDRwazRJNDJ2YUJNc1UxMWlMRENDTGtWaHRVVjIxbXZhS0N2T\
3125       XgyWStTTWdROGZmd0wyM3ozVElWQldqZFRCek1Dc0dDQ3NHQVFVRkJ3RWdCQjhXSFcxa\
3126       GMyRXRkR1Z6ZEM1emFXVnRaVzV6TFdKMExtNWxkRG81TkRRek1COEdBMVVkSXdRWU1CY\
3127       UFGRlFMak56UFwvU1wva291alF3amc1RTVmdndjWWJNQk1HQTFVZEpRUU1NQW9HQ0NzR\
3128       0FRVUZCd01DTUE0R0ExVWREd0VCXC93UUVBd0lIZ0RBS0JnZ3Foa2pPUFFRREFnTkhBR\
3129       EJFQWlCdTN3UkJMc0pNUDVzTTA3MEgrVUZyeU5VNmdLekxPUmNGeVJST2xxcUhpZ0lnW\
3130       ENtSkxUekVsdkQycG9LNmR4NmwxXC91eW1UbmJRRERmSmxhdHVYMlJvT0U9Il0sImFsZ\
3131       yI6IkVTMjU2In0",
3132             "signature":"Y_ohapnmvbwjLuUicOB7NAmbGM7igBfpUlkKUuSNdG-eDI4BQ\

3134       yuXZ2aw93zZId45R7XxAK-12YKIx6qLjiPjMw"
3135         }]
3136       }

3138                  Figure 23: Example Pledge Voucher Request - PVR

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

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

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

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

3155       {
3156         "payload":
3157           "eyJpZXRmLXZvdWNoZXItcmVxdWVzdC1wcm06dm91Y2hlciI6eyJhc3NlcnRpb24\
3158       iOiJhZ2VudC1wcm94aW1pdHkiLCJzZXJpYWwtbnVtYmVyIjoiY2FmZmUtOTg3NDUiLCJ\
3159       ub25jZSI6ImM1VEVPb29NTE5hNEN4L1UrVExoQ3c9PSIsInByaW9yLXNpZ25lZC12b3V\
3160       jaGVyLXJlcXVlc3QiOiJleUp3WVhsc2IyRmtJam9pWlhsS2NGcFlVbTFNV0ZwMlpGZE9\
3161       iMXBZU1hSamJWWjRaRmRXZW1SRE1YZGpiVEEyWkcwNU1Wa3lhR3hqYVVrMlpYbEthR01\
3162       6VG14amJsSndZakkwYVU5cFNtaGFNbFoxWkVNeGQyTnRPVFJoVnpGd1pFaHJhVXhEU25\
3163       wYVdFcHdXVmQzZEdKdVZuUlpiVlo1U1dwdmFWa3lSbTFhYlZWMFQxUm5NMDVFVldsTVE\
3164       wcDFZakkxYWxwVFNUWkpiVTB4VmtWV1VHSXlPVTVVUlRWb1RrVk9ORXd4VlhKV1JYaHZ\
3165       VVE5qT1ZCVFNYTkpiVTU1V2xkR01GcFhVWFJpTWpScFQybEplVTFFU1hsTVZFRjVURlJ\
3166       KZVZaRVFUTlBhazE2VDJwQk5FeHFSVFZPYkc5cFRFTkthRm95Vm5Wa1F6RjNZMjA1TW1\
3167       GWFVteGFRekYzWTIwNU5HRlhNWEJrU0d0MFkyMVdibUZZVGpCamJVWjVURmRPYkdOdVV\
3168       XbFBhVXBPVTFWc1JGSkdVa1JSTUVacFZESmtRbVF3YkVOUlYyUktVakJHV1ZkWVRuZFR\
3169       WMVoyVkZWR2RsSXdUa1JqVldSVVZGUlJOVkZyUms1Uk1ERkhaRE5vUkdWclJrdFJiV1J\
3170       QVm10S1FsZFdVa0poTUZwVFZGWktTbVF3VmtKWFZWSlhWVlpHVEZKRlJuTlViVlpXVkc\
3171       1YWFWZEZTbTlaYlRWeVpVVmFWVkZXVWtOYU1EVlhVV3RHZWxSVlVrWk5WRlpXVFRGYWN\
3172       GbDZTbk5oTWtaWVVtNXNiRlpGVmxGVVZVVjNVakJGZUZaVlZrTmtNMlJJVmtab2MxWkh\
3173       SbGxWYlhoT1ZXdFdNMUpJWkZwU1JscFNWVlZTUlZGWGFFOWFWbHBQWTBkU1NGWnJVbEp\
3174       XUlVac1VtNWpkMlZWTVVWU1dHeE9Va1pHTTFSdWNFcE5WVFZGWVVkR1IyUjZRalpVVlZ\
3175       KR1pWVXhSVlZZWkU5bGEydDRWR3RTYjFsVk1VaFRXR2hFWld0R1MxRnRaRTlXYTBwQ1Y\
3176       xWlNRbUV3V2xOVVZrcEtaREJXUWxkVlVsZFZWa1pNVWtWR2MxUnRWbFpVYmxwcFYwVkt\
3177       iMWx0TlhKbFJWcEZVVlpPUTFvd05WZFJhMFo2VkZWTmQwMVVWbFpOTVZwd1dYcEtjMkV\
3178       4YkZsVGFsWk9WVlJvTTFKR1JscFNSbHBTVlZWb1JWRldjRTlhVmxwUFkwZFNTRlpZYUV\
3179       oU1JVWllVVzFrVDFaclNrSlVWVEZGVFVSRk1WWlVTbk5OUm5CWFUyMTRZVTF0ZURaYVJ\
3180       XaExZVWRPY1ZGc2NFNVJhekZJVVc1c2VGSXhUazVPUkd4Q1dqQldTRkV3VG5oU01VNU9\
3181       Ua1JzUW1Rd1ZrbFJWRUpLVVZWS1NsVklhRmhrVlRGSlVucG9TMVJIV2taVlJVVTFUMWh\
3182       hZDAxdVZrbFNWVFZxVlROc2JWa3pWVE5VUjJSYVRraEJlRTVGUmtOT01GSk9XbFJGTkU\
3183       xSVRrWmxSV1J4VkZOME0yTnJOVFJPTURVMVdWaE9lRXQ2Um5CTlJXUlVVVEZKTlU1VVV\
3184       UTk5SRVp0VWpKV1dGUldSbWxqVjNCWVpXdEtZVlJWU1hkU01FVjRWbGRTUzFWV1JsaFV\
3185       WVXBTVWpCT1JHTXdaRUpWVmxaSFVXNWtUbEZyU201YU0wcERXakJXUjFGc1JtcFNSV2h\
3186       GVVZVNVExb3dOVmRUUmtVMFVXdEdiVTlGVmtOUlZURkVVV3BTUW1Rd2RFSlhWVkpYVld\
3187       wQ1UxRnJUa1prTUdjd1UxZFNhVmRIZURaWlZtaFRZa2RPZEZadE5XaFhSVFIzV1RJeFI\
3188       yVlZlSFJOVkZaYVRXcHNNRmt3WkVka1YxWlVUbGR3YVUxcVFqTlJNbVJhVTFWMGRsZHJ\
3189       iRFpoYWtKR1VWaGtTbEpHVGtKUldHUlRWVlZzYjFGV1FqVlBXRnBOVTFkR01WVnJWbEp\
3190       qYlhnMVlteGtNRlI2VmxOaVZYQXdZVmhTVW1GNlpFOVhSRkpMVlVoV2RWVklRazlVYXp\
3191       BeFZWUnNRbUZWUm5sa1JVNTBWRVprWVZSVmJFMVdiRTEyVFZWc1JWbFhjR2xqTVU1Sll\
3192       tNXdkbUpYYjNkV1F6a3paVmhKY21Nd2RFdGpRM1IxVFhwU1VsQlVNR2xNUTBwb1dqSld\
3193       kV1JETVhwaFYyUjFXbGRSZEZwSFJqQlpVMGsyU1cxV05WTnVaRnBYUjNoNldXcEtSMkV\
3194       3YkhGaU1teGhWMGQ0VEZrd1duZFhWbFowVFZVeFdGSnVRWGxYYTFwclZESkplR05HYkZ\
3195       SWFJrcHhXV3hhWVU1R2NFZGFSbVJzWWxaS1JWUldhR3RoYlVwVlVWUktXRlp0VW5KWmE\
3196       yUkxaRlpXV1ZWdGNFNWlXR2d4VjFjd2VGWXlSWGRsUm1oV1lsZG9jbFZxUWxkalJsRjV\
3197       UbGh3YUZadGREWlZNakUwVjJ4a1IxTnVUbGhoTURFMFdrY3hTMk5HVGxWWGEzQm9ZVEo\
3198       zZWxaR1pIZFNiVkpHVFZaV1UxZEdTazlXYTFwM1ZteFNWbFZyY0U5aGVrVXlWVlpTWVZ\
3199       Sc1NrWlNha1pWVmxaS1ExcEVSbXRqUms1WlZHdHdhV0Y2Vm5wWFZFbDRZekpHU0ZOclV\
3200       rNVhSbHB5Vm01d1IyTkdaSE5oUlhCb1ZsUnNkMVV5TVhkWGJGbDRZMGhTV0dKRk1UTlV\
3201       iRlUxVWxac05sRnJPVlpOUnpneFYyMTRSbUZWZUVSVGJuQm9WakpTTVZkV2FGTk5WMDU\
3202       wVm01d1NtRnVRbWxhV0d4TFpESk9kRTlVUW1GV01EUjNWMnhrVW1GVk9YQlRiWGhzVmx\
3203       oQ2RsZFhkR3RoYlVaV1QxaENWR0V4Y0ZkYVYzUnlaVVpTZEdKRmNHcE5SM2d3V2tWb1E\
3204       xbFdSWGRoZWtwVVZqTm9kbFZ0ZEhwbFZsWlpVMnhTYVdKclNrcFdhMVpUVVcxV2MxSnV\
3205       VbFJpVlZwVlZXdGFjbVZzVFhwalJ6bFhUVlpHTmxkWWNFTmhiRWw1V1ROa1ZVMUdSak5\
3206       aVm1SaFZXdHNjR1F5YkdwTmJYaDFXVzB4UjAxSFVsbFRiWGhLWVcwNWNGZEVRazlsYXp\
3207       sV1QxWm9VMkpyY0dGWmJHTTFaV3hOZDA5WVZsSlhSMUpUVjFSR1YyRXhiM2RqUlZaWVV\
3208       qRndUVmxzVWt0WFZUbFhVMnhXVjFJd05URlVSazE0WXpGUmQwNVdRbWxTZWxaMlZqSjB\
3209       SazFGT1VaWGJYUlhZa2hCZDFReFVrOWhNbEY0Vld0d1YxWlVWbGRYUkVwaFYyczVWMWR\
3210       1UWxkaVJHdzFWWHBPVDFaV1JuSmhSa3BRVmpOQ2Vsa3haSHBsVjBsNldUSnNiVlpxUlR\
3211       WSmFYZHBXVmRrYkdKdVVYUmpNbXh1WW1reGFscFlTakJKYW5CaVNXc3hTbE5WVGt0U1J\
3212       VNUVVVmRPZUZvd1JqTlRWVXBDV2pCc1JsZEhlSEZSTURGRlVWVjBRMW95WkhoaFIzUnh\
3213       WREZDVWxWVlVrSmhhMHB6VkZaR2VtUXdUbEpYVlZKWFZWWkdTRkpZWkV0UmJGWlZVbFp\
3214       PVGxGclJraFJWRVpXVWxWT2JtUXdjRlZYUjNoRldXcEplR1F4YkZoT1ZGWk9WV3hXTTF\
3215       KWVpGcFNSbHBTVlZWNFJWRllhRTlhVmxwUFRWWnNkVlJ1UW1GU01uaHZXVEkxY21WRlV\
3216       qWlJWVFZEV2pBMVYxRnJSbXBVVlVweVRWUldWazF0ZDNkWGJGSkdXVlV4UTFvd1pFSk5\
3217       WbFpHVVZoa00xVnNVbGxpUmxKb1YwWktjMVpWYUZkbGJVWkdUVmhhWVZJeFducFZWRUp\
3218       HWkRCb2Ixa3dOVTVoYTBZelZGZHdTazVGTVVWWk0zQk9aV3RGZDFZeWFHcFVhekUyVVZ\
3219       oa1RtRnJhekJVVlZKcVpXc3hObEZVUWxoaGEwcDBWRlpHZW1Rd1RsSlhWVkpYVlZaR1N\
3220       GSllaRXRSYkZaVlVsWk9UbEZyUmtoUlZFWldVbFZPYm1Rd2NGVlhSM2hGV1dwSmVHUXh\
3221       iRmhPVkZaT1ZXeFdNMUpZWkZwU1JscFNWVlY0UlZGWWFFOWFWbHBQVFZac2RWUnVRbUZ\
3222       TTW5odldUSTFjbVZGVWpaUlZUVkRXakExVjFGclJtcFVWVXB5VFZSV1ZrMXRkM2RYYkZ\
3223       KR1dXc3hRMkV3WkVKTlZsWkdVVmhrTTFVeFVsbGlSbEpvVjBaS2MxWlZhRmRsYlVaR1R\
3224       WaGFZVkl4V25wVlZtaERaREF4UjJFelpFWmtNV3hKVXpJNVlWTlljSEZOUlU1Q1ZWWnN\
3225       TbE15T1dGVFdIQnhUVVZTUWxWWFRrVlZWMlJDVWxSWmQwMVZPSEppTW5CRVlUTktSVlZ\
3226       1WXpOYU1Hd3lWMnRWTUdGVVRUQmFSMHB2VVROR2NGSjZaSEZpTWprelYyNUJNR1ZJV2p\
3227       aU2JsSk5XbnBhVlZaNlFtOVViVkpKWkd4Q1JWVXhVbnBrVm1oVVpWWmpOV1JJU1hwUld\
3228       HUkVZa2RhUkdJd1VsZFVia1pRWkhwc05WUldaekpVYlRWT1VqRldNMUpIWkZwU1JscFR\
3229       UVVpDUWxWVlozWlJhMFpTVWtWR2JscFZSazVSYW1oSVVWUkdWbHBGYkROVlZteE9VVzF\
3230       HUWxKcmJ6TlRTRkpVWkROQ1RWUklWbEJYYW1ScVlUQkdjMVZWYUZaTk1tUkNWRmRqZGx\
3231       Ock1VTk5SV1JDVFZaV2ExSkhaRkpXTUVwRFZXMU9WVTVVVFRCaWF6RmFaR3hTYWxKdVV\
3232       uSmFia295VGpOb1ZrNHdVbkJpVldoeFpXdEdWVkZ0WkU5V2EyaFVWbFZXUlZKRlJreFJ\
3233       iV1J1WTJ0S2JsSlZXa05WVjA1RlVWZHdRbE13U201YU0wWnZZVEp3VUZWR1JsSlNSVVp\
3234       1Vkd0c1FsSkZTa2RSVjJ4R1VWaENTMDR6YUhkVWJGWXlWVlZ3U0UxRk5XOVVSMGwyV2x\
3235       oU2FVMXFRazFTUmxWNFRtMTRkMVV3YUZCT01rWnNZbnBDVjFkWVozZGxTR1JFVTFWRmN\
3236       sUjZWWFpYVkZwRllVTjBhVkZxU1RSTmFsSXhZVmRHVUZWWFJsWlNSRnB1VVZVMWIxZFV\
3237       iRmRTYlZGeVlXNUtlVmt3VmpKVGJsRnBURU5LVGxOVmJFUlNNVkpFVVRCR2FVc3laRUp\
3238       rTUd4RFVWZGtTbEpXYUhOaGEwVjJaV3RHVEZGdFpHNWpWMmh5WVdzNVVWVldSa1ZSVjN\
3239       CRFdUQXhVbU16WkVSVlZteEZWbXhHVWxJd1ZqTlRhMHBXVmtWV1ZGUlZTa0pTTUVWNFZ\
3240       sVldSRm96WkV0V1JtaHpVa2RKZVUxWVpGcFdlbFV4VkZaS1ZtUXdWak5YVlZKWFZWWkd\
3241       UVkpGUmpSVWJWWlhWR3BHV21Kck5YZFhhMlJ6WVVkT2RXRXphRVZsYTBaUFVXMWtUMVp\
3242       yU2tKWk1ERkRZWHBGTVZaVVNuTk5SbkJWVWxaS1RsRlVhRWhSVkVaV1VsVkdNMlF3YkZ\
3243       WWFIzaFZXVlpvVTJKR1JYZFNXR1JKWVVkT1QxUlhjRUprTURGeFUxUlNUbEpIVGpWVWJ\
3244       uQldUbFprYjFrd05VNWxhMFl6VkZkd1NrNUZNVVZaTTJ4UFpXeFZNVll5Y0VOaVJURlN\
3245       Zek5rUkZWV2JFVldiRVpTVWpCV00xTnJTbFpXUlZaVVZGVktRbEl3UlhoV1ZWWkVXak5\
3246       rUzFaR2FITlNSMGw1VFZoa1dsWjZWVEZVVmtwV1pEQldNMWRWVWxkVlZrWk5Va1ZHTkZ\
3247       SdFZsZFVha1phWW1zMWQxZHJaSE5oUjA1MVlUTm9SV1ZyUms5UmJXUlBWbXRLUWxrd01\
3248       VTmhla1V4VmxSS2MwMUdjRlZTVjBaT1VXMWtTRkZVUmxaU1ZVWXpaREZLVlZkSGVGVlp\
3249       WbWhUWWtaV1NWWnVjR2hTVkVZeVYydGtWMk14UlhkU1dHUllWa1ZHVlZGdFpHcGpWMmh\
3250       5WVdzNVVWVlZiRU5SYldSdVkxZG9jbUZyT1ZGVlZURkRVVzVrVDFFd1JrSlZhM0JEVm0\
3251       wNWVscEZkRE5YVlRVMFlWWkNORk5JV25CU2JrWk1aV3RTYzA5WFdqQlVTRlpPV1ZjeGQ\
3252       xSnNSbXBYU0dONFRXcGthRlJ0T1ZOWmJrNUpUREJhVG1OdE1UWlJNRVpKVFhwak0wMTZ\
3253       UbXBOYlRscFZVZE9jMlJzVG5sWFZVb3lUVVZPTUZZeFJqQlpWRnBvU3pKT2RrMXNiRE5\
3254       YYTFKQ1ZUQktibFJzV2tsVmF6RkRVVmRaTkZKVlRrVlJWV1JDVlZWbmRsRlhaRVpSVlR\
3255       GQ1RrVmtRazFXVm10U1NHUkdVV2s1TTFWVlZrSmtNR3hFVVd0U1FscHJTbTVVYkZwSlZ\
3256       UQXhSbEl3VWtKV01tUkRWVmh3TkdWdVpIZFZia0pOWlZNNWVWUldWbHBsYlVadlRXNU5\
3257       lRTB5VmxaUFYyUkhaV3RHYTFGdFpFOVdhMmhTVGtWV1Ixb3hSbFppYms1c1RWVjRSR0V\
3258       6VGpGT1JGWjFaRWhzVWxFeFdrSmFSbEpzVVZWR05WSkVhSEprTUU1dVYxVnNUR0l4Y0V\
3259       wbGJXOTNVbFZHTTFOVlVsUlJWVVl6Vld4R1NtRkZSa3BqTVd4eldsWndUR015Y0VkVWE\
3260       wNTZVMnQwYkZWSGVFaFVWVVpOV2xoQ1YxcFViRVpVUkdSUFlqTlJNVTFVVmpObFJ6Rlh\
3261       aRlZ3UTFGWGJFSlpNRlpPVmxaV2IxSldUbnBVUm1SUlRsaG9WRlZXVlhkWFNFWTJWbTV\
3262       GTkZkWVduQlNha1pwVm0wNU5sSXpjRFJPV0hCUFdqSk9lbVI2TURsSmJERTVabEVpTEN\
3263       KemFXZHVZWFIxY21WeklqcGJleUp3Y205MFpXTjBaV1FpT2lKbGVVbzBUbGROYVU5c2M\
3264       ybFVWV3hLVVRCb2NWRXdUa0paTVU1dVVWaGtTbEZyUm01VFZXUkNWMGRvTUUxVVVucGl\
3265       NREZDWWpCa1JGRXpSa2hWTURBd1QxVktRbFJWVGs1U1ZtdzBVVE53UWxOclNtNVViRnB\
3266       EVVZac1ZWRlhkRTlUVlRGVFZGaGtSbFZXYkVWV2JFWlNVekJTUW1OR1VtaFdNVm93VjJ\
3267       4ak1XVnJiRVpTYTJoT1ZWUm9NMUpHUmxwU1JscFNWVlY0UlZGV2NFUldhMDVEVWtaV1I\
3268       xUllhRVpXUlVaUlVXMWtUMVpyU2tKVVZURkVVbXh3YzFsdE1WTmtiVTV5Vkd0S1RsRXd\
3269       SbGxTUmxKS1pVVXhSVlJZYkU5aGEwVXhWRmR3U21WVk5WZGlNV3hGWlcxek1WUXhVbkp\
3270       sUlRGeFZGaG9UbUZyTUhoVU1WSldUbFprY1ZGdGFFNVZXRTR6VVRGR1dsSkdXbEpWVld\
3271       SR1pEQndSVlV3VWtaV1JURkRVbFZrUWsxV1ZrWlJNbVF6VXpGVmVXSkhlR2xXTVZveFd\
3272       UTnNRMUZzU2paU1ZrSk9VVlJDU0ZGVVJsWlNWVTR6WkRCa1VtSkdSbTVWVkVaRFZrVXh\
3273       VMVZZWkVaYU1XeEZWbXhHVWxKclZqTmtSM0JhVmpGd2RGZHNUWGRPVlRsRldYcENUMVp\
3274       GVmxoVVZVcFNVakJGZUZaVlZrSmtNMlJQVmxWYWIxSkZNVFZPVlZwUFpXeFdNRlJXVWt\
3275       Ka01VWlZVV3h3VGxGck1VaFJibXg0VWpGT1RrNUViRUphTUZaSVVUQk9lRkl4VGs1T1J\
3276       HeENaREJXU1ZGVVFrcFJWVXBQVFVSb2NWWXdlSHBOUjBadlV6Qm9XbGR1Vm05aVZ6Rmp\
3277       UREpqTkdScVVsaFRNR2d5VVZoU2FGcHNSazFSVTNSS1pGVXhUMkZITVc1aFZ6RllUakJ\
3278       HVG1OdVJtOWlWMHBWVFRCc2FGVkZUalZoUnpGaFUxWk9kMVI2V20xaVUzTXlVMWhhWTB\
3279       3eldrcGphM1J2VlZaU01WWnRPVXhoYldSYVVWaGtiV0ZyUm5aUmJXUnVZMnRLYmxKVld\
3280       rTlZWMDVEVTFWR1Vsa3dVa05qU0ZKYVYwVTFiMVJHYUZOaVIwMTZWVmhXYWsxdGVITlp\
3281       iR1JYWkZkT05VNVhjR2xOYWtFeVZERlNVazFGTVRaUlZsSkRXakExVjFOR1RsWlNWVkp\
3282       GVVZWMFExb3laSGxSYldSR1VtdEtVbGt3VWtKV1JVWlFVVzFrVDFacmFGSlBSVXBDV21\
3283       wb1JsRnJSazVSTUVrd1VWaGtUVlZXYkVWV2JFbDNWV3RLUkZkWVpFdFRWV3h3V2tWa2I\
3284       ySkZlSFZYYlhocFlsWktNbGt5YXpGaGJHeFlUa2hXYVdKVWEzZFVSekV3WkZkSmVsa3p\
3285       WbXRTTW1oM1dUTnJNVTFzYkZobFJFWmhWa1ZHVEZGdFpHNWpWMmh5WVdzNVVWVldSa1Z\
3286       SVjJSUFUxVkdSVkZyV2tKaFZVazFVVzB4ZUZRemNIRlZWR2hzV1ZkamVWTnVVblprVmx\
3287       KdlVsWm9lVm93T1VOWFZsRjNVWHBvWVdSRGREVlBWemxKVWtad1JWbHNVbEpUVjJoQ1Z\
3288       HMXpNbVJIT1ZOaU1sWkVXVmMxYUZSWGNFNVdSWGgwWWxaV2RXSlhTbkphYWtKNldsaGF\
3289       jbEV3YnpSTmJXc3hWbGhHY1ZWcldsZFZVMHBrVEVOS2FHSkhZMmxQYVVwR1ZYcEpNVTV\
3290       wU2praUxDSnphV2R1WVhSMWNtVWlPaUphWTFwa1dYbzBiMUl3UjJKc09UWnFNWGxZWm5\
3291       kdlRYZGxVVGt6VGpCdFNVUmxjVFkyVTBacWRFdG9lR1pSWjNJMGRUWkpOVEJKWldNMmE\
3292       xWTJhSEV3YVcxdlptTlBhVGs0VW1OSVpXUmpNVzFuZHpCWVp5SjlYWDA9IiwiY3JlYXR\
3293       lZC1vbiI6IjIwMjItMDItMjJUMDc6MzM6MjUuMDIwWiIsImFnZW50LXNpZ24tY2VydCI\
3294       6WyJNSUlDSkRDQ0FjcWdBd0lCQWdJRVhsakNNREFLQmdncWhrak9QUVFEQWpCbE1Rc3d\
3295       DUVlEVlFRR0V3SkJVVEVTTUJBR0ExVUVDZ3dKVFhsRGIyMXdZVzU1TVJVd0V3WURWUVF\
3296       MREF4TmVWTjFZbk5wWkdsaGNua3hEekFOQmdOVkJBY01CazE1VTJsMFpURWFNQmdHQTF\
3297       VRUF3d1JUWGxUYVhSbFVIVnphRTF2WkdWc1EwRXdIaGNOTWpBd01qSTRNRGN6TXpBMFd\
3298       oY05NekF3TWpJNE1EY3pNekEwV2pCbU1Rc3dDUVlEVlFRR0V3SkJVVEVTTUJBR0ExVUV\
3299       DZ3dKVFhsRGIyMXdZVzU1TVJVd0V3WURWUVFMREF4TmVWTjFZbk5wWkdsaGNua3hEekF\
3300       OQmdOVkJBY01CazE1VTJsMFpURWJNQmtHQTFVRUF3d1NUWGxUYVhSbFVIVnphRTF2Wkd\
3301       Wc1FYQndNRmt3RXdZSEtvWkl6ajBDQVFZSUtvWkl6ajBEQVFjRFFnQUU2MDFPK29qQ2t\
3302       yRFJ3N2dJdlpFNGkzNGRiaENxaUc3am9vd1pwNHh2ekZ0TGc2VFcwaE5kSHZQRFNUc3V\
3303       YU3lXOXRyM0F3Q2xmQ29EVk5xT3c5eU1YNk5uTUdVd0RnWURWUjBQQVFIL0JBUURBZ2V\
3304       BTUI4R0ExVWRJd1FZTUJhQUZKN0h0U3dwTEx1T1o3Y2tBbFFIVTNnQU1nL0pNQjBHQTF\
3305       VZERnUVdCQlJjVDUzNG5NWXZUY0Z0a2Zydjd4VTdEaW1IanpBVEJnTlZIU1VFRERBS0J\
3306       nZ3JCZ0VGQlFjREFqQUtCZ2dxaGtqT1BRUURBZ05JQURCRkFpRUFwSjd4cE5VdlFKRzB\
3307       OaExiL2V0YjIwTERVMTZscFNITzdhZW8wVll4MHh3Q0lBK081L1k2RGgrYkIyODI0dWl\
3308       hT1FhVUQ2Z0FOaFk5VkZkK2pycmNFdkp0IiwiTUlJQ0dUQ0NBYitnQXdJQkFnSUVYbGp\
3309       BL3pBS0JnZ3Foa2pPUFFRREFqQmNNUXN3Q1FZRFZRUUdFd0pCVVRFU01CQUdBMVVFQ2d\
3310       3SlRYbERiMjF3WVc1NU1SVXdFd1lEVlFRTERBeE5lVk4xWW5OcFpHbGhjbmt4RHpBTkJ\
3311       nTlZCQWNNQmsxNVUybDBaVEVSTUE4R0ExVUVBd3dJVFhsVGFYUmxRMEV3SGhjTk1qQXd\
3312       Nakk0TURjeU56VTVXaGNOTXpBd01qSTRNRGN5TnpVNVdqQmxNUXN3Q1FZRFZRUUdFd0p\
3313       CVVRFU01CQUdBMVVFQ2d3SlRYbERiMjF3WVc1NU1SVXdFd1lEVlFRTERBeE5lVk4xWW5\
3314       OcFpHbGhjbmt4RHpBTkJnTlZCQWNNQmsxNVUybDBaVEVhTUJnR0ExVUVBd3dSVFhsVGF\
3315       YUmxVSFZ6YUUxdlpHVnNRMEV3V1RBVEJnY3Foa2pPUFFJQkJnZ3Foa2pPUFFNQkJ3TkN\
3316       BQVJKQlZvc2RLd1lOeGlQeEh2aUZxS3pEbDlmdEx1TWFtcEZRY1h3MTI3YU5vUmJzSC9\
3317       GTXJtekNBSDM3NzMzYzJvYlBjbHZTcllCdjBDdFdRdGE2YStjbzJZd1pEQVNCZ05WSFJ\
3318       NQkFmOEVDREFHQVFIL0FnRUFNQTRHQTFVZER3RUIvd1FFQXdJQ0JEQWZCZ05WSFNNRUd\
3319       EQVdnQlF6eHp3cFJwTHkvck1VWXphaDJzMTNlVTlnRnpBZEJnTlZIUTRFRmdRVW5zZTF\
3320       MQ2tzdTQ1bnR5UUNWQWRUZUFBeUQ4a3dDZ1lJS29aSXpqMEVBd0lEU0FBd1JRSWhBSXN\
3321       ZbGVaS3NqRk5Dc0pLZVBsR01BTGVwVmU5RUw3Tm90NTE1d3htVnVKQkFpQWNFTVVVaEV\
3322       Tc0xXUDV4U1FVMFhxelZxOFl2aUYxYlZvekd6eDV6Tmdjc3c9PSJdfX0",
3323         "signatures":[{
3324           "protected":"eyJ4NWMiOlsiTUlJQjhEQ0NBWmFnQXdJQkFnSUdBWEJoTUtZSU1\
3325       Bb0dDQ3FHU000OUJBTUNNRnd4Q3pBSkJnTlZCQVlUQWtGUk1SSXdFQVlEVlFRS0RBbE5\
3326       lVU52YlhCaGJua3hGVEFUQmdOVkJBc01ERTE1VTNWaWMybGthV0Z5ZVRFUE1BMEdBMVV\
3327       FQnd3R1RYbFRhWFJsTVJFd0R3WURWUVFEREFoTmVWTnBkR1ZEUVRBZUZ3MHlNREF5TWp\
3328       Bd05qQXlNak5hRncwek1EQXlNakF3TmpBeU1qTmFNSGt4Q3pBSkJnTlZCQVlUQWtGUk1\
3329       SSXdFQVlEVlFRS0RBbE5lVU52YlhCaGJua3hGVEFUQmdOVkJBc01ERTE1VTNWaWMybGt\
3330       hV0Z5ZVRFUE1BMEdBMVVFQnd3R1RYbFRhWFJsTVM0d0xBWURWUVFERENWU1pXZHBjM1J\
3331       5WVhJZ1ZtOTFZMmhsY2lCU1pYRjFaWE4wSUZOcFoyNXBibWNnUzJWNU1Ga3dFd1lIS29\
3332       aSXpqMENBUVlJS29aSXpqMERBUWNEUWdBRUJUVFwvc1JmTDlsSnVGbVwvY24zU2pHcWp\
3333       QXC9xdnBrNytoSTIwOE5oVkRvR2hcLzdLUCt2TXpYeVFRQStqUjZrNnJhTTI4ZlwvbHV\
3334       FK1h1aHVwN1Vmem05Q3FNbk1DVXdFd1lEVlIwbEJBd3dDZ1lJS3dZQkJRVUhBeHd3RGd\
3335       ZRFZSMFBBUUhcL0JBUURBZ2VBTUFvR0NDcUdTTTQ5QkFNQ0EwZ0FNRVVDSUhOK3VBbUp\
3336       ldVhlc1wveWQxd1M0Mlo0RFhKNEptMWErZzNYa1pnZjhUaGxuQWlFQXBVdTZzZnljRWt\
3337       veDdSWlhtZitLOHc0cDZzUldyamExUVJwWTAyNjQxSFk9IiwiTUlJQjhEQ0NBWmVnQXd\
3338       JQkFnSUdBWEJoTUtZQk1Bb0dDQ3FHU000OUJBTUNNRnd4Q3pBSkJnTlZCQVlUQWtGUk1\
3339       SSXdFQVlEVlFRS0RBbE5lVU52YlhCaGJua3hGVEFUQmdOVkJBc01ERTE1VTNWaWMybGt\
3340       hV0Z5ZVRFUE1BMEdBMVVFQnd3R1RYbFRhWFJsTVJFd0R3WURWUVFEREFoTmVWTnBkR1Z\
3341       EUVRBZUZ3MHlNREF5TWpBd05qQXlNak5hRncwek1EQXlNakF3TmpBeU1qTmFNRnd4Q3p\
3342       BSkJnTlZCQVlUQWtGUk1SSXdFQVlEVlFRS0RBbE5lVU52YlhCaGJua3hGVEFUQmdOVkJ\
3343       Bc01ERTE1VTNWaWMybGthV0Z5ZVRFUE1BMEdBMVVFQnd3R1RYbFRhWFJsTVJFd0R3WUR\
3344       WUVFEREFoTmVWTnBkR1ZEUVRCWk1CTUdCeXFHU000OUFnRUdDQ3FHU000OUF3RUhBMEl\
3345       BQkluQ3VoV1ZzZ2NONzFvWmVzMUZHXC9xZFZnTVBva01wZlMyNzFcL2V5SWNcL29EVmJ\
3346       NRkhDYmV2SjVMTTgxOTVOYVpLTlNvSFAzS3dMeXVCaDh2MncwOVp1alJUQkRNQklHQTF\
3347       VZEV3RUJcL3dRSU1BWUJBZjhDQVFFd0RnWURWUjBQQVFIXC9CQVFEQWdJRU1CMEdBMVV\
3348       kRGdRV0JCUXp4endwUnBMeVwvck1VWXphaDJzMTNlVTlnRnpBS0JnZ3Foa2pPUFFRREF\
3349       nTkhBREJFQWlCZGJIU212YW9qaDBpZWtaSUtOVzhRMGxTbGI1K0RLTlFcL05LY1I3dWx\
3350       6dGdJZ2RwejZiUkYyREZtcGlKb3JCMkd5VmE4YVdkd2xIc0RvRVdZY0k0UEdKYmc9Il0\
3351       sImFsZyI6IkVTMjU2In0",
3352           "signature":"67t3n8zyEek4IM2Ko3Y_UvE1hzp794QFNTqG-HzTrBQtE4_4-yS\
3353       yyFd3kP6YCn35YYJ7yK35d3styo_yoiPfKA"
3354         }]
3355       }

3357                 Figure 24: Example Registrar Voucher Request - RVR

3359    A.3.  Example Voucher Response (from MASA to Pledge, via Registrar and
3360          Registrar-agent)

3362       The following is an example voucher response from MASA to Pledge via
3363       Registrar and Registrar-agent, in "General JWS JSON Serialization".
3364       The message size of this Voucher is: 1916 bytes
3365       =============== NOTE: '\' line wrapping per RFC 8792 ================

3367       {
3368         "payload":"eyJpZXRmLXZvdWNoZXI6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJhZ2V\
3369       udC1wcm94aW1pdHkiLCJzZXJpYWwtbnVtYmVyIjoiMDEyMzQ1Njc4OSIsIm5vbmNlIjo\
3370       iTDNJSjZocHRIQ0lRb054YWFiOUhXQT09IiwiY3JlYXRlZC1vbiI6IjIwMjItMDQtMjZ\
3371       UMDU6MTY6MjguNzI2WiIsInBpbm5lZC1kb21haW4tY2VydCI6Ik1JSUJwRENDQVVtZ0F\
3372       3SUJBZ0lHQVcwZUx1SCtNQW9HQ0NxR1NNNDlCQU1DTURVeEV6QVJCZ05WQkFvTUNrMTV\
3373       RblZ6YVc1bGMzTXhEVEFMQmdOVkJBY01CRk5wZEdVeER6QU5CZ05WQkFNTUJsUmxjM1J\
3374       EUVRBZUZ3MHhPVEE1TVRFd01qTTNNekphRncweU9UQTVNVEV3TWpNM016SmFNRFV4RXp\
3375       BUkJnTlZCQW9NQ2sxNVFuVnphVzVsYzNNeERUQUxCZ05WQkFjTUJGTnBkR1V4RHpBTkJ\
3376       nTlZCQU1NQmxSbGMzUkRRVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUF\
3377       CT2t2a1RIdThRbFQzRkhKMVVhSTcrV3NIT2IwVVMzU0FMdEc1d3VLUURqaWV4MDYvU2N\
3378       ZNVBKaWJ2Z0hUQitGL1FUamdlbEhHeTFZS3B3Y05NY3NTeWFqUlRCRE1CSUdBMVVkRXd\
3379       FQi93UUlNQVlCQWY4Q0FRRXdEZ1lEVlIwUEFRSC9CQVFEQWdJRU1CMEdBMVVkRGdRV0J\
3380       CVG9aSU16UWRzRC9qLytnWC83Y0JKdWNIL1htakFLQmdncWhrak9QUVFEQWdOSkFEQkd\
3381       BaUVBdHhRMytJTEdCUEl0U2g0YjlXWGhYTnVocVNQNkgrYi9MQy9mVllEalE2b0NJUUR\
3382       HMnVSQ0hsVnEzeWhCNThUWE1VYnpIOCtPbGhXVXZPbFJEM1ZFcURkY1F3PT0ifX0",
3383         "signatures":[{
3384           "protected":"eyJ4NWMiOlsiTUlJQmt6Q0NBVGlnQXdJQkFnSUdBV0ZCakNrWU1\
3385       Bb0dDQ3FHU000OUJBTUNNRDB4Q3pBSkJnTlZCQVlUQWtGUk1SVXdFd1lEVlFRS0RBeEt\
3386       hVzVuU21sdVowTnZjbkF4RnpBVkJnTlZCQU1NRGtwcGJtZEthVzVuVkdWemRFTkJNQjR\
3387       YRFRFNE1ERXlPVEV3TlRJME1Gb1hEVEk0TURFeU9URXdOVEkwTUZvd1R6RUxNQWtHQTF\
3388       VRUJoTUNRVkV4RlRBVEJnTlZCQW9NREVwcGJtZEthVzVuUTI5eWNERXBNQ2NHQTFVRUF\
3389       3d2dTbWx1WjBwcGJtZERiM0p3SUZadmRXTm9aWElnVTJsbmJtbHVaeUJMWlhrd1dUQVR\
3390       CZ2NxaGtqT1BRSUJCZ2dxaGtqT1BRTUJCd05DQUFTQzZiZUxBbWVxMVZ3NmlRclJzOFI\
3391       wWlcrNGIxR1d5ZG1XczJHQU1GV3diaXRmMm5JWEgzT3FIS1Z1OHMyUnZpQkdOaXZPS0d\
3392       CSEh0QmRpRkVaWnZiN294SXdFREFPQmdOVkhROEJBZjhFQkFNQ0I0QXdDZ1lJS29aSXp\
3393       qMEVBd0lEU1FBd1JnSWhBSTRQWWJ4dHNzSFAyVkh4XC90elVvUVwvU3N5ZEwzMERRSU5\
3394       FdGNOOW1DVFhQQWlFQXZJYjNvK0ZPM0JUbmNMRnNhSlpSQWtkN3pPdXNuXC9cL1pLT2F\
3395       FS2JzVkRpVT0iXSwiYWxnIjoiRVMyNTYifQ",
3396           "signature":"0TB5lr-cs1jqka2vNbQm3bBYWfLJd8zdVKIoV53eo2YgSITnKKY\
3397       TvHMUw0wx9wdyuNVjNoAgLysNIgEvlcltBw"
3398         }]
3399       }

3401                   Figure 25: Example Voucher Response from MASA

3403    A.4.  Example Voucher Response, MASA issued Voucher with additional
3404          Registrar signature (from MASA to Pledge, via Registrar and
3405          Registrar-agent)

3407       The following is an example voucher response from MASA to Pledge via
3408       Registrar and Registrar-agent, in "General JWS JSON Serialization".
3409       The message size of this Voucher is: 3006 bytes
3410       =============== NOTE: '\' line wrapping per RFC 8792 ================

3412       {
3413         "payload":"eyJpZXRmLXZvdWNoZXI6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJhZ2V\
3414       udC1wcm94aW1pdHkiLCJzZXJpYWwtbnVtYmVyIjoiMDEyMzQ1Njc4OSIsIm5vbmNlIjo\
3415       iUUJiSXMxNTJzbkFvVzdSeVFMWENvZz09IiwiY3JlYXRlZC1vbiI6IjIwMjItMDktMjl\
3416       UMDM6Mzc6MjYuMzgyWiIsInBpbm5lZC1kb21haW4tY2VydCI6Ik1JSUJwRENDQVVtZ0F\
3417       3SUJBZ0lHQVcwZUx1SCtNQW9HQ0NxR1NNNDlCQU1DTURVeEV6QVJCZ05WQkFvTUNrMTV\
3418       RblZ6YVc1bGMzTXhEVEFMQmdOVkJBY01CRk5wZEdVeER6QU5CZ05WQkFNTUJsUmxjM1J\
3419       EUVRBZUZ3MHhPVEE1TVRFd01qTTNNekphRncweU9UQTVNVEV3TWpNM016SmFNRFV4RXp\
3420       BUkJnTlZCQW9NQ2sxNVFuVnphVzVsYzNNeERUQUxCZ05WQkFjTUJGTnBkR1V4RHpBTkJ\
3421       nTlZCQU1NQmxSbGMzUkRRVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUF\
3422       CT2t2a1RIdThRbFQzRkhKMVVhSTcrV3NIT2IwVVMzU0FMdEc1d3VLUURqaWV4MDYvU2N\
3423       ZNVBKaWJ2Z0hUQitGL1FUamdlbEhHeTFZS3B3Y05NY3NTeWFqUlRCRE1CSUdBMVVkRXd\
3424       FQi93UUlNQVlCQWY4Q0FRRXdEZ1lEVlIwUEFRSC9CQVFEQWdJRU1CMEdBMVVkRGdRV0J\
3425       CVG9aSU16UWRzRC9qLytnWC83Y0JKdWNIL1htakFLQmdncWhrak9QUVFEQWdOSkFEQkd\
3426       BaUVBdHhRMytJTEdCUEl0U2g0YjlXWGhYTnVocVNQNkgrYi9MQy9mVllEalE2b0NJUUR\
3427       HMnVSQ0hsVnEzeWhCNThUWE1VYnpIOCtPbGhXVXZPbFJEM1ZFcURkY1F3PT0ifX0",
3428         "signatures":[{
3429           "protected":"eyJ4NWMiOlsiTUlJQmt6Q0NBVGlnQXdJQkFnSUdBV0ZCakNrWU1\
3430       Bb0dDQ3FHU000OUJBTUNNRDB4Q3pBSkJnTlZCQVlUQWtGUk1SVXdFd1lEVlFRS0RBeEt\
3431       hVzVuU21sdVowTnZjbkF4RnpBVkJnTlZCQU1NRGtwcGJtZEthVzVuVkdWemRFTkJNQjR\
3432       YRFRFNE1ERXlPVEV3TlRJME1Gb1hEVEk0TURFeU9URXdOVEkwTUZvd1R6RUxNQWtHQTF\
3433       VRUJoTUNRVkV4RlRBVEJnTlZCQW9NREVwcGJtZEthVzVuUTI5eWNERXBNQ2NHQTFVRUF\
3434       3d2dTbWx1WjBwcGJtZERiM0p3SUZadmRXTm9aWElnVTJsbmJtbHVaeUJMWlhrd1dUQVR\
3435       CZ2NxaGtqT1BRSUJCZ2dxaGtqT1BRTUJCd05DQUFTQzZiZUxBbWVxMVZ3NmlRclJzOFI\
3436       wWlcrNGIxR1d5ZG1XczJHQU1GV3diaXRmMm5JWEgzT3FIS1Z1OHMyUnZpQkdOaXZPS0d\
3437       CSEh0QmRpRkVaWnZiN294SXdFREFPQmdOVkhROEJBZjhFQkFNQ0I0QXdDZ1lJS29aSXp\
3438       qMEVBd0lEU1FBd1JnSWhBSTRQWWJ4dHNzSFAyVkh4XC90elVvUVwvU3N5ZEwzMERRSU5\
3439       FdGNOOW1DVFhQQWlFQXZJYjNvK0ZPM0JUbmNMRnNhSlpSQWtkN3pPdXNuXC9cL1pLT2F\
3440       FS2JzVkRpVT0iXSwidHlwIjoidm91Y2hlci1qd3MranNvbiIsImFsZyI6IkVTMjU2In0\
3441       ",
3442           "signature":"ShqW8uFRkuAXIzjAhB4bolMMndcY7GYq3Kbo94yvGtjCaxEX3Hp\
3443       6QXZUTEJ_kulQ1G7DnaU4igDPdUGtcV9Lkw"},{
3444           "protected":"eyJ4NWMiOlsiTUlJQjRqQ0NBWWlnQXdJQkFnSUdBWFk3MmJiWk1\
3445       Bb0dDQ3FHU000OUJBTUNNRFV4RXpBUkJnTlZCQW9NQ2sxNVFuVnphVzVsYzNNeERUQUx\
3446       CZ05WQkFjTUJGTnBkR1V4RHpBTkJnTlZCQU1NQmxSbGMzUkRRVEFlRncweU1ERXlNRGN\
3447       3TmpFNE1USmFGdzB6TURFeU1EY3dOakU0TVRKYU1ENHhFekFSQmdOVkJBb01DazE1UW5\
3448       WemFXNWxjM014RFRBTEJnTlZCQWNNQkZOcGRHVXhHREFXQmdOVkJBTU1EMFJ2YldGcGJ\
3449       sSmxaMmx6ZEhKaGNqQlpNQk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VIQTBJQUJCazE\
3450       2S1wvaTc5b1JrSzVZYmVQZzhVU1I4XC91czFkUFVpWkhNdG9rU2RxS1c1Zm5Xc0JkK3F\
3451       STDdXUmZmZVdreWdlYm9KZklsbHVyY2kyNXduaGlPVkNHamV6QjVNQjBHQTFVZEpRUVd\
3452       NQlFHQ0NzR0FRVUZCd01CQmdnckJnRUZCUWNESERBT0JnTlZIUThCQWY4RUJBTUNCNEF\
3453       3U0FZRFZSMFJCRUV3UDRJZGNtVm5hWE4wY21GeUxYUmxjM1F1YzJsbGJXVnVjeTFpZEM\
3454       1dVpYU0NIbkpsWjJsemRISmhjaTEwWlhOME5pNXphV1Z0Wlc1ekxXSjBMbTVsZERBS0J\
3455       nZ3Foa2pPUFFRREFnTklBREJGQWlCeGxkQmhacTBFdjVKTDJQcldDdHlTNmhEWVcxeUN\
3456       PXC9SYXVicEM3TWFJRGdJaEFMU0piZ0xuZ2hiYkFnMGRjV0ZVVm9cL2dHTjBcL2p3ekp\
3457       aMFNsMmg0eElYazEiXSwidHlwIjoidm91Y2hlci1qd3MranNvbiIsImFsZyI6IkVTMjU\
3458       2In0",
3459           "signature":"N4oXV48V6umsHMKkhdSSmJYFtVb6agjD32uXpIlGx6qVE7Dh0-b\
3460       qhRRyjnxp80IV_Fy1RAOXIIzs3Q8CnMgBgg"
3461         }]
3462       }

3464           Figure 26: Example Voucher Response from MASA, with additional
3465                                Registrar signature

3467    Appendix B.  History of Changes [RFC Editor: please delete]

3469       Proof of Concept Code available

3471       From IETF draft 05 -> IETF draft 06:

3473       *  Update of list of reviewers

3475       *  Issue #67, shortened the pledge endpoints to prepare for
3476          constraint deployments

3478       *  Included table for new endpoints on the registrar in the overview
3479          of the registrar-agent

3481       *  addressed review comments from SECDIR early review

3483       *  addressed review comments from IOTDIR early review

3485       From IETF draft 04 -> IETF draft 05:

3487       *  Restructured document to have a distinct section for the object
3488          flow and handling and shortened introduction, issue #72

3490       *  Added security considerations for using mDNS without a specific
3491          product-serial-number, issue #75

3493       *  Clarified pledge-status responses are cumulative, issue #73

3495       *  Removed agent-sign-cert from trigger data to save bandwidth and
3496          remove complexity through options, issue #70

3498       *  Changed terminology for LDevID(Reg) certificate to registrar EE
3499          certificate, as it does not need to be an LDevID, issue #66

3501       *  Added new protected header parameter (created-on) in PER to
3502          support freshness validation, issue #63

3504       *  Removed reference to CAB Forum as not needed for BRSKI-PRM
3505          specifically, issue #65

3507       *  Enhanced error codes in section 5.5.1, issue #39, #64

3509       *  Enhanced security considerations and privacy considerations, issue
3510          #59

3512       *  Issue #50 addressed by referring to the utilized enrollment
3513          protocol

3515       *  Issue #47 MASA verification of LDevID(RegAgt) to the same
3516          registrar EE certificate domain CA

3518       *  Reworked terminology of "enrollment object", "certification
3519          object", "enrollment request object", etc., issue #27

3521       *  Reworked all message representations to align with encoding

3523       *  Added explanation of MASA requiring domain CA cert in section
3524          5.5.1 and section 5.5.2, issue #36

3526       *  Defined new endpoint for pledge bootstrapping status inquiry,
3527          issue #35 in section Section 6.4, IANA considerations and section
3528          Section 5.3

3530       *  Included examples for several objects in section Appendix A
3531          including message example sizes, issue #33

3533       *  PoP for private key to registrar certificate included as
3534          mandatory, issues #32 and #49

3536       *  Issue #31, clarified that combined pledge may act as client/server
3537          for further (re)enrollment

3539       *  Issue #42, clarified that Registrar needs to verify the status
3540          responses with and ensure that they match the audit log response
3541          from the MASA, otherwise it needs drop the pledge and revoke the
3542          certificate

3544       *  Issue #43, clarified that the pledge shall use the create time
3545          from the trigger message if the time has not been synchronized,
3546          yet.

3548       *  Several editorial changes and enhancements to increasing
3549          readability.

3551       From IETF draft 03 -> IETF draft 04:

3553       *  In deep Review by Esko Dijk lead to issues #22-#61, which are bein
3554          stepwise integrated

3556       *  Simplified YANG definition by augmenting the voucher request from
3557          RFC 8995 instead of redefining it.

3559       *  Added explanation for terminology "endpoint" used in this
3560          document, issue #16

3562       *  Added clarification that registrar-agent may collect PVR or PER or
3563          both in one run, issue #17

3565       *  Added a statement that nonceless voucher may be accepted, issue
3566          #18

3568       *  Simplified structure in section Section 3.1, issue #19

3570       *  Removed join proxy in Figure 1 and added explanatory text, issue
3571          #20

3573       *  Added description of pledge-CAcerts endpoint plus further handling
3574          of providing a wrapped CA certs response to the pledge in section
3575          Section 6.3; also added new required registrar endpoint (section
3576          Section 6.2 and IANA considerations) for the registrar to provide
3577          a wrapped CA certs response, issue #21

3579       *  utilized defined abbreviations in the document consistently, issue
3580          #22

3582       *  Reworked text on discovery according to issue #23 to clarify scope
3583          and handling

3585       *  Added several clarifications based on review comments

3587       From IETF draft 02 -> IETF draft 03:

3589       *  Updated examples to state "base64encodedvalue==" for x5c
3590          occurrences

3592       *  Include link to SVG graphic as general overview

3594       *  Restructuring of section 5 to flatten hierarchy

3596       *  Enhanced requirements and motivation in Section 4

3598       *  Several editorial improvements based on review comments

3600       From IETF draft 01 -> IETF draft 02:

3602       *  Issue #15 included additional signature on voucher from registrar
3603          in section Section 6.2 and section Section 5.2 The verification of
3604          multiple signatures is described in section Section 6.3

3606       *  Included representation for General JWS JSON Serialization for
3607          examples

3609       *  Included error responses from pledge if it is not able to create a
3610          pledge-voucher request or an enrollment request in section
3611          Section 6.1

3613       *  Removed open issue regarding handling of multiple CSRs and
3614          enrollment responses during the bootstrapping as the initial
3615          target it the provisioning of a generic LDevID certificate.  The
3616          defined endpoint on the pledge may also be used for management of
3617          further certificates.

3619       From IETF draft 00 -> IETF draft 01:

3621       *  Issue #15 lead to the inclusion of an option for an additional
3622          signature of the registrar on the voucher received from the MASA
3623          before forwarding to the registrar-agent to support verification
3624          of POP of the registrars private key in section Section 6.2 and
3625          Section 6.3.

3627       *  Based on issue #11, a new endpoint was defined for the registrar
3628          to enable delivery of the wrapped enrollment request from the
3629          pledge (in contrast to plain PKCS#10 in simple enroll).

3631       *  Decision on issue #8 to not provide an additional signature on the
3632          enrollment-response object by the registrar.  As the enrollment
3633          response will only contain the generic LDevID certificate.  This
3634          credential builds the base for further configuration outside the
3635          initial enrollment.

3637       *  Decision on issue #7 to not support multiple CSRs during the
3638          bootstrapping, as based on the generic LDevID certificate the
3639          pledge may enroll for further certificates.

3641       *  Closed open issue #5 regarding verification of ietf-ztp-types
3642          usage as verified via a proof-of-concept in section
3643          {#exchanges_uc2_1}.

3645       *  Housekeeping: Removed already addressed open issues stated in the
3646          draft directly.

3648       *  Reworked text in from introduction to section pledge-responder-
3649          mode

3651       *  Fixed "serial-number" encoding in PVR/RVR

3653       *  Added prior-signed-voucher-request in the parameter description of
3654          the registrar-voucher-request in Section 6.2.

3656       *  Note added in Section 6.2 if sub-CAs are used, that the
3657          corresponding information is to be provided to the MASA.

3659       *  Inclusion of limitation section (pledge sleeps and needs to be
3660          waked up.  Pledge is awake but registrar-agent is not available)
3661          (Issue #10).

3663       *  Assertion-type aligned with voucher in RFC8366bis, deleted related
3664          open issues.  (Issue #4)

3666       *  Included table for endpoints in Section 5.3 for better
3667          readability.

3669       *  Included registrar authorization check for registrar-agent during
3670          TLS handshake in section Section 6.2.  Also enhanced figure
3671          Figure 9 with the authorization step on TLS level.

3673       *  Enhanced description of registrar authorization check for
3674          registrar-agent based on the agent-signed-data in section
3675          Section 6.2.  Also enhanced figure Figure 9 with the authorization
3676          step on pledge-voucher-request level.

3678       *  Changed agent-signed-cert to an array to allow for providing
3679          further certificate information like the issuing CA cert for the
3680          LDevID(RegAgt) certificate in case the registrar and the
3681          registrar-agent have different issuing CAs in Figure 9 (issue
3682          #12).  This also required changes in the YANG module in
3683          Section 7.1.2

3685       *  Addressed YANG warning (issue #1)

3687       *  Inclusion of examples for a trigger to create a pledge-voucher-
3688          request and an enrollment-request.

3690       From IETF draft-ietf-anima-brski-async-enroll-03 -> IETF anima-brski-
3691       prm-00:

3693       *  Moved UC2 related parts defining the pledge in responder mode from
3694          draft-ietf-anima-brski-async-enroll-03 to this document This
3695          required changes and adaptations in several sections to remove the
3696          description and references to UC1.

3698       *  Addressed feedback for voucher-request enhancements from YANG
3699          doctor early review in Section 7.1 as well as in the security
3700          considerations (formerly named ietf-async-voucher-request).

3702       *  Renamed ietf-async-voucher-request to IETF-voucher-request-prm to
3703          to allow better listing of voucher related extensions; aligned
3704          with constraint voucher (#20)

3706       *  Utilized ietf-voucher-request-async instead of ietf-voucher-
3707          request in voucher exchanges to utilize the enhanced voucher-
3708          request.

3710       *  Included changes from draft-ietf-netconf-sztp-csr-06 regarding the
3711          YANG definition of csr-types into the enrollment request exchange.

3713       From IETF draft 02 -> IETF draft 03:

3715       *  Housekeeping, deleted open issue regarding YANG voucher-request in
3716          Section 6.1 as voucher-request was enhanced with additional leaf.

3718       *  Included open issues in YANG model in Section 5.1 regarding
3719          assertion value agent-proximity and csr encapsulation using SZTP
3720          sub module).

3722       From IETF draft 01 -> IETF draft 02:

3724       *  Defined call flow and objects for interactions in UC2.  Object
3725          format based on draft for JOSE signed voucher artifacts and
3726          aligned the remaining objects with this approach in Section 6 .

3728       *  Terminology change: issue #2 pledge-agent -> registrar-agent to
3729          better underline agent relation.

3731       *  Terminology change: issue #3 PULL/PUSH -> pledge-initiator-mode
3732          and pledge-responder-mode to better address the pledge operation.

3734       *  Communication approach between pledge and registrar-agent changed
3735          by removing TLS-PSK (former section TLS establishment) and
3736          associated references to other drafts in favor of relying on
3737          higher layer exchange of signed data objects.  These data objects
3738          are included also in the pledge-voucher-request and lead to an
3739          extension of the YANG module for the voucher-request (issue #12).

3741       *  Details on trust relationship between registrar-agent and
3742          registrar (issue #4, #5, #9) included in Section 5.1.

3744       *  Recommendation regarding short-lived certificates for registrar-
3745          agent authentication towards registrar (issue #7) in the security
3746          considerations.

3748       *  Introduction of reference to agent signing certificate using SKID
3749          in agent signed data (issue #37).

3751       *  Enhanced objects in exchanges between pledge and registrar-agent
3752          to allow the registrar to verify agent-proximity to the pledge
3753          (issue #1) in Section 6.

3755       *  Details on trust relationship between registrar-agent and pledge
3756          (issue #5) included in Section 5.1.

3758       *  Split of use case 2 call flow into sub sections in Section 6.

3760       From IETF draft 00 -> IETF draft 01:

3762       *  Update of scope in Section 3.1 to include in which the pledge acts
3763          as a server.  This is one main motivation for use case 2.

3765       *  Rework of use case 2 in Section 5.1 to consider the transport
3766          between the pledge and the pledge-agent.  Addressed is the TLS
3767          channel establishment between the pledge-agent and the pledge as
3768          well as the endpoint definition on the pledge.

3770       *  First description of exchanged object types (needs more work)

3772       *  Clarification in discovery options for enrollment endpoints at the
3773          domain registrar based on well-known endpoints do not result in
3774          additional /.well-known URIs.  Update of the illustrative example.
3775          Note that the change to /brski for the voucher related endpoints
3776          has been taken over in the BRSKI main document.

3778       *  Updated references.

3780       *  Included Thomas Werner as additional author for the document.

3782       From individual version 03 -> IETF draft 00:

3784       *  Inclusion of discovery options of enrollment endpoints at the
3785          domain registrar based on well-known endpoints in new section as
3786          replacement of section 5.1.3 in the individual draft.  This is
3787          intended to support both use cases in the document.  An
3788          illustrative example is provided.

3790       *  Missing details provided for the description and call flow in
3791          pledge-agent use case Section 5.1, e.g. to accommodate
3792          distribution of CA certificates.

3794       *  Updated CMP example in to use lightweight CMP instead of CMP, as
3795          the draft already provides the necessary /.well-known endpoints.

3797       *  Requirements discussion moved to separate section in Section 4.
3798          Shortened description of proof of identity binding and mapping to
3799          existing protocols.

3801       *  Removal of copied call flows for voucher exchange and registrar
3802          discovery flow from [RFC8995] in UC1 to avoid doubling or text or
3803          inconsistencies.

3805       *  Reworked abstract and introduction to be more crisp regarding the
3806          targeted solution.  Several structural changes in the document to
3807          have a better distinction between requirements, use case
3808          description, and solution description as separate sections.
3809          History moved to appendix.

3811       From individual version 02 -> 03:

3813       *  Update of terminology from self-contained to authenticated self-
3814          contained object to be consistent in the wording and to underline
3815          the protection of the object with an existing credential.  Note
3816          that the naming of this object may be discussed.  An alternative
3817          name may be attestation object.

3819       *  Simplification of the architecture approach for the initial use
3820          case having an offsite PKI.

3822       *  Introduction of a new use case utilizing authenticated self-
3823          contain objects to onboard a pledge using a commissioning tool
3824          containing a pledge-agent.  This requires additional changes in
3825          the BRSKI call flow sequence and led to changes in the
3826          introduction, the application example,and also in the related
3827          BRSKI-PRM call flow.

3829       From individual version 01 -> 02:

3831       *  Update of introduction text to clearly relate to the usage of
3832          IDevID and LDevID.

3834       *  Update of description of architecture elements and changes to
3835          BRSKI in Section 5.

3837       *  Enhanced consideration of existing enrollment protocols in the
3838          context of mapping the requirements to existing solutions in
3839          Section 4.

3841       From individual version 00 -> 01:

3843       *  Update of examples, specifically for building automation as well
3844          as two new application use cases in Section 3.1.

3846       *  Deletion of asynchronous interaction with MASA to not complicate
3847          the use case.  Note that the voucher exchange can already be
3848          handled in an asynchronous manner and is therefore not considered
3849          further.  This resulted in removal of the alternative path the
3850          MASA in Figure 1 and the associated description in Section 5.

3852       *  Enhancement of description of architecture elements and changes to
3853          BRSKI in Section 5.

3855       *  Consideration of existing enrollment protocols in the context of
3856          mapping the requirements to existing solutions in Section 4.

3858       *  New section starting with the mapping to existing enrollment
3859          protocols by collecting boundary conditions.

3861    Contributors

3863       Esko Dijk
3864       IoTconsultancy.nl
3865       Email: [e-mail]<mailto:[e-mail]>

3867    Authors' Addresses

3869       Steffen Fries
3870       Siemens AG
3871       Otto-Hahn-Ring 6
3872       81739 Munich
3873       Germany
3874       Email: [e-mail]<mailto:[e-mail]>
3875       URI:   https://www.siemens.com/

3877       Thomas Werner
3878       Siemens AG
3879       Otto-Hahn-Ring 6
3880       81739 Munich
3881       Germany
3882       Email: [e-mail]<mailto:[e-mail]>
3883       URI:   https://www.siemens.com/

3885       Eliot Lear
3886       Cisco Systems
3887       Richtistrasse 7
3888       CH-8304 Wallisellen
3889       Switzerland
3890       Phone: [phone]<tel:[phone]>
3891       Email: [e-mail]<mailto:[e-mail]>

3893       Michael C. Richardson
3894       Sandelman Software Works
3895       Email: [e-mail]<mailto:[e-mail]>
3896       URI:   https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sandelman.ca%2F&data=05%7C01%7Cthomas-werner%40siemens.com%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131634928167457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=j1xmK3qyUKJeALzDPfJyaTVZoBLAEOLL%2Bd82hUGgfuA%3D&reserved=0<http://www.sandelman.ca/>