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

["Fries, Steffen" <[e-mail]>]

Hi Toerless, 

Thank you for the review. I/We will get back to the issue you raised. Just need to dig through the list and also to the referring issues we had on the ANIMA github, which led to some of the design decisions. 

Best regards
Steffen 

> -----Original Message-----
> From: Toerless Eckert <[e-mail]>
> Sent: Dienstag, 28. Februar 2023 07:44
> To: Sheng Jiang <[e-mail]>; [e-mail]
> Cc: anima <[e-mail]>; anima-chairs <[e-mail]>; draft-ietf-
> anima-brski-prm <[e-mail]>; ietf
> <[e-mail]>
> Subject: 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
> 
> 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 ...
> 
> 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).
> 
> 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).
> 
> 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)".
> 
> 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.
> 
> 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.
> 
> 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)).
> 
> 2014	   To perform the validation of multiple signatures on the voucher
> 
> s/multiple/the different/ ??
> 
> 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.
> 
> 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.
> 
> 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 ;-))
> 
> [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.
> 
> 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.
> 
> 2096	   The supply CA certificates message has the Content-Type application/
> 
> s/supply//
> s/the/a/
> 
> 2097	   jose+json and is signed using the credential of the registrar pledge
> 2098	   as shown in Figure 13.
> 
> "registrar pledge" ?
> 
> 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.
> 
> 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.
> 
> 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).
> 
> 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.
> 
> 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).
> 
> 2220	   agent establishes a TLS connection with the registrar as stated in
> 
> establishes a new TLS connection
>               ^^^
> 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...
> 
> 
> 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/ ??
> 
> 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/
> 
> 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].
> 
> 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.
> 
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 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)/
> 
> 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/ ??
> 
> 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 ?!
> 
> new paraagraph.
> 
> 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.
> 
> 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 ?
> 
> 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]"
> 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%7Csteffen.fries%40siemens.com%7
> C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1495d
> 55a%7C1%7C0%7C638131634926776595%7CUnknown%7CTWFpbGZsb3d8eyJ
> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
> 3000%7C%7C%7C&sdata=Vl8qFAXzf7RB9vYuXEVPyck2OuZuDOri8b6rmyq4bGM
> %3D&reserved=0>
> 2591	       WG List:  <mailto:[e-mail]>
> 2592	       Author:   Steffen Fries
> 2593	                 <mailto:[e-mail]>
> 2594	       Author:   Eliot Lear
> 2595	                 <mailto: [e-mail]>
> 2596	       Author:   Thomas Werner
> 2597	                 <mailto: [e-mail]>
> 2598	       Author:   Michael Richardson
> 2599	                 <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.i
> etf.org%2Flicense-
> info&data=05%7C01%7Csteffen.fries%40siemens.com%7C3fa08d366121415a4
> 2d408db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C63
> 8131634926932386%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
> CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdat
> a=iI2zm78xoQXxDB0yOPbaF1PY1R6sq7DRUMkEly9p3vg%3D&reserved=0).
> 
> 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.).
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.ie
> tf.org%2Farchive%2Fid%2Fdraft-ietf-
> &data=05%7C01%7Csteffen.fries%40siemens.com%7C3fa08d366121415a42d40
> 8db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131
> 634926932386%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=c
> mNAuMhRVGMBi2k7bUM04TeS9Jg1XPbfQIusIqX3kN4%3D&reserved=0
> 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.ie
> tf.org%2Farchive%2Fid%2Fdraft-ietf-anima-
> &data=05%7C01%7Csteffen.fries%40siemens.com%7C3fa08d366121415a42d40
> 8db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131
> 634926932386%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%
> 2BJtmbfapLXDJBUwC%2FK%2BQZ99gZo3duMEakeXCh1Njdyk%3D&reserved=0
> 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.ie
> tf.org%2Farchive%2Fid%2Fdraft-ietf-
> &data=05%7C01%7Csteffen.fries%40siemens.com%7C3fa08d366121415a42d40
> 8db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131
> 634926932386%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=c
> mNAuMhRVGMBi2k7bUM04TeS9Jg1XPbfQIusIqX3kN4%3D&reserved=0
> 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.rf
> c-
> editor.org%2Finfo%2Frfc2119&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1
> 495d55a%7C1%7C0%7C638131634926932386%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C3000%7C%7C%7C&sdata=1D0zCR3XW2s6NcMTk84nRv%2FV1aEvV3%2FUAQ
> xFmMEBkYU%3D&reserved=0>.
> 
> 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.rf
> c-
> editor.org%2Finfo%2Frfc5280&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1
> 495d55a%7C1%7C0%7C638131634926932386%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C3000%7C%7C%7C&sdata=g2iZ8%2FUpxVWf6wVSUuTltLUqUiFlq7DSVc4P22vo
> i5k%3D&reserved=0>.
> 
> 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.rf
> c-
> editor.org%2Finfo%2Frfc6762&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1
> 495d55a%7C1%7C0%7C638131634926932386%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C3000%7C%7C%7C&sdata=DH0VMbf34BWChRjO7D7FYroWDeffOt5G%2B0KR
> TVdxrHI%3D&reserved=0>.
> 
> 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.rf
> c-
> editor.org%2Finfo%2Frfc6763&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1
> 495d55a%7C1%7C0%7C638131634926932386%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C3000%7C%7C%7C&sdata=6RsL%2BSR50saIHIdmse17EBrg%2B38y7JpRbJnU%
> 2FJ7JEyI%3D&reserved=0>.
> 
> 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.rf
> c-
> editor.org%2Finfo%2Frfc7030&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1
> 495d55a%7C1%7C0%7C638131634926932386%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C3000%7C%7C%7C&sdata=L6MfK7pUrdVXsrpfAP8WYnRAdapYaTsamCFRbMG
> 1JD8%3D&reserved=0>.
> 
> 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.rf
> c-
> editor.org%2Finfo%2Frfc7515&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1
> 495d55a%7C1%7C0%7C638131634926932386%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C3000%7C%7C%7C&sdata=GG1W6gR1O7tQURfbIKZHmMyaGyC%2BKU%2FnfI
> eSFEWeGc8%3D&reserved=0>.
> 
> 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.rf
> c-
> editor.org%2Finfo%2Frfc8040&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1
> 495d55a%7C1%7C0%7C638131634926932386%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C3000%7C%7C%7C&sdata=ZvHTpo06msXsyHzu1lDxSmci%2BY5VWwzrtoicgjm
> RjDk%3D&reserved=0>.
> 
> 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.rf
> c-
> editor.org%2Finfo%2Frfc8174&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1
> 495d55a%7C1%7C0%7C638131634926932386%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C3000%7C%7C%7C&sdata=hltfgC540Z%2FwHIaw0PDmXChk6Gy%2FHUX6la1lp
> 5MWQIY%3D&reserved=0>.
> 
> 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.rf
> c-
> editor.org%2Finfo%2Frfc8366&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1
> 495d55a%7C1%7C0%7C638131634926932386%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C3000%7C%7C%7C&sdata=d94Vs1EF2lSA4XjgbtAkqcNcrE5RtG%2BYyKcobOxzC
> 9c%3D&reserved=0>.
> 
> 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.rf
> c-
> editor.org%2Finfo%2Frfc8610&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1
> 495d55a%7C1%7C0%7C638131634926932386%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C3000%7C%7C%7C&sdata=TzbEExUOvOQNK8W4dKSst8uz9zbHa1%2F4I1G8o8
> JaOqM%3D&reserved=0>.
> 
> 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.rf
> c-
> editor.org%2Finfo%2Frfc8995&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1
> 495d55a%7C1%7C0%7C638131634926932386%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C3000%7C%7C%7C&sdata=g2PXo5DDjPcyyFrNMilFZASZGlgeFQWye1BL59%2FK
> Fa8%3D&reserved=0>.
> 
> 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.git
> hubusercontent.com%2Fanima-wg%2Fanima-brski-
> &data=05%7C01%7Csteffen.fries%40siemens.com%7C3fa08d366121415a42d40
> 8db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131
> 634926932386%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=9
> HnHyCaDU1GNBIcLUZSX%2BIVPSE9m4JV0ugfgPeOyI5c%3D&reserved=0
> 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.ie
> tf.org%2Farchive%2Fid%2Fdraft-ietf-
> &data=05%7C01%7Csteffen.fries%40siemens.com%7C3fa08d366121415a42d40
> 8db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638131
> 634926932386%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=c
> mNAuMhRVGMBi2k7bUM04TeS9Jg1XPbfQIusIqX3kN4%3D&reserved=0
> 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%2Fmailarc
> hive.ietf.org%2Farch%2Fmsg%2Fsaag%2F&data=05%7C01%7Csteffen.fries%40s
> iemens.com%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4a
> ddab42e1495d55a%7C1%7C0%7C638131634926932386%7CUnknown%7CTWFp
> bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn0%3D%7C3000%7C%7C%7C&sdata=ZFEDdFgXLysDPIbfyxKms7BkVceFKVzgM
> ZVj0sP6GpA%3D&reserved=0
> 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.rf
> c-
> editor.org%2Finfo%2Frfc2986&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1
> 495d55a%7C1%7C0%7C638131634926932386%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C3000%7C%7C%7C&sdata=hph8TJjnGEQ6IDFan%2BriSAjfof9CSONg0B0rmrqkZ
> eI%3D&reserved=0>.
> 
> 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.rf
> c-
> editor.org%2Finfo%2Frfc6125&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1
> 495d55a%7C1%7C0%7C638131634926932386%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C3000%7C%7C%7C&sdata=OyTcrghtjQzAYOzsvsW1tgCNNyk9cVQgV%2F3oiIAL
> ics%3D&reserved=0>.
> 
> 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.rf
> c-
> editor.org%2Finfo%2Frfc6241&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1
> 495d55a%7C1%7C0%7C638131634926932386%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C3000%7C%7C%7C&sdata=U%2BzBCkCMYpjb2R6qUNZWuPKabaMfd19wX%2F
> HGXLa645E%3D&reserved=0>.
> 
> 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.rf
> c-
> editor.org%2Finfo%2Frfc7252&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1
> 495d55a%7C1%7C0%7C638131634926932386%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C3000%7C%7C%7C&sdata=E4HmUSsjSofdvOGeE46dnOWGWgTpVUKdlVo%2BI
> ocsNLM%3D&reserved=0>.
> 
> 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.rf
> c-
> editor.org%2Finfo%2Frfc8340&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1
> 495d55a%7C1%7C0%7C638131634926932386%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C3000%7C%7C%7C&sdata=lpN%2BC2HRXnknML0QGWTPgCw4RcWEBVhVnFH
> OZ3AnSAQ%3D&reserved=0>.
> 
> 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.rf
> c-
> editor.org%2Finfo%2Frfc8407&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1
> 495d55a%7C1%7C0%7C638131634926932386%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C3000%7C%7C%7C&sdata=RS4RZ4zGM%2FBvWmndQHfWHgUmhBDR8dZtPxX
> DvY0A9XA%3D&reserved=0>.
> 
> 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.rf
> c-
> editor.org%2Finfo%2Frfc8792&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1
> 495d55a%7C1%7C0%7C638131634926932386%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C3000%7C%7C%7C&sdata=QLjU%2F2RUQXaoiCOqiN28cy4ESBN5cXkOc3YV8b
> s0FC4%3D&reserved=0>.
> 
> 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.rf
> c-
> editor.org%2Finfo%2Frfc9052&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1
> 495d55a%7C1%7C0%7C638131634926932386%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C3000%7C%7C%7C&sdata=T8gNQuCgEZkgh69NFQEPEyaI20dl%2BzIaDR1hk6D
> fnWk%3D&reserved=0>.
> 
> 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.rf
> c-
> editor.org%2Finfo%2Frfc9053&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1
> 495d55a%7C1%7C0%7C638131634926932386%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C3000%7C%7C%7C&sdata=kJeIVQKLxJPYZeRjCCIIKBaj5xUvd7SluGtzO44j2sw%
> 3D&reserved=0>.
> 
> 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.rf
> c-
> editor.org%2Finfo%2Frfc9110&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1
> 495d55a%7C1%7C0%7C638131634926932386%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C3000%7C%7C%7C&sdata=bCHVb5wXOJKxnR7C9SmUCCiMma76qwijgTDIz9xZ
> 6jw%3D&reserved=0>.
> 
> 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.rf
> c-
> editor.org%2Finfo%2Frfc9238&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7C3fa08d366121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1
> 495d55a%7C1%7C0%7C638131634926932386%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C3000%7C%7C%7C&sdata=8r3FstEuF0vmtjK2eF1nw925pnhyXn7lgnCHl09UyUY
> %3D&reserved=0>.
> 
> 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
> iOiJhZ2VudC1wcm94aW1pdHkiLCJzZXJpYWwtbnVtYmVyIjoiMDEyMzQ1Njc4OSIsI
> m5\
> 3065
> vbmNlIjoiTDNJSjZocHRIQ0lRb054YWFiOUhXQT09IiwiY3JlYXRlZC1vbiI6IjIwMjI\
> 3066
> tMDQtMjZUMDU6MTY6MTcuNzA5WiIsImFnZW50LXByb3ZpZGVkLXByb3hpbWl0
> eS1yZWd\
> 3067
> pc3RyYXItY2VydCI6Ik1JSUI0akNDQVlpZ0F3SUJBZ0lHQVhZNzJiYlpNQW9HQ0NxR
> 1N\
> 3068
> NNDlCQU1DTURVeEV6QVJCZ05WQkFvTUNrMTVRblZ6YVc1bGMzTXhEVEFMQm
> dOVkJBY01\
> 3069
> CRk5wZEdVeER6QU5CZ05WQkFNTUJsUmxjM1JEUVRBZUZ3MHlNREV5TURjd05
> qRTRNVEp\
> 3070
> hRncwek1ERXlNRGN3TmpFNE1USmFNRDR4RXpBUkJnTlZCQW9NQ2sxNVFuVnp
> hVzVsYzN\
> 3071
> NeERUQUxCZ05WQkFjTUJGTnBkR1V4R0RBV0JnTlZCQU1NRDBSdmJXRnBibEps
> WjJsemR\
> 3072
> ISmhjakJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFCQmsxNksva
> Tc5b1J\
> 3073
> rSzVZYmVQZzhVU1I4L3VzMWRQVWlaSE10b2tTZHFLVzVmbldzQmQrcVJMN1dSZ
> mZlV2t\
> 3074
> 5Z2Vib0pmSWxsdXJjaTI1d25oaU9WQ0dqZXpCNU1CMEdBMVVkSlFRV01CUUdD
> Q3NHQVF\
> 3075
> VRkJ3TUJCZ2dyQmdFRkJRY0RIREFPQmdOVkhROEJBZjhFQkFNQ0I0QXdTQVlEVlI
> wUkJ\
> 3076
> FRXdQNElkY21WbmFYTjBjbUZ5TFhSbGMzUXVjMmxsYldWdWN5MWlkQzV1WlhT
> Q0huSmx\
> 3077
> aMmx6ZEhKaGNpMTBaWE4wTmk1emFXVnRaVzV6TFdKMExtNWxkREFLQmdnc
> Whrak9QUVF\
> 3078
> EQWdOSUFEQkZBaUJ4bGRCaFpxMEV2NUpMMlByV0N0eVM2aERZVzF5Q08vUm
> F1YnBDN01\
> 3079
> hSURnSWhBTFNKYmdMbmdoYmJBZzBkY1dGVVZvL2dHTjAvand6SlowU2wyaDR4
> SVhrMSI\
> 3080
> sImFnZW50LXNpZ25lZC1kYXRhIjoiZXlKd1lYbHNiMkZrSWpvaVpYbEtjRnBZVW0xTV
> d\
> 3081
> GcDJaRmRPYjFwWVNYUmpiVlo0WkZkV2VtUkRNWGRqYlRBMldWZGtiR0p1VVhS
> ak1teHV\
> 3082
> ZbTFXYTB4WFVtaGtSMFZwVDI1emFWa3pTbXhaV0ZKc1drTXhkbUpwU1RaSmFrb
> DNUV3B\
> 3083
> KZEUxRVVYUk5hbHBWVFVSVk5rMUVZelpPUkVWMVRrUlJORmRwU1hOSmJrNX
> NZMjFzYUd\
> 3084
> KRE1YVmtWekZwV2xoSmFVOXBTWGROVkVsNlRrUlZNazU2WnpWSmJqRTVJaXd
> pYzJsbmJ\
> 3085
> tRjBkWEpsY3lJNlczc2ljSEp2ZEdWamRHVmtJam9pWlhsS2NtRlhVV2xQYVVwWlkw
> aHd\
> 3086
> jMVJWZERSaVNFSkNUbXBvYWxaVVZrZFZWVEZaVmxoYWRWTldVVEpWV0dNNV
> NXbDNhVmx\
> 3087
> YZUc1SmFtOXBVbFpOZVU1VVdXbG1VU0lzSW5OcFoyNWhkSFZ5WlNJNklrY3pW
> M2hHU0d\
> 3088
> WMFdGQTRiR3hTVmkwNWRXSnlURmxxU25aUllUWmZlUzFRYWxGWk5FNWhk
> MW81Y0ZKaGI\
> 3089
> yeE9TbTlFTm1SbFpXdHVTVjlGV0daemVWWlRZbmM0VTBONlRWcE1iakJoUVhW
> b2FVZFp\
> 3090
> UakJSSW4xZGZRPT0iLCJhZ2VudC1zaWduLWNlcnQiOlsiTUlJQjFEQ0NBWHFnQXdJ
> QkF\
> 3091
> nSUVZbWQ0T1RBS0JnZ3Foa2pPUFFRREFqQStNUk13RVFZRFZRUUtEQXBOZVVK
> MWMybHV\
> 3092
> aWE56TVEwd0N3WURWUVFIREFSVGFYUmxNUmd3RmdZRFZRUUREQTlVWlhO
> MFVIVnphRTF\
> 3093
> 2WkdWc1EwRXdIaGNOTWpJd05ESTJNRFEwTWpNeldoY05Nekl3TkRJMk1EUTB
> Nak16V2p\
> 3094
> BOU1STXdFUVlEVlFRS0RBcE5lVUoxYzJsdVpYTnpNUTB3Q3dZRFZRUUhEQVJUYV
> hSbE1\
> 3095
> SY3dGUVlEVlFRRERBNVNaV2RwYzNSeVlYSkJaMlZ1ZERCWk1CTUdCeXFHU000O
> UFnRUd\
> 3096
> DQ3FHU000OUF3RUhBMElBQkd4bHJOZmozaVJiNy9CUW9kVys1WWlvT3poK2pJ
> dHlxdVJ\
> 3097
> JTy9XejdZb1czaXdEYzNGeGV3TFZmekNyNU52RDEzWmFGYjdmcmFuK3Q5b3RZN
> VdMaEo\
> 3098
> 2alp6QmxNQTRHQTFVZER3RUIvd1FFQXdJSGdEQWZCZ05WSFNNRUdEQVdnQlJ2
> b1QxdWR\
> 3099
> lMmY2TEVRaFU3SEhqK3ZKL2Q3SXpBZEJnTlZIUTRFRmdRVVhwemxNS3hscEE2OG
> NVNUZ\
> 3100
> RTVhVdm5JVDZRd3dFd1lEVlIwbEJBd3dDZ1lJS3dZQkJRVUhBd0l3Q2dZSUtvWkl6aj
> B\
> 3101
> FQXdJRFNBQXdSUUlnYzJ5NnhvT3RvUUJsSnNnbE9MMVZ4SEdvc1R5cEVxUmZ6M
> FF2NFp\
> 3102
> FUHY0d0NJUUNWeWIyRjl6VjNuOTUrb2xnZkZKZ1pUV0V6NGRTYUYzaHpSUWIz
> WnVCMjl\
> 3103
> RPT0iLCJNSUlCekRDQ0FYR2dBd0lCQWdJRVhYakhwREFLQmdncWhrak9QUVFEQ
> WpBMU1\
> 3104
> STXdFUVlEVlFRS0RBcE5lVUoxYzJsdVpYTnpNUTB3Q3dZRFZRUUhEQVJUYVhSbE1
> ROHd\
> 3105
> EUVlEVlFRRERBWlVaWE4wUTBFd0hoY05NVGt3T1RFeE1UQXdPRE0yV2hjTk1qa3
> dPVEV\
> 3106
> 4TVRBd09ETTJXakErTVJNd0VRWURWUVFLREFwTmVVSjFjMmx1WlhOek1RMHd
> Dd1lEVlF\
> 3107
> RSERBUlRhWFJsTVJnd0ZnWURWUVFEREE5VVpYTjBVSFZ6YUUxdlpHVnNRMEV3
> V1RBVEJ\
> 3108
> nY3Foa2pPUFFJQkJnZ3Foa2pPUFFNQkJ3TkNBQVRsRzBmd1QzM29leloxdmtIUWJ
> ldGV\
> 3109
> ibWorQm9WK1pGc2pjZlF3MlRPa0pQaE9rT2ZBYnU5YlMxcVppOHlhRVY4b2VyS2
> wvNlp\
> 3110
> YYmZ4T21CanJScmNYbzJZd1pEQVNCZ05WSFJNQkFmOEVDREFHQVFIL0FnRUFN
> QTRHQTF\
> 3111
> VZER3RUIvd1FFQXdJQ0JEQWZCZ05WSFNNRUdEQVdnQlRvWklNelFkc0Qvai8rZ1
> gvN2N\
> 3112
> CSnVjSC9YbWpBZEJnTlZIUTRFRmdRVWI2RTliblh0bitpeEVJVk94eDQvcnlmM2V5T
> Xd\
> 3113
> DZ1lJS29aSXpqMEVBd0lEU1FBd1JnSWhBUG5CMHcxTkN1cmhNeEp3d2ZqejdnRG
> lpeGt\
> 3114
> VWUxQU1o5ZU45a29oTlFVakFpRUF3NFk3bHR4V2lQd0t0MUo5bmp5ZkRObDVN
> dUVEQml\
> 3115	   teFIzQ1hvWktHUXJVPSJdfX0",
> 3116	       "signatures":[{
> 3117
> "protected":"eyJ4NWMiOlsiTUlJQitUQ0NBYUNnQXdJQkFnSUdBWG5WanNVN\
> 3118
> U1Bb0dDQ3FHU000OUJBTUNNRDB4Q3pBSkJnTlZCQVlUQWtGUk1SVXdFd1lEVlF
> RS0RBe\
> 3119
> EthVzVuU21sdVowTnZjbkF4RnpBVkJnTlZCQU1NRGtwcGJtZEthVzVuVkdWemRFT
> kJNQ\
> 3120
> 0FYRFRJeE1EWXdOREExTkRZeE5Gb1lEems1T1RreE1qTXhNak0xT1RVNVdqQlNN
> UXN3Q\
> 3121
> 1FZRFZRUUdFd0pCVVRFVk1CTUdBMVVFQ2d3TVNtbHVaMHBwYm1kRGIzSndNU
> k13RVFZR\
> 3122
> FZRUUZFd293TVRJek5EVTJOemc1TVJjd0ZRWURWUVFEREE1S2FXNW5TbWx1Wj
> BSbGRtb\
> 3123
> GpaVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFCQzc5bGlhUm
> NCalpjR\
> 3124
> UVYdzdyVWVhdnRHSkF1SDRwazRJNDJ2YUJNc1UxMWlMRENDTGtWaHRVVjIxbX
> ZhS0N2T\
> 3125
> XgyWStTTWdROGZmd0wyM3ozVElWQldqZFRCek1Dc0dDQ3NHQVFVRkJ3RWdC
> QjhXSFcxa\
> 3126
> GMyRXRkR1Z6ZEM1emFXVnRaVzV6TFdKMExtNWxkRG81TkRRek1COEdBMVVkS
> XdRWU1CY\
> 3127
> UFGRlFMak56UFwvU1wva291alF3amc1RTVmdndjWWJNQk1HQTFVZEpRUU1NQ
> W9HQ0NzR\
> 3128
> 0FRVUZCd01DTUE0R0ExVWREd0VCXC93UUVBd0lIZ0RBS0JnZ3Foa2pPUFFRREFn
> TkhBR\
> 3129
> EJFQWlCdTN3UkJMc0pNUDVzTTA3MEgrVUZyeU5VNmdLekxPUmNGeVJST2xxc
> UhpZ0lnW\
> 3130
> ENtSkxUekVsdkQycG9LNmR4NmwxXC91eW1UbmJRRERmSmxhdHVYMlJvT0U9Il
> 0sImFsZ\
> 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
> iOiJhZ2VudC1wcm94aW1pdHkiLCJzZXJpYWwtbnVtYmVyIjoiY2FmZmUtOTg3NDU
> iLCJ\
> 3159
> ub25jZSI6ImM1VEVPb29NTE5hNEN4L1UrVExoQ3c9PSIsInByaW9yLXNpZ25lZC12
> b3V\
> 3160
> jaGVyLXJlcXVlc3QiOiJleUp3WVhsc2IyRmtJam9pWlhsS2NGcFlVbTFNV0ZwMlpGZE
> 9\
> 3161
> iMXBZU1hSamJWWjRaRmRXZW1SRE1YZGpiVEEyWkcwNU1Wa3lhR3hqYVVrMlp
> YbEthR01\
> 3162
> 6VG14amJsSndZakkwYVU5cFNtaGFNbFoxWkVNeGQyTnRPVFJoVnpGd1pFaHJhV
> XhEU25\
> 3163
> wYVdFcHdXVmQzZEdKdVZuUlpiVlo1U1dwdmFWa3lSbTFhYlZWMFQxUm5NMDVF
> VldsTVE\
> 3164
> wcDFZakkxYWxwVFNUWkpiVTB4VmtWV1VHSXlPVTVVUlRWb1RrVk9ORXd4VlhK
> V1JYaHZ\
> 3165
> VVE5qT1ZCVFNYTkpiVTU1V2xkR01GcFhVWFJpTWpScFQybEplVTFFU1hsTVZFRjV
> URlJ\
> 3166
> KZVZaRVFUTlBhazE2VDJwQk5FeHFSVFZPYkc5cFRFTkthRm95Vm5Wa1F6RjNZMjA
> 1TW1\
> 3167
> GWFVteGFRekYzWTIwNU5HRlhNWEJrU0d0MFkyMVdibUZZVGpCamJVWjVURm
> RPYkdOdVV\
> 3168
> XbFBhVXBPVTFWc1JGSkdVa1JSTUVacFZESmtRbVF3YkVOUlYyUktVakJHV1ZkWVR
> uZFR\
> 3169
> WMVoyVkZWR2RsSXdUa1JqVldSVVZGUlJOVkZyUms1Uk1ERkhaRE5vUkdWclJrdF
> JiV1J\
> 3170
> QVm10S1FsZFdVa0poTUZwVFZGWktTbVF3VmtKWFZWSlhWVlpHVEZKRlJuTlViVlp
> XVkc\
> 3171
> 1YWFWZEZTbTlaYlRWeVpVVmFWVkZXVWtOYU1EVlhVV3RHZWxSVlVrWk5WRlp
> XVFRGYWN\
> 3172
> GbDZTbk5oTWtaWVVtNXNiRlpGVmxGVVZVVjNVakJGZUZaVlZrTmtNMlJJVmtab2
> MxWkh\
> 3173
> SbGxWYlhoT1ZXdFdNMUpJWkZwU1JscFNWVlZTUlZGWGFFOWFWbHBQWTBkU
> 1NGWnJVbEp\
> 3174
> XUlVac1VtNWpkMlZWTVVWU1dHeE9Va1pHTTFSdWNFcE5WVFZGWVVkR1IyUjZ
> RalpVVlZ\
> 3175
> KR1pWVXhSVlZZWkU5bGEydDRWR3RTYjFsVk1VaFRXR2hFWld0R1MxRnRaRTlXY
> TBwQ1Y\
> 3176
> xWlNRbUV3V2xOVVZrcEtaREJXUWxkVlVsZFZWa1pNVWtWR2MxUnRWbFpVYmx
> wcFYwVkt\
> 3177
> iMWx0TlhKbFJWcEZVVlpPUTFvd05WZFJhMFo2VkZWTmQwMVVWbFpOTVZwd1d
> YcEtjMkV\
> 3178
> 4YkZsVGFsWk9WVlJvTTFKR1JscFNSbHBTVlZWb1JWRldjRTlhVmxwUFkwZFNTRlpZ
> YUV\
> 3179
> oU1JVWllVVzFrVDFaclNrSlVWVEZGVFVSRk1WWlVTbk5OUm5CWFUyMTRZVTF0Z
> URaYVJ\
> 3180
> XaExZVWRPY1ZGc2NFNVJhekZJVVc1c2VGSXhUazVPUkd4Q1dqQldTRkV3VG5oU0
> 1VNU9\
> 3181
> Ua1JzUW1Rd1ZrbFJWRUpLVVZWS1NsVklhRmhrVlRGSlVucG9TMVJIV2taVlJVVTF
> UMWh\
> 3182
> hZDAxdVZrbFNWVFZxVlROc2JWa3pWVE5VUjJSYVRraEJlRTVGUmtOT01GSk9XbFJ
> GTkU\
> 3183
> xSVRrWmxSV1J4VkZOME0yTnJOVFJPTURVMVdWaE9lRXQ2Um5CTlJXUlVVVEZKT
> lU1VVV\
> 3184
> UTk5SRVp0VWpKV1dGUldSbWxqVjNCWVpXdEtZVlJWU1hkU01FVjRWbGRTUzFW
> V1JsaFV\
> 3185
> WVXBTVWpCT1JHTXdaRUpWVmxaSFVXNWtUbEZyU201YU0wcERXakJXUjFGc1Jt
> cFNSV2h\
> 3186
> GVVZVNVExb3dOVmRUUmtVMFVXdEdiVTlGVmtOUlZURkVVV3BTUW1Rd2RFSlh
> WVkpYVld\
> 3187
> wQ1UxRnJUa1prTUdjd1UxZFNhVmRIZURaWlZtaFRZa2RPZEZadE5XaFhSVFIzV1RJ
> eFI\
> 3188
> yVlZlSFJOVkZaYVRXcHNNRmt3WkVka1YxWlVUbGR3YVUxcVFqTlJNbVJhVTFWM
> GRsZHJ\
> 3189
> iRFpoYWtKR1VWaGtTbEpHVGtKUldHUlRWVlZzYjFGV1FqVlBXRnBOVTFkR01WVnJ
> WbEp\
> 3190
> qYlhnMVlteGtNRlI2VmxOaVZYQXdZVmhTVW1GNlpFOVhSRkpMVlVoV2RWVklRaz
> lVYXp\
> 3191
> BeFZWUnNRbUZWUm5sa1JVNTBWRVprWVZSVmJFMVdiRTEyVFZWc1JWbFhjR2
> xqTVU1Sll\
> 3192
> tNXdkbUpYYjNkV1F6a3paVmhKY21Nd2RFdGpRM1IxVFhwU1VsQlVNR2xNUTBw
> b1dqSld\
> 3193
> kV1JETVhwaFYyUjFXbGRSZEZwSFJqQlpVMGsyU1cxV05WTnVaRnBYUjNoNldXcEt
> SMkV\
> 3194
> 3YkhGaU1teGhWMGQ0VEZrd1duZFhWbFowVFZVeFdGSnVRWGxYYTFwclZESkplR
> 05HYkZ\
> 3195
> SWFJrcHhXV3hhWVU1R2NFZGFSbVJzWWxaS1JWUldhR3RoYlVwVlVWUktXRlp0V
> W5KWmE\
> 3196
> yUkxaRlpXV1ZWdGNFNWlXR2d4VjFjd2VGWXlSWGRsUm1oV1lsZG9jbFZxUWxkalJ
> sRjV\
> 3197
> UbGh3YUZadGREWlZNakUwVjJ4a1IxTnVUbGhoTURFMFdrY3hTMk5HVGxWWGE
> zQm9ZVEo\
> 3198
> zZWxaR1pIZFNiVkpHVFZaV1UxZEdTazlXYTFwM1ZteFNWbFZyY0U5aGVrVXlWVlp
> TWVZ\
> 3199
> Sc1NrWlNha1pWVmxaS1ExcEVSbXRqUms1WlZHdHdhV0Y2Vm5wWFZFbDRZekp
> HU0ZOclV\
> 3200
> rNVhSbHB5Vm01d1IyTkdaSE5oUlhCb1ZsUnNkMVV5TVhkWGJGbDRZMGhTV0dK
> Rk1UTlV\
> 3201
> iRlUxVWxac05sRnJPVlpOUnpneFYyMTRSbUZWZUVSVGJuQm9WakpTTVZkV2FGT
> k5WMDU\
> 3202
> wVm01d1NtRnVRbWxhV0d4TFpESk9kRTlVUW1GV01EUjNWMnhrVW1GVk9YQlR
> iWGhzVmx\
> 3203
> oQ2RsZFhkR3RoYlVaV1QxaENWR0V4Y0ZkYVYzUnlaVVpTZEdKRmNHcE5SM2d3V
> 2tWb1E\
> 3204
> xbFdSWGRoZWtwVVZqTm9kbFZ0ZEhwbFZsWlpVMnhTYVdKclNrcFdhMVpUVVcxV
> 2MxSnV\
> 3205
> VbFJpVlZwVlZXdGFjbVZzVFhwalJ6bFhUVlpHTmxkWWNFTmhiRWw1V1ROa1ZVM
> UdSak5\
> 3206
> aVm1SaFZXdHNjR1F5YkdwTmJYaDFXVzB4UjAxSFVsbFRiWGhLWVcwNWNGZEVR
> azlsYXp\
> 3207
> sV1QxWm9VMkpyY0dGWmJHTTFaV3hOZDA5WVZsSlhSMUpUVjFSR1YyRXhiM2R
> qUlZaWVV\
> 3208
> qRndUVmxzVWt0WFZUbFhVMnhXVjFJd05URlVSazE0WXpGUmQwNVdRbWxTZW
> xaMlZqSjB\
> 3209
> SazFGT1VaWGJYUlhZa2hCZDFReFVrOWhNbEY0Vld0d1YxWlVWbGRYUkVwaFYyc
> zVWMWR\
> 3210
> 1UWxkaVJHdzFWWHBPVDFaV1JuSmhSa3BRVmpOQ2Vsa3haSHBsVjBsNldUSnNi
> VlpxUlR\
> 3211
> WSmFYZHBXVmRrYkdKdVVYUmpNbXh1WW1reGFscFlTakJKYW5CaVNXc3hTbE5
> WVGt0U1J\
> 3212
> VNUVVVmRPZUZvd1JqTlRWVXBDV2pCc1JsZEhlSEZSTURGRlVWVjBRMW95Wkho
> aFIzUnh\
> 3213
> WREZDVWxWVlVrSmhhMHB6VkZaR2VtUXdUbEpYVlZKWFZWWkdTRkpZWkV0U
> mJGWlZVbFp\
> 3214
> PVGxGclJraFJWRVpXVWxWT2JtUXdjRlZYUjNoRldXcEplR1F4YkZoT1ZGWk9WV3h
> XTTF\
> 3215
> KWVpGcFNSbHBTVlZWNFJWRllhRTlhVmxwUFRWWnNkVlJ1UW1GU01uaHZXVEk
> xY21WRlV\
> 3216
> qWlJWVFZEV2pBMVYxRnJSbXBVVlVweVRWUldWazF0ZDNkWGJGSkdXVlV4UTFv
> d1pFSk5\
> 3217
> WbFpHVVZoa00xVnNVbGxpUmxKb1YwWktjMVpWYUZkbGJVWkdUVmhhWVZJeF
> ducFZWRUp\
> 3218
> HWkRCb2Ixa3dOVTVoYTBZelZGZHdTazVGTVVWWk0zQk9aV3RGZDFZeWFHcFVh
> ekUyVVZ\
> 3219
> oa1RtRnJhekJVVlZKcVpXc3hObEZVUWxoaGEwcDBWRlpHZW1Rd1RsSlhWVkpYVl
> ZaR1N\
> 3220
> GSllaRXRSYkZaVlVsWk9UbEZyUmtoUlZFWldVbFZPYm1Rd2NGVlhSM2hGV1dwSm
> VHUXh\
> 3221
> iRmhPVkZaT1ZXeFdNMUpZWkZwU1JscFNWVlY0UlZGWWFFOWFWbHBQVFZac2
> RWUnVRbUZ\
> 3222
> TTW5odldUSTFjbVZGVWpaUlZUVkRXakExVjFGclJtcFVWVXB5VFZSV1ZrMXRkM2R
> YYkZ\
> 3223
> KR1dXc3hRMkV3WkVKTlZsWkdVVmhrTTFVeFVsbGlSbEpvVjBaS2MxWlZhRmRsYlV
> aR1R\
> 3224
> WaGFZVkl4V25wVlZtaERaREF4UjJFelpFWmtNV3hKVXpJNVlWTlljSEZOUlU1Q1ZW
> WnN\
> 3225
> TbE15T1dGVFdIQnhUVVZTUWxWWFRrVlZWMlJDVWxSWmQwMVZPSEppTW5CR
> VlUTktSVlZ\
> 3226
> 1WXpOYU1Hd3lWMnRWTUdGVVRUQmFSMHB2VVROR2NGSjZaSEZpTWprelYyN
> UJNR1ZJV2p\
> 3227
> aU2JsSk5XbnBhVlZaNlFtOVViVkpKWkd4Q1JWVXhVbnBrVm1oVVpWWmpOV1JJU
> 1hwUld\
> 3228
> HUkVZa2RhUkdJd1VsZFVia1pRWkhwc05WUldaekpVYlRWT1VqRldNMUpIWkZw
> U1JscFR\
> 3229
> UVVpDUWxWVlozWlJhMFpTVWtWR2JscFZSazVSYW1oSVVWUkdWbHBGYkROVl
> ZteE9VVzF\
> 3230
> HUWxKcmJ6TlRTRkpVWkROQ1RWUklWbEJYYW1ScVlUQkdjMVZWYUZaTk1tUkN
> WRmRqZGx\
> 3231
> Ock1VTk5SV1JDVFZaV2ExSkhaRkpXTUVwRFZXMU9WVTVVVFRCaWF6RmFaR3hT
> YWxKdVV\
> 3232
> uSmFia295VGpOb1ZrNHdVbkJpVldoeFpXdEdWVkZ0WkU5V2EyaFVWbFZXUlZKRlJ
> reFJ\
> 3233
> iV1J1WTJ0S2JsSlZXa05WVjA1RlVWZHdRbE13U201YU0wWnZZVEp3VUZWR1JsSl
> NSVVp\
> 3234
> 1Vkd0c1FsSkZTa2RSVjJ4R1VWaENTMDR6YUhkVWJGWXlWVlZ3U0UxRk5XOVVS
> MGwyV2x\
> 3235
> oU2FVMXFRazFTUmxWNFRtMTRkMVV3YUZCT01rWnNZbnBDVjFkWVozZGxTR1J
> FVTFWRmN\
> 3236
> sUjZWWFpYVkZwRllVTjBhVkZxU1RSTmFsSXhZVmRHVUZWWFJsWlNSRnB1VVZV
> MWIxZFV\
> 3237
> iRmRTYlZGeVlXNUtlVmt3VmpKVGJsRnBURU5LVGxOVmJFUlNNVkpFVVRCR2FVc3
> laRUp\
> 3238
> rTUd4RFVWZGtTbEpXYUhOaGEwVjJaV3RHVEZGdFpHNWpWMmh5WVdzNVVWV
> ldSa1ZSVjN\
> 3239
> CRFdUQXhVbU16WkVSVlZteEZWbXhHVWxJd1ZqTlRhMHBXVmtWV1ZGUlZTa0pT
> TUVWNFZ\
> 3240
> sVldSRm96WkV0V1JtaHpVa2RKZVUxWVpGcFdlbFV4VkZaS1ZtUXdWak5YVlZKWF
> ZWWkd\
> 3241
> UVkpGUmpSVWJWWlhWR3BHV21Kck5YZFhhMlJ6WVVkT2RXRXphRVZsYTBaUFV
> XMWtUMVp\
> 3242
> yU2tKWk1ERkRZWHBGTVZaVVNuTk5SbkJWVWxaS1RsRlVhRWhSVkVaV1VsVkdN
> MlF3YkZ\
> 3243
> WWFIzaFZXVlpvVTJKR1JYZFNXR1JKWVVkT1QxUlhjRUprTURGeFUxUlNUbEpIVGp
> WVWJ\
> 3244
> uQldUbFprYjFrd05VNWxhMFl6VkZkd1NrNUZNVVZaTTJ4UFpXeFZNVll5Y0VOaVJU
> RlN\
> 3245
> Zek5rUkZWV2JFVldiRVpTVWpCV00xTnJTbFpXUlZaVVZGVktRbEl3UlhoV1ZWWkV
> Xak5\
> 3246
> rUzFaR2FITlNSMGw1VFZoa1dsWjZWVEZVVmtwV1pEQldNMWRWVWxkVlZrWk5
> Va1ZHTkZ\
> 3247
> SdFZsZFVha1phWW1zMWQxZHJaSE5oUjA1MVlUTm9SV1ZyUms5UmJXUlBWbXR
> LUWxrd01\
> 3248
> VTmhla1V4VmxSS2MwMUdjRlZTVjBaT1VXMWtTRkZVUmxaU1ZVWXpaREZLVlZk
> SGVGVlp\
> 3249
> WbWhUWWtaV1NWWnVjR2hTVkVZeVYydGtWMk14UlhkU1dHUllWa1ZHVlZGdF
> pHcGpWMmh\
> 3250
> 5WVdzNVVWVlZiRU5SYldSdVkxZG9jbUZyT1ZGVlZURkRVVzVrVDFFd1JrSlZhM0JEV
> m0\
> 3251
> wNWVscEZkRE5YVlRVMFlWWkNORk5JV25CU2JrWk1aV3RTYzA5WFdqQlVTRlpP
> V1ZjeGQ\
> 3252
> xSnNSbXBYU0dONFRXcGthRlJ0T1ZOWmJrNUpUREJhVG1OdE1UWlJNRVpKVFhw
> ak0wMTZ\
> 3253
> UbXBOYlRscFZVZE9jMlJzVG5sWFZVb3lUVVZPTUZZeFJqQlpWRnBvU3pKT2RrMXNi
> RE5\
> 3254
> YYTFKQ1ZUQktibFJzV2tsVmF6RkRVVmRaTkZKVlRrVlJWV1JDVlZWbmRsRlhaRVpS
> VlR\
> 3255
> GQ1RrVmtRazFXVm10U1NHUkdVV2s1TTFWVlZrSmtNR3hFVVd0U1FscHJTbTVVY
> kZwSlZ\
> 3256
> UQXhSbEl3VWtKV01tUkRWVmh3TkdWdVpIZFZia0pOWlZNNWVWUldWbHBsYlV
> adlRXNU5\
> 3257
> lRTB5VmxaUFYyUkhaV3RHYTFGdFpFOVdhMmhTVGtWV1Ixb3hSbFppYms1c1RW
> VjRSR0V\
> 3258
> 6VGpGT1JGWjFaRWhzVWxFeFdrSmFSbEpzVVZWR05WSkVhSEprTUU1dVYxVnNU
> R0l4Y0V\
> 3259
> wbGJXOTNVbFZHTTFOVlVsUlJWVVl6Vld4R1NtRkZSa3BqTVd4eldsWndUR015Y0V
> kVWE\
> 3260
> wNTZVMnQwYkZWSGVFaFVWVVpOV2xoQ1YxcFViRVpVUkdSUFlqTlJNVTFVVmp
> ObFJ6Rlh\
> 3261
> aRlZ3UTFGWGJFSlpNRlpPVmxaV2IxSldUbnBVUm1SUlRsaG9WRlZXVlhkWFNFWTJ
> WbTV\
> 3262
> GTkZkWVduQlNha1pwVm0wNU5sSXpjRFJPV0hCUFdqSk9lbVI2TURsSmJERTVabE
> VpTEN\
> 3263
> KemFXZHVZWFIxY21WeklqcGJleUp3Y205MFpXTjBaV1FpT2lKbGVVbzBUbGROYV
> U5c2M\
> 3264
> ybFVWV3hLVVRCb2NWRXdUa0paTVU1dVVWaGtTbEZyUm01VFZXUkNWMGRvT
> UUxVVVucGl\
> 3265
> NREZDWWpCa1JGRXpSa2hWTURBd1QxVktRbFJWVGs1U1ZtdzBVVE53UWxOclN
> tNVViRnB\
> 3266
> EVVZac1ZWRlhkRTlUVlRGVFZGaGtSbFZXYkVWV2JFWlNVekJTUW1OR1VtaFdNV
> m93VjJ\
> 3267
> 4ak1XVnJiRVpTYTJoT1ZWUm9NMUpHUmxwU1JscFNWVlY0UlZGV2NFUldhMDV
> EVWtaV1I\
> 3268
> xUllhRVpXUlVaUlVXMWtUMVpyU2tKVVZURkVVbXh3YzFsdE1WTmtiVTV5Vkd0S1
> RsRXd\
> 3269
> SbGxTUmxKS1pVVXhSVlJZYkU5aGEwVXhWRmR3U21WVk5WZGlNV3hGWlcxek1
> WUXhVbkp\
> 3270
> sUlRGeFZGaG9UbUZyTUhoVU1WSldUbFprY1ZGdGFFNVZXRTR6VVRGR1dsSkdXbE
> pWVld\
> 3271
> SR1pEQndSVlV3VWtaV1JURkRVbFZrUWsxV1ZrWlJNbVF6VXpGVmVXSkhlR2xXTVZ
> veFd\
> 3272
> UTnNRMUZzU2paU1ZrSk9VVlJDU0ZGVVJsWlNWVTR6WkRCa1VtSkdSbTVWVkVa
> RFZrVXh\
> 3273
> VMVZZWkVaYU1XeEZWbXhHVWxKclZqTmtSM0JhVmpGd2RGZHNUWGRPVlRsRld
> YcENUMVp\
> 3274
> GVmxoVVZVcFNVakJGZUZaVlZrSmtNMlJQVmxWYWIxSkZNVFZPVlZwUFpXeFdNRl
> JXVWt\
> 3275
> Ka01VWlZVV3h3VGxGck1VaFJibXg0VWpGT1RrNUViRUphTUZaSVVUQk9lRkl4VGs
> 1T1J\
> 3276
> HeENaREJXU1ZGVVFrcFJWVXBQVFVSb2NWWXdlSHBOUjBadlV6Qm9XbGR1Vm0
> 5aVZ6Rmp\
> 3277
> UREpqTkdScVVsaFRNR2d5VVZoU2FGcHNSazFSVTNSS1pGVXhUMkZITVc1aFZ6Rll
> UakJ\
> 3278
> HVG1OdVJtOWlWMHBWVFRCc2FGVkZUalZoUnpGaFUxWk9kMVI2V20xaVUzTXl
> VMWhhWTB\
> 3279
> 3eldrcGphM1J2VlZaU01WWnRPVXhoYldSYVVWaGtiV0ZyUm5aUmJXUnVZMnRLY
> mxKVld\
> 3280
> rTlZWMDVEVTFWR1Vsa3dVa05qU0ZKYVYwVTFiMVJHYUZOaVIwMTZWVmhXYW
> sxdGVITlp\
> 3281
> iR1JYWkZkT05VNVhjR2xOYWtFeVZERlNVazFGTVRaUlZsSkRXakExVjFOR1RsWlN
> WVkp\
> 3282
> GVVZWMFExb3laSGxSYldSR1VtdEtVbGt3VWtKV1JVWlFVVzFrVDFacmFGSlBSVXB
> DV21\
> 3283
> wb1JsRnJSazVSTUVrd1VWaGtUVlZXYkVWV2JFbDNWV3RLUkZkWVpFdFRWV3h3
> V2tWa2I\
> 3284
> ySkZlSFZYYlhocFlsWktNbGt5YXpGaGJHeFlUa2hXYVdKVWEzZFVSekV3WkZkSmVsa
> 3p\
> 3285
> WbXRTTW1oM1dUTnJNVTFzYkZobFJFWmhWa1ZHVEZGdFpHNWpWMmh5WVdz
> NVVWVldSa1Z\
> 3286
> SVjJSUFUxVkdSVkZyV2tKaFZVazFVVzB4ZUZRemNIRlZWR2hzV1ZkamVWTnVVblpr
> Vmx\
> 3287
> KdlVsWm9lVm93T1VOWFZsRjNVWHBvWVdSRGREVlBWemxKVWtad1JWbHNVbE
> pUVjJoQ1Z\
> 3288
> HMXpNbVJIT1ZOaU1sWkVXVmMxYUZSWGNFNVdSWGgwWWxaV2RXSlhTbkphY
> WtKNldsaGF\
> 3289
> jbEV3YnpSTmJXc3hWbGhHY1ZWcldsZFZVMHBrVEVOS2FHSkhZMmxQYVVwR1ZYc
> EpNVTV\
> 3290
> wU2praUxDSnphV2R1WVhSMWNtVWlPaUphWTFwa1dYbzBiMUl3UjJKc09UWnF
> NWGxZWm5\
> 3291
> kdlRYZGxVVGt6VGpCdFNVUmxjVFkyVTBacWRFdG9lR1pSWjNJMGRUWkpOVEJK
> WldNMmE\
> 3292
> xWTJhSEV3YVcxdlptTlBhVGs0VW1OSVpXUmpNVzFuZHpCWVp5SjlYWDA9IiwiY3Jl
> YXR\
> 3293
> lZC1vbiI6IjIwMjItMDItMjJUMDc6MzM6MjUuMDIwWiIsImFnZW50LXNpZ24tY2Vy
> dCI\
> 3294
> 6WyJNSUlDSkRDQ0FjcWdBd0lCQWdJRVhsakNNREFLQmdncWhrak9QUVFEQWp
> CbE1Rc3d\
> 3295
> DUVlEVlFRR0V3SkJVVEVTTUJBR0ExVUVDZ3dKVFhsRGIyMXdZVzU1TVJVd0V3WU
> RWUVF\
> 3296
> MREF4TmVWTjFZbk5wWkdsaGNua3hEekFOQmdOVkJBY01CazE1VTJsMFpURWF
> NQmdHQTF\
> 3297
> VRUF3d1JUWGxUYVhSbFVIVnphRTF2WkdWc1EwRXdIaGNOTWpBd01qSTRNRG
> N6TXpBMFd\
> 3298
> oY05NekF3TWpJNE1EY3pNekEwV2pCbU1Rc3dDUVlEVlFRR0V3SkJVVEVTTUJBR0
> ExVUV\
> 3299
> DZ3dKVFhsRGIyMXdZVzU1TVJVd0V3WURWUVFMREF4TmVWTjFZbk5wWkdsaG
> Nua3hEekF\
> 3300
> OQmdOVkJBY01CazE1VTJsMFpURWJNQmtHQTFVRUF3d1NUWGxUYVhSbFVIVn
> phRTF2Wkd\
> 3301
> Wc1FYQndNRmt3RXdZSEtvWkl6ajBDQVFZSUtvWkl6ajBEQVFjRFFnQUU2MDFPK2
> 9qQ2t\
> 3302
> yRFJ3N2dJdlpFNGkzNGRiaENxaUc3am9vd1pwNHh2ekZ0TGc2VFcwaE5kSHZQRF
> NUc3V\
> 3303
> YU3lXOXRyM0F3Q2xmQ29EVk5xT3c5eU1YNk5uTUdVd0RnWURWUjBQQVFIL0J
> BUURBZ2V\
> 3304
> BTUI4R0ExVWRJd1FZTUJhQUZKN0h0U3dwTEx1T1o3Y2tBbFFIVTNnQU1nL0pNQj
> BHQTF\
> 3305
> VZERnUVdCQlJjVDUzNG5NWXZUY0Z0a2Zydjd4VTdEaW1IanpBVEJnTlZIU1VFRER
> BS0J\
> 3306
> nZ3JCZ0VGQlFjREFqQUtCZ2dxaGtqT1BRUURBZ05JQURCRkFpRUFwSjd4cE5VdlFK
> RzB\
> 3307
> OaExiL2V0YjIwTERVMTZscFNITzdhZW8wVll4MHh3Q0lBK081L1k2RGgrYkIyODI0d
> Wl\
> 3308
> hT1FhVUQ2Z0FOaFk5VkZkK2pycmNFdkp0IiwiTUlJQ0dUQ0NBYitnQXdJQkFnSUVY
> bGp\
> 3309
> BL3pBS0JnZ3Foa2pPUFFRREFqQmNNUXN3Q1FZRFZRUUdFd0pCVVRFU01CQUdB
> MVVFQ2d\
> 3310
> 3SlRYbERiMjF3WVc1NU1SVXdFd1lEVlFRTERBeE5lVk4xWW5OcFpHbGhjbmt4RHp
> BTkJ\
> 3311
> nTlZCQWNNQmsxNVUybDBaVEVSTUE4R0ExVUVBd3dJVFhsVGFYUmxRMEV3SGh
> jTk1qQXd\
> 3312
> Nakk0TURjeU56VTVXaGNOTXpBd01qSTRNRGN5TnpVNVdqQmxNUXN3Q1FZRFZ
> RUUdFd0p\
> 3313
> CVVRFU01CQUdBMVVFQ2d3SlRYbERiMjF3WVc1NU1SVXdFd1lEVlFRTERBeE5lVk
> 4xWW5\
> 3314
> OcFpHbGhjbmt4RHpBTkJnTlZCQWNNQmsxNVUybDBaVEVhTUJnR0ExVUVBd3dS
> VFhsVGF\
> 3315
> YUmxVSFZ6YUUxdlpHVnNRMEV3V1RBVEJnY3Foa2pPUFFJQkJnZ3Foa2pPUFFNQ
> kJ3TkN\
> 3316
> BQVJKQlZvc2RLd1lOeGlQeEh2aUZxS3pEbDlmdEx1TWFtcEZRY1h3MTI3YU5vUmJ
> zSC9\
> 3317
> GTXJtekNBSDM3NzMzYzJvYlBjbHZTcllCdjBDdFdRdGE2YStjbzJZd1pEQVNCZ05WSF
> J\
> 3318
> NQkFmOEVDREFHQVFIL0FnRUFNQTRHQTFVZER3RUIvd1FFQXdJQ0JEQWZCZ05
> WSFNNRUd\
> 3319
> EQVdnQlF6eHp3cFJwTHkvck1VWXphaDJzMTNlVTlnRnpBZEJnTlZIUTRFRmdRVW5
> zZTF\
> 3320
> MQ2tzdTQ1bnR5UUNWQWRUZUFBeUQ4a3dDZ1lJS29aSXpqMEVBd0lEU0FBd1J
> RSWhBSXN\
> 3321
> ZbGVaS3NqRk5Dc0pLZVBsR01BTGVwVmU5RUw3Tm90NTE1d3htVnVKQkFpQW
> NFTVVVaEV\
> 3322	   Tc0xXUDV4U1FVMFhxelZxOFl2aUYxYlZvekd6eDV6Tmdjc3c9PSJdfX0",
> 3323	     "signatures":[{
> 3324
> "protected":"eyJ4NWMiOlsiTUlJQjhEQ0NBWmFnQXdJQkFnSUdBWEJoTUtZSU1\
> 3325
> Bb0dDQ3FHU000OUJBTUNNRnd4Q3pBSkJnTlZCQVlUQWtGUk1SSXdFQVlEVlFRS
> 0RBbE5\
> 3326
> lVU52YlhCaGJua3hGVEFUQmdOVkJBc01ERTE1VTNWaWMybGthV0Z5ZVRFUE1B
> MEdBMVV\
> 3327
> FQnd3R1RYbFRhWFJsTVJFd0R3WURWUVFEREFoTmVWTnBkR1ZEUVRBZUZ3MHl
> NREF5TWp\
> 3328
> Bd05qQXlNak5hRncwek1EQXlNakF3TmpBeU1qTmFNSGt4Q3pBSkJnTlZCQVlUQ
> WtGUk1\
> 3329
> SSXdFQVlEVlFRS0RBbE5lVU52YlhCaGJua3hGVEFUQmdOVkJBc01ERTE1VTNWaW
> MybGt\
> 3330
> hV0Z5ZVRFUE1BMEdBMVVFQnd3R1RYbFRhWFJsTVM0d0xBWURWUVFERENWU
> 1pXZHBjM1J\
> 3331
> 5WVhJZ1ZtOTFZMmhsY2lCU1pYRjFaWE4wSUZOcFoyNXBibWNnUzJWNU1Ga3dF
> d1lIS29\
> 3332
> aSXpqMENBUVlJS29aSXpqMERBUWNEUWdBRUJUVFwvc1JmTDlsSnVGbVwvY24
> zU2pHcWp\
> 3333
> QXC9xdnBrNytoSTIwOE5oVkRvR2hcLzdLUCt2TXpYeVFRQStqUjZrNnJhTTI4Zlwvb
> HV\
> 3334
> FK1h1aHVwN1Vmem05Q3FNbk1DVXdFd1lEVlIwbEJBd3dDZ1lJS3dZQkJRVUhBeH
> d3RGd\
> 3335
> ZRFZSMFBBUUhcL0JBUURBZ2VBTUFvR0NDcUdTTTQ5QkFNQ0EwZ0FNRVVDSUh
> OK3VBbUp\
> 3336
> ldVhlc1wveWQxd1M0Mlo0RFhKNEptMWErZzNYa1pnZjhUaGxuQWlFQXBVdTZzZ
> nljRWt\
> 3337
> veDdSWlhtZitLOHc0cDZzUldyamExUVJwWTAyNjQxSFk9IiwiTUlJQjhEQ0NBWmV
> nQXd\
> 3338
> JQkFnSUdBWEJoTUtZQk1Bb0dDQ3FHU000OUJBTUNNRnd4Q3pBSkJnTlZCQVlUQ
> WtGUk1\
> 3339
> SSXdFQVlEVlFRS0RBbE5lVU52YlhCaGJua3hGVEFUQmdOVkJBc01ERTE1VTNWaW
> MybGt\
> 3340
> hV0Z5ZVRFUE1BMEdBMVVFQnd3R1RYbFRhWFJsTVJFd0R3WURWUVFEREFoTm
> VWTnBkR1Z\
> 3341
> EUVRBZUZ3MHlNREF5TWpBd05qQXlNak5hRncwek1EQXlNakF3TmpBeU1qTmFN
> Rnd4Q3p\
> 3342
> BSkJnTlZCQVlUQWtGUk1SSXdFQVlEVlFRS0RBbE5lVU52YlhCaGJua3hGVEFUQmd
> OVkJ\
> 3343
> Bc01ERTE1VTNWaWMybGthV0Z5ZVRFUE1BMEdBMVVFQnd3R1RYbFRhWFJsTVJ
> Fd0R3WUR\
> 3344
> WUVFEREFoTmVWTnBkR1ZEUVRCWk1CTUdCeXFHU000OUFnRUdDQ3FHU000O
> UF3RUhBMEl\
> 3345
> BQkluQ3VoV1ZzZ2NONzFvWmVzMUZHXC9xZFZnTVBva01wZlMyNzFcL2V5SWNc
> L29EVmJ\
> 3346
> NRkhDYmV2SjVMTTgxOTVOYVpLTlNvSFAzS3dMeXVCaDh2MncwOVp1alJUQkRN
> QklHQTF\
> 3347
> VZEV3RUJcL3dRSU1BWUJBZjhDQVFFd0RnWURWUjBQQVFIXC9CQVFEQWdJRU1
> CMEdBMVV\
> 3348
> kRGdRV0JCUXp4endwUnBMeVwvck1VWXphaDJzMTNlVTlnRnpBS0JnZ3Foa2pPU
> FFRREF\
> 3349
> nTkhBREJFQWlCZGJIU212YW9qaDBpZWtaSUtOVzhRMGxTbGI1K0RLTlFcL05LY1I
> 3dWx\
> 3350
> 6dGdJZ2RwejZiUkYyREZtcGlKb3JCMkd5VmE4YVdkd2xIc0RvRVdZY0k0UEdKYmc9I
> l0\
> 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
> udC1wcm94aW1pdHkiLCJzZXJpYWwtbnVtYmVyIjoiMDEyMzQ1Njc4OSIsIm5vbm
> NlIjo\
> 3370
> iTDNJSjZocHRIQ0lRb054YWFiOUhXQT09IiwiY3JlYXRlZC1vbiI6IjIwMjItMDQtMjZ\
> 3371
> UMDU6MTY6MjguNzI2WiIsInBpbm5lZC1kb21haW4tY2VydCI6Ik1JSUJwRENDQV
> VtZ0F\
> 3372
> 3SUJBZ0lHQVcwZUx1SCtNQW9HQ0NxR1NNNDlCQU1DTURVeEV6QVJCZ05WQk
> FvTUNrMTV\
> 3373
> RblZ6YVc1bGMzTXhEVEFMQmdOVkJBY01CRk5wZEdVeER6QU5CZ05WQkFNTUJs
> UmxjM1J\
> 3374
> EUVRBZUZ3MHhPVEE1TVRFd01qTTNNekphRncweU9UQTVNVEV3TWpNM016S
> mFNRFV4RXp\
> 3375
> BUkJnTlZCQW9NQ2sxNVFuVnphVzVsYzNNeERUQUxCZ05WQkFjTUJGTnBkR1V4
> RHpBTkJ\
> 3376
> nTlZCQU1NQmxSbGMzUkRRVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXd
> FSEEwSUF\
> 3377
> CT2t2a1RIdThRbFQzRkhKMVVhSTcrV3NIT2IwVVMzU0FMdEc1d3VLUURqaWV4
> MDYvU2N\
> 3378
> ZNVBKaWJ2Z0hUQitGL1FUamdlbEhHeTFZS3B3Y05NY3NTeWFqUlRCRE1CSUdB
> MVVkRXd\
> 3379
> FQi93UUlNQVlCQWY4Q0FRRXdEZ1lEVlIwUEFRSC9CQVFEQWdJRU1CMEdBMVVk
> RGdRV0J\
> 3380
> CVG9aSU16UWRzRC9qLytnWC83Y0JKdWNIL1htakFLQmdncWhrak9QUVFEQWd
> OSkFEQkd\
> 3381
> BaUVBdHhRMytJTEdCUEl0U2g0YjlXWGhYTnVocVNQNkgrYi9MQy9mVllEalE2b0
> NJUUR\
> 3382
> HMnVSQ0hsVnEzeWhCNThUWE1VYnpIOCtPbGhXVXZPbFJEM1ZFcURkY1F3PT0if
> X0",
> 3383	     "signatures":[{
> 3384
> "protected":"eyJ4NWMiOlsiTUlJQmt6Q0NBVGlnQXdJQkFnSUdBV0ZCakNrWU1\
> 3385
> Bb0dDQ3FHU000OUJBTUNNRDB4Q3pBSkJnTlZCQVlUQWtGUk1SVXdFd1lEVlFRS
> 0RBeEt\
> 3386
> hVzVuU21sdVowTnZjbkF4RnpBVkJnTlZCQU1NRGtwcGJtZEthVzVuVkdWemRFTkJ
> NQjR\
> 3387
> YRFRFNE1ERXlPVEV3TlRJME1Gb1hEVEk0TURFeU9URXdOVEkwTUZvd1R6RUxNQ
> WtHQTF\
> 3388
> VRUJoTUNRVkV4RlRBVEJnTlZCQW9NREVwcGJtZEthVzVuUTI5eWNERXBNQ2NH
> QTFVRUF\
> 3389
> 3d2dTbWx1WjBwcGJtZERiM0p3SUZadmRXTm9aWElnVTJsbmJtbHVaeUJMWlhrd
> 1dUQVR\
> 3390
> CZ2NxaGtqT1BRSUJCZ2dxaGtqT1BRTUJCd05DQUFTQzZiZUxBbWVxMVZ3NmlRcl
> JzOFI\
> 3391
> wWlcrNGIxR1d5ZG1XczJHQU1GV3diaXRmMm5JWEgzT3FIS1Z1OHMyUnZpQkdO
> aXZPS0d\
> 3392
> CSEh0QmRpRkVaWnZiN294SXdFREFPQmdOVkhROEJBZjhFQkFNQ0I0QXdDZ1lJS2
> 9aSXp\
> 3393
> qMEVBd0lEU1FBd1JnSWhBSTRQWWJ4dHNzSFAyVkh4XC90elVvUVwvU3N5ZEwz
> MERRSU5\
> 3394
> FdGNOOW1DVFhQQWlFQXZJYjNvK0ZPM0JUbmNMRnNhSlpSQWtkN3pPdXNuXC
> 9cL1pLT2F\
> 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
> udC1wcm94aW1pdHkiLCJzZXJpYWwtbnVtYmVyIjoiMDEyMzQ1Njc4OSIsIm5vbm
> NlIjo\
> 3415
> iUUJiSXMxNTJzbkFvVzdSeVFMWENvZz09IiwiY3JlYXRlZC1vbiI6IjIwMjItMDktMjl\
> 3416
> UMDM6Mzc6MjYuMzgyWiIsInBpbm5lZC1kb21haW4tY2VydCI6Ik1JSUJwRENDQ
> VVtZ0F\
> 3417
> 3SUJBZ0lHQVcwZUx1SCtNQW9HQ0NxR1NNNDlCQU1DTURVeEV6QVJCZ05WQk
> FvTUNrMTV\
> 3418
> RblZ6YVc1bGMzTXhEVEFMQmdOVkJBY01CRk5wZEdVeER6QU5CZ05WQkFNTUJs
> UmxjM1J\
> 3419
> EUVRBZUZ3MHhPVEE1TVRFd01qTTNNekphRncweU9UQTVNVEV3TWpNM016S
> mFNRFV4RXp\
> 3420
> BUkJnTlZCQW9NQ2sxNVFuVnphVzVsYzNNeERUQUxCZ05WQkFjTUJGTnBkR1V4
> RHpBTkJ\
> 3421
> nTlZCQU1NQmxSbGMzUkRRVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXd
> FSEEwSUF\
> 3422
> CT2t2a1RIdThRbFQzRkhKMVVhSTcrV3NIT2IwVVMzU0FMdEc1d3VLUURqaWV4
> MDYvU2N\
> 3423
> ZNVBKaWJ2Z0hUQitGL1FUamdlbEhHeTFZS3B3Y05NY3NTeWFqUlRCRE1CSUdB
> MVVkRXd\
> 3424
> FQi93UUlNQVlCQWY4Q0FRRXdEZ1lEVlIwUEFRSC9CQVFEQWdJRU1CMEdBMVVk
> RGdRV0J\
> 3425
> CVG9aSU16UWRzRC9qLytnWC83Y0JKdWNIL1htakFLQmdncWhrak9QUVFEQWd
> OSkFEQkd\
> 3426
> BaUVBdHhRMytJTEdCUEl0U2g0YjlXWGhYTnVocVNQNkgrYi9MQy9mVllEalE2b0
> NJUUR\
> 3427
> HMnVSQ0hsVnEzeWhCNThUWE1VYnpIOCtPbGhXVXZPbFJEM1ZFcURkY1F3PT0if
> X0",
> 3428	     "signatures":[{
> 3429
> "protected":"eyJ4NWMiOlsiTUlJQmt6Q0NBVGlnQXdJQkFnSUdBV0ZCakNrWU1\
> 3430
> Bb0dDQ3FHU000OUJBTUNNRDB4Q3pBSkJnTlZCQVlUQWtGUk1SVXdFd1lEVlFRS
> 0RBeEt\
> 3431
> hVzVuU21sdVowTnZjbkF4RnpBVkJnTlZCQU1NRGtwcGJtZEthVzVuVkdWemRFTkJ
> NQjR\
> 3432
> YRFRFNE1ERXlPVEV3TlRJME1Gb1hEVEk0TURFeU9URXdOVEkwTUZvd1R6RUxNQ
> WtHQTF\
> 3433
> VRUJoTUNRVkV4RlRBVEJnTlZCQW9NREVwcGJtZEthVzVuUTI5eWNERXBNQ2NH
> QTFVRUF\
> 3434
> 3d2dTbWx1WjBwcGJtZERiM0p3SUZadmRXTm9aWElnVTJsbmJtbHVaeUJMWlhrd
> 1dUQVR\
> 3435
> CZ2NxaGtqT1BRSUJCZ2dxaGtqT1BRTUJCd05DQUFTQzZiZUxBbWVxMVZ3NmlRcl
> JzOFI\
> 3436
> wWlcrNGIxR1d5ZG1XczJHQU1GV3diaXRmMm5JWEgzT3FIS1Z1OHMyUnZpQkdO
> aXZPS0d\
> 3437
> CSEh0QmRpRkVaWnZiN294SXdFREFPQmdOVkhROEJBZjhFQkFNQ0I0QXdDZ1lJS2
> 9aSXp\
> 3438
> qMEVBd0lEU1FBd1JnSWhBSTRQWWJ4dHNzSFAyVkh4XC90elVvUVwvU3N5ZEwz
> MERRSU5\
> 3439
> FdGNOOW1DVFhQQWlFQXZJYjNvK0ZPM0JUbmNMRnNhSlpSQWtkN3pPdXNuXC
> 9cL1pLT2F\
> 3440
> FS2JzVkRpVT0iXSwidHlwIjoidm91Y2hlci1qd3MranNvbiIsImFsZyI6IkVTMjU2In0\
> 3441	   ",
> 3442
> "signature":"ShqW8uFRkuAXIzjAhB4bolMMndcY7GYq3Kbo94yvGtjCaxEX3Hp\
> 3443	   6QXZUTEJ_kulQ1G7DnaU4igDPdUGtcV9Lkw"},{
> 3444
> "protected":"eyJ4NWMiOlsiTUlJQjRqQ0NBWWlnQXdJQkFnSUdBWFk3MmJiWk1
> \
> 3445
> Bb0dDQ3FHU000OUJBTUNNRFV4RXpBUkJnTlZCQW9NQ2sxNVFuVnphVzVsYzNN
> eERUQUx\
> 3446
> CZ05WQkFjTUJGTnBkR1V4RHpBTkJnTlZCQU1NQmxSbGMzUkRRVEFlRncweU1ER
> XlNRGN\
> 3447
> 3TmpFNE1USmFGdzB6TURFeU1EY3dOakU0TVRKYU1ENHhFekFSQmdOVkJBb01
> DazE1UW5\
> 3448
> WemFXNWxjM014RFRBTEJnTlZCQWNNQkZOcGRHVXhHREFXQmdOVkJBTU1EM
> FJ2YldGcGJ\
> 3449
> sSmxaMmx6ZEhKaGNqQlpNQk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VIQTBJ
> QUJCazE\
> 3450
> 2S1wvaTc5b1JrSzVZYmVQZzhVU1I4XC91czFkUFVpWkhNdG9rU2RxS1c1Zm5Xc0J
> kK3F\
> 3451
> STDdXUmZmZVdreWdlYm9KZklsbHVyY2kyNXduaGlPVkNHamV6QjVNQjBHQTFVZ
> EpRUVd\
> 3452
> NQlFHQ0NzR0FRVUZCd01CQmdnckJnRUZCUWNESERBT0JnTlZIUThCQWY4RUJB
> TUNCNEF\
> 3453
> 3U0FZRFZSMFJCRUV3UDRJZGNtVm5hWE4wY21GeUxYUmxjM1F1YzJsbGJXVnVje
> TFpZEM\
> 3454
> 1dVpYU0NIbkpsWjJsemRISmhjaTEwWlhOME5pNXphV1Z0Wlc1ekxXSjBMbTVsZE
> RBS0J\
> 3455
> nZ3Foa2pPUFFRREFnTklBREJGQWlCeGxkQmhacTBFdjVKTDJQcldDdHlTNmhEWV
> cxeUN\
> 3456
> PXC9SYXVicEM3TWFJRGdJaEFMU0piZ0xuZ2hiYkFnMGRjV0ZVVm9cL2dHTjBcL2p3
> ekp\
> 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]
> 
> 3867	Authors' Addresses
> 
> 3869	   Steffen Fries
> 3870	   Siemens AG
> 3871	   Otto-Hahn-Ring 6
> 3872	   81739 Munich
> 3873	   Germany
> 3874	   Email: [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]
> 3883	   URI:   https://www.siemens.com/
> 
> 3885	   Eliot Lear
> 3886	   Cisco Systems
> 3887	   Richtistrasse 7
> 3888	   CH-8304 Wallisellen
> 3889	   Switzerland
> 3890	   Phone: [phone]
> 3891	   Email: [e-mail]
> 
> 3893	   Michael C. Richardson
> 3894	   Sandelman Software Works
> 3895	   Email: [e-mail]
> 3896	   URI:
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.san
> delman.ca%2F&data=05%7C01%7Csteffen.fries%40siemens.com%7C3fa08d366
> 121415a42d408db195748ce%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7
> C0%7C638131634926932386%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
> %7C&sdata=xcssht4QN48nD63vtHhhqD%2F5N%2BE6Blf%2Fns9OgWkmCs8%3D
> &reserved=0
> 
> 
> 
> 
> 
> 
>