anima-jws-voucher.xml

<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.23 (Ruby 2.6.10) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-anima-jws-voucher-09" category="std" consensus="true" submissionType="IETF" updates="8366" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.16.0 -->
  <front>
    <title abbrev="JWS-voucher">JWS signed Voucher Artifacts for Bootstrapping Protocols</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-anima-jws-voucher-09"/>
    <author initials="T." surname="Werner" fullname="Thomas Werner">
      <organization>Siemens AG</organization>
      <address>
        <email>thomas-werner@siemens.com</email>
      </address>
    </author>
    <author initials="M." surname="Richardson" fullname="Michael Richardson">
      <organization>Sandelman Software Works</organization>
      <address>
        <email>mcr+ietf@sandelman.ca</email>
      </address>
    </author>
    <date year="2023" month="August" day="29"/>
    <area>Internet</area>
    <workgroup>anima Working Group</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>[TODO: I-D.draft-ietf-anima-rfc8366bis] defines a digital artifact called voucher as a YANG-defined JSON document that is signed using a Cryptographic Message Syntax (CMS) structure.
This document introduces a variant of the voucher artifact in which CMS is replaced by the JSON Object Signing and Encryption (JOSE) mechanism described in RFC7515 to support deployments in which JOSE is preferred over CMS.</t>
      <t>In addition to explaining how the format is created, the "application/voucher-jws+json" media type is registered and examples are provided.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <t>"A Voucher Artifact for Bootstrapping Protocols" <xref target="I-D.draft-ietf-anima-rfc8366bis"/> defines a YANG-based data structure used in "Bootstrapping Remote Secure Key Infrastructure" <xref target="BRSKI"/> and
"Secure Zero Touch Provisioning" <xref target="SZTP"/> to transfer ownership of a device from a manufacturer to a new owner (customer or operational domain).
That document provides a serialization of the voucher data to JSON <xref target="RFC8259"/> (JSON Voucher Data) with cryptographic signing according to the Cryptographic Message Syntax (CMS) <xref target="RFC5652"/>.
The resulting voucher artifact has the media type "application/voucher-cms+json".</t>
      <t><xref target="I-D.ietf-anima-constrained-voucher"/> provides a serialization of the voucher data to CBOR <xref target="RFC8949"/>
with the signature format of COSE <xref target="RFC8812"/>
and the media type "application/voucher-cose+cbor".</t>
      <t>This document provides cryptographic signing of the JSON Voucher Data in form of JSON Web Signature (JWS) <xref target="RFC7515"/>
and the media type "application/voucher-jws+json".
The encoding specified in this document is used by <xref target="I-D.ietf-anima-brski-prm"/>
and may be more handy for use cases already using Javascript Object Signing and Encryption (JOSE).</t>
      <t>With the availability of different encoded vouchers, it is up to an industry specific application statement to indicate/decide which voucher signature format is to be used.
There is no provision across the different voucher signature formats that a receiver could safely recognize which format it uses unless additional context is provided.
For example, <xref target="BRSKI"/> provides this context via the media type for the voucher artifact.
This document utilizes the optional "typ" (Type) Header Parameter of JWS <xref target="RFC7515"/> to provide information about the signed object.</t>
      <t>This document should be considered an update to <xref target="I-D.draft-ietf-anima-rfc8366bis"/> in the category of "See Also" as per <xref target="I-D.kuehlewind-update-tag"/>.
[TODO: Fix "Updates:" header with I-D.draft-ietf-anima-rfc8366bis number.]
It does not extend the YANG definition of <xref target="I-D.draft-ietf-anima-rfc8366bis"/>.</t>
    </section>
    <section anchor="terminology">
      <name>Terminology</name>
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
      <t>This document uses the following terms:</t>
      <dl>
        <dt>JSON Voucher Data:</dt>
        <dd>
          <t>An unsigned JSON representation of the Voucher Data.</t>
        </dd>
        <dt>JWS Voucher:</dt>
        <dd>
          <t>A JWS structure signing the JSON Voucher Data.</t>
        </dd>
        <dt>Voucher:</dt>
        <dd>
          <t>A short form for Voucher Artifact and refers to the signed statement from the MASA service that indicates to a pledge the cryptographic identity of the domain it should trust, per <xref target="I-D.draft-ietf-anima-rfc8366bis"/>.</t>
        </dd>
        <dt>Voucher Data:</dt>
        <dd>
          <t>The raw (serialized) representation of the ietf-voucher YANG module without any enclosing signature, per <xref target="I-D.draft-ietf-anima-rfc8366bis"/>.</t>
        </dd>
      </dl>
      <t>This document uses the following encoding notations:</t>
      <dl>
        <dt>BASE64URL(OCTETS):</dt>
        <dd>
          <t>Denotes the base64url encoding of OCTETS, per <xref section="2" sectionFormat="of" target="RFC7515"/>.</t>
        </dd>
        <dt>UTF8(STRING):</dt>
        <dd>
          <t>Denotes the octets of the UTF-8 <xref target="RFC3629"/> representation of STRING, per <xref section="1" sectionFormat="of" target="RFC7515"/>.</t>
        </dd>
      </dl>
    </section>
    <section anchor="voucher-artifact-with-json-web-signature">
      <name>Voucher Artifact with JSON Web Signature</name>
      <t><xref target="RFC7515"/> defines the following serializations for JWS:</t>
      <ol spacing="normal" type="1"><li>"JWS Compact Serialization" in <xref section="7.1" sectionFormat="of" target="RFC7515"/></li>
        <li>
          <t>"JWS JSON Serialization" in <xref section="7.2" sectionFormat="of" target="RFC7515"/>
          </t>
          <ul spacing="normal">
            <li>"General JWS JSON Serialization Syntax" in <xref section="7.2.1" sectionFormat="of" target="RFC7515"/></li>
            <li>"Flattened JWS JSON Serialization Syntax" in <xref section="7.2.2" sectionFormat="of" target="RFC7515"/></li>
          </ul>
        </li>
      </ol>
      <t>A "JWS JSON Serialization Overview" is given in <xref section="3.2" sectionFormat="of" target="RFC7515"/> and more details on the JWS serializations in <xref section="7" sectionFormat="of" target="RFC7515"/>.
This document makes use of the "General JWS JSON Serialization Syntax" of <xref target="RFC7515"/> to support multiple signatures,
as already supported by <xref target="RFC8366"/> for CMS-signed vouchers.</t>
      <section anchor="voucher-representation-in-general-jws-json-serialization-syntax">
        <name>Voucher Representation in General JWS JSON Serialization Syntax</name>
        <t>JWS Voucher artifacts MUST use the "General JWS JSON Serialization Syntax" defined in <xref section="7.2.1" sectionFormat="of" target="RFC7515"/>.
The following figure summarizes the serialization of JWS Voucher artifacts:</t>
        <figure anchor="VoucherGeneralJWSFigure">
          <name>Voucher Representation in General JWS JSON Serialization Syntax (JWS Voucher)</name>
          <artwork align="left"><![CDATA[
    {
      "payload": BASE64URL(UTF8(JSON Voucher Data)),
      "signatures": [
        {
          "protected": BASE64URL(UTF8(JWS Protected Header)),
          "signature": BASE64URL(JWS Signature)
        }
      ]
    }
]]></artwork>
        </figure>
        <t>The JSON Voucher Data MUST be UTF-8 encoded to become the octet-based JWS Payload defined in <xref target="RFC7515"/>.
The JWS Payload is further base64url-encoded to become the string value of the "payload" member as described in <xref section="3.2" sectionFormat="of" target="RFC7515"/>.
The octets of the UTF-8 representation of the JWS Protected Header are base64url-encoded to become the string value of the "protected" member.
The generated JWS Signature is base64url-encoded to become the string value of the "signature" member.</t>
      </section>
      <section anchor="json-voucher-data">
        <name>JSON Voucher Data</name>
        <t>The JSON Voucher Data is an unsigned JSON document <xref target="RFC8259"/> that conforms with the data model described by the ietf-voucher YANG module <xref target="RFC7950"/> defined in <xref section="5.3" sectionFormat="of" target="I-D.draft-ietf-anima-rfc8366bis"/> and is encoded using the rules defined in <xref target="RFC7951"/>.
The following figure provides an example of JSON Voucher Data:</t>
        <figure anchor="VoucherGeneralJWSVoucherPayloadFigure">
          <name>JSON Voucher Data Example</name>
          <artwork align="left"><![CDATA[
    {
      "ietf-voucher:voucher": {
        "assertion": "logged",
        "serial-number": "0123456789",
        "nonce": "5742698422680472",
        "created-on": "2022-07-08T03:01:24.618Z",
        "pinned-domain-cert": "base64encodedvalue=="
      }
    }
]]></artwork>
        </figure>
      </section>
      <section anchor="jws-protected-header">
        <name>JWS Protected Header</name>
        <t>The JWS Protected Header defined in <xref target="RFC7515"/> uses the standard header parameters "alg", "typ", and "x5c".
The "alg" parameter MUST contain the algorithm type used to create the signature, e.g., "ES256" as defined in <xref section="4.1.1" sectionFormat="of" target="RFC7515"/>.
If present, the "typ" parameter SHOULD contain the value "[TODO: voucher-jws+json]" as defined in <xref section="4.1.9" sectionFormat="of" target="RFC7515"/>.
If X.509 (PKIX) certificates <xref target="RFC5280"/> are used, the "x5c" parameter SHOULD contain the base64-encoded (not base64url-encoded) X.509 v3 (DER) certificate and chain as defined in <xref section="4.1.6" sectionFormat="of" target="RFC7515"/>.</t>
        <t>Implementation Note:
base64-encoded values opposed to base64url-encoded values may contain slashes ('/').
JSON <xref target="RFC8259"/> optionally allows to escape these with backslashes ('').
Hence, depending on the JSON parser/serializer implementation used, they may or may not be included.
JWS Voucher parsers must be prepared accordingly to extract certificates correctly.</t>
        <t>Vouchers will often need all certificates in the chain,
including what would be considered the trust anchor certificate,
because intermediate devices (such as the Registrar) may need to audit the artifact,
or end systems may need to pin a trust anchor for future operations.
Note, a trust anchor SHOULD be provided differently to be trusted.
This is consistent with <xref section="5.5.2" sectionFormat="of" target="BRSKI"/>.</t>
        <t>The following figure gives an example of a JWS Protected Header:</t>
        <figure anchor="VoucherGeneralJWSProtectedHeaderFigure">
          <name>JWS Protected Header Example</name>
          <artwork align="left"><![CDATA[
    {
      "alg": "ES256",
      "typ": "[TODO: voucher-jws+json]",
      "x5c": [
        "base64encodedvalue1==",
        "base64encodedvalue2=="
      ]
    }  
]]></artwork>
        </figure>
      </section>
      <section anchor="jws-signature">
        <name>JWS Signature</name>
        <t>The JWS Signature is generated over the JWS Protected Header and the JWS Payload (= UTF-8 encoded JSON Voucher Data) as described in <xref section="5.1" sectionFormat="of" target="RFC7515"/>.</t>
      </section>
    </section>
    <section anchor="privacy-considerations">
      <name>Privacy Considerations</name>
      <t>The Voucher Request reveals the IDevID of the component (Pledge) that is in the process of bootstrapping.</t>
      <t>This request occurs via HTTP-over-TLS, however, for the Pledge-to-Registrar TLS connection, the Pledge is provisionally accepting the Registrar server certificate.
Hence it is subject to disclosure by a Dolev-Yao attacker (a "malicious messenger") <xref target="ON-PATH"/>, as explained in <xref section="10.2" sectionFormat="of" target="BRSKI"/>.</t>
      <t>The use of a JWS header brings no new privacy considerations.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>The issues of how <xref target="I-D.draft-ietf-anima-rfc8366bis"/> vouchers are used in a <xref target="BRSKI"/> system is addressed in <xref section="11" sectionFormat="of" target="BRSKI"/>.
This document does not change any of those issues, it just changes the signature technology used for voucher request and response artifacts.</t>
      <t><xref section="9" sectionFormat="of" target="SZTP"/> deals with voucher use in Secure Zero Touch Provisioning, for which this document also makes no changes to security.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <section anchor="media-type-registry">
        <name>Media-Type Registry</name>
        <t>This section registers the "application/voucher-jws+json" in the "Media Types" registry.</t>
        <section anchor="applicationvoucher-jwsjson">
          <name>application/voucher-jws+json</name>
          <artwork><![CDATA[
Type name:  application
Subtype name:  voucher-jws+json
Required parameters:  none
Optional parameters:  none
Encoding considerations:  JWS+JSON vouchers are JOSE objects
                          signed with one or multiple signers.
Security considerations:  See section [Security Considerations]
Interoperability considerations:  The format is designed to be
  broadly interoperable.
Published specification:  [THIS RFC].
Applications that use this media type:  ANIMA, 6tisch, and other
  zero-touch bootstrapping/provisioning solutions
Additional information:
  Magic number(s):  None
  File extension(s):  .vjj
  Macintosh file type code(s):  none
Person & email address to contact for further information:  IETF
  ANIMA WG
Intended usage:  LIMITED
Restrictions on usage:  NONE
Author:  ANIMA WG
Change controller:  IETF
Provisional registration? (standards tree only):  NO
]]></artwork>
        </section>
      </section>
    </section>
    <section anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>We would like to thank the various reviewers for their input,
in particular Steffen Fries, Ingo Wenda, Esko Dijk and Toerless Eckert.
Thanks for the supporting PoC implementations to Hong Rui Li and He Peng Jia.</t>
    </section>
    <section anchor="examples">
      <name>Examples</name>
      <t>These examples are folded according to <xref target="RFC8792"/> Single Backslash rule.</t>
      <section anchor="example-pledge-voucher-request-pvr-from-pledge-to-registrar">
        <name>Example Pledge Voucher Request - PVR (from Pledge to Registrar)</name>
        <t>The following is an example request sent from a Pledge to the Registrar, in "General JWS JSON Serialization".</t>
        <figure anchor="ExamplePledgeVoucherRequestfigure">
          <name>Example Pledge Voucher Request - PVR</name>
          <artwork align="left"><![CDATA[
=============== NOTE: '\' line wrapping per RFC 8792 ================

{
  "payload": "eyJpZXRmLXZvdWNoZXItcmVxdWVzdDp2b3VjaGVyIjp7InNlcmlhbC\
1udW1iZXIiOiIwMTIzNDU2Nzg5Iiwibm9uY2UiOiI2R3RuK1pRS04ySHFERlZrQkV4Wk\
xRPT0iLCJjcmVhdGVkLW9uIjoiMjAyMi0wNy0wOFQwODo0MDo0Mi44MjBaIiwicHJveG\
ltaXR5LXJlZ2lzdHJhci1jZXJ0IjoiTUlJQjRqQ0NBWWlnQXdJQkFnSUdBWFk3MmJiWk\
1Bb0dDQ3FHU000OUJBTUNNRFV4RXpBUkJnTlZCQW9NQ2sxNVFuVnphVzVsYzNNeERUQU\
xCZ05WQkFjTUJGTnBkR1V4RHpBTkJnTlZCQU1NQmxSbGMzUkRRVEFlRncweU1ERXlNRG\
N3TmpFNE1USmFGdzB6TURFeU1EY3dOakU0TVRKYU1ENHhFekFSQmdOVkJBb01DazE1UW\
5WemFXNWxjM014RFRBTEJnTlZCQWNNQkZOcGRHVXhHREFXQmdOVkJBTU1EMFJ2YldGcG\
JsSmxaMmx6ZEhKaGNqQlpNQk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VIQTBJQUJCaz\
E2Sy9pNzlvUmtLNVliZVBnOFVTUjgvdXMxZFBVaVpITXRva1NkcUtXNWZuV3NCZCtxUk\
w3V1JmZmVXa3lnZWJvSmZJbGx1cmNpMjV3bmhpT1ZDR2plekI1TUIwR0ExVWRKUVFXTU\
JRR0NDc0dBUVVGQndNQkJnZ3JCZ0VGQlFjREhEQU9CZ05WSFE4QkFmOEVCQU1DQjRBd1\
NBWURWUjBSQkVFd1A0SWRjbVZuYVhOMGNtRnlMWFJsYzNRdWMybGxiV1Z1Y3kxaWRDNX\
VaWFNDSG5KbFoybHpkSEpoY2kxMFpYTjBOaTV6YVdWdFpXNXpMV0owTG01bGREQUtCZ2\
dxaGtqT1BRUURBZ05JQURCRkFpQnhsZEJoWnEwRXY1SkwyUHJXQ3R5UzZoRFlXMXlDTy\
9SYXVicEM3TWFJRGdJaEFMU0piZ0xuZ2hiYkFnMGRjV0ZVVm8vZ0dOMC9qd3pKWjBTbD\
JoNHhJWGsxIn19",
  "signatures": [{
    "protected": "eyJ4NWMiOlsiTUlJQitUQ0NBYUNnQXdJQkFnSUdBWG5WanNVNU\
1Bb0dDQ3FHU000OUJBTUNNRDB4Q3pBSkJnTlZCQVlUQWtGUk1SVXdFd1lEVlFRS0RBeE\
thVzVuU21sdVowTnZjbkF4RnpBVkJnTlZCQU1NRGtwcGJtZEthVzVuVkdWemRFTkJNQ0\
FYRFRJeE1EWXdOREExTkRZeE5Gb1lEems1T1RreE1qTXhNak0xT1RVNVdqQlNNUXN3Q1\
FZRFZRUUdFd0pCVVRFVk1CTUdBMVVFQ2d3TVNtbHVaMHBwYm1kRGIzSndNUk13RVFZRF\
ZRUUZFd293TVRJek5EVTJOemc1TVJjd0ZRWURWUVFEREE1S2FXNW5TbWx1WjBSbGRtbG\
paVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFCQzc5bGlhUmNCalpjRU\
VYdzdyVWVhdnRHSkF1SDRwazRJNDJ2YUJNc1UxMWlMRENDTGtWaHRVVjIxbXZhS0N2TX\
gyWStTTWdROGZmd0wyM3ozVElWQldqZFRCek1Dc0dDQ3NHQVFVRkJ3RWdCQjhXSFcxaG\
MyRXRkR1Z6ZEM1emFXVnRaVzV6TFdKMExtNWxkRG81TkRRek1COEdBMVVkSXdRWU1CYU\
FGRlFMak56UFwvU1wva291alF3amc1RTVmdndjWWJNQk1HQTFVZEpRUU1NQW9HQ0NzR0\
FRVUZCd01DTUE0R0ExVWREd0VCXC93UUVBd0lIZ0RBS0JnZ3Foa2pPUFFRREFnTkhBRE\
JFQWlCdTN3UkJMc0pNUDVzTTA3MEgrVUZyeU5VNmdLekxPUmNGeVJST2xxcUhpZ0lnWE\
NtSkxUekVsdkQycG9LNmR4NmwxXC91eW1UbmJRRERmSmxhdHVYMlJvT0U9Il0sInR5cC\
I6InZvdWNoZXItandzK2pzb24iLCJhbGciOiJFUzI1NiJ9",
    "signature": "abVg4TDGzSTjVHkQlNeIW3ABu5ZXdMl1cEqwcIAlHFW4BrlGbO\
-DRTKfyCOGxSW49-ktJcrVlYgKqC4xmZoy0Q"
  }]
}
]]></artwork>
        </figure>
      </section>
      <section anchor="example-parboiled-registrar-voucher-request-rvr-from-registrar-to-masa">
        <name>Example Parboiled Registrar Voucher Request - RVR (from Registrar to MASA)</name>
        <t>The term parboiled refers to food which is partially cooked.
In <xref target="BRSKI"/>, the term refers to a Pledge voucher-request (PVR) which has been received by the Registrar, and then has been processed by the Registrar ("cooked"), and is now being forwarded to the MASA.</t>
        <t>The following is an example Registrar voucher-request (RVR) sent from the Registrar to the MASA, in "General JWS JSON Serialization".
Note that the previous PVR can be seen in the payload as "prior-signed-voucher-request".</t>
        <figure anchor="ExampleParboiledRegistrarVoucherRequestfigure">
          <name>Example Parboiled Registrar Voucher Request - RVR</name>
          <artwork align="left"><![CDATA[
=============== NOTE: '\' line wrapping per RFC 8792 ================

{
  "payload": "eyJpZXRmLXZvdWNoZXItcmVxdWVzdDp2b3VjaGVyIjp7InNlcmlhbC\
1udW1iZXIiOiIwMTIzNDU2Nzg5IiwiaWRldmlkLWlzc3VlciI6IkJCZ3dGb0FVVkF1TT\
NNLzlMK1NpNk5EQ09Ea1RsKy9CeGhzPSIsIm5vbmNlIjoiNkd0bitaUUtOMkhxREZWa0\
JFeFpMUT09IiwicHJpb3Itc2lnbmVkLXZvdWNoZXItcmVxdWVzdCI6ImV5SndZWGxzYj\
JGa0lqb2laWGxLY0ZwWVVtMU1XRnAyWkZkT2IxcFlTWFJqYlZaNFpGZFdlbVJFY0RKaU\
0xWnFZVWRXZVVscWNEZEpiazVzWTIxc2FHSkRNWFZrVnpGcFdsaEphVTlwU1hkTlZFbD\
ZUa1JWTWs1Nlp6VkphWGRwWW0wNWRWa3lWV2xQYVVreVVqTlNkVXN4Y0ZKVE1EUjVVMG\
hHUlZKc1duSlJhMVkwVjJ0NFVsQlVNR2xNUTBwcVkyMVdhR1JIVm10TVZ6bDFTV3B2YV\
UxcVFYbE5hVEIzVG5rd2QwOUdVWGRQUkc4d1RVUnZNRTFwTkRSTmFrSmhTV2wzYVdOSV\
NuWmxSMngwWVZoU05VeFlTbXhhTW14NlpFaEthR05wTVdwYVdFb3dTV3B2YVZSVmJFcF\
JhbEp4VVRCT1FsZFhiRzVSV0dSS1VXdEdibE5WWkVKWFJtc3pUVzFLYVZkck1VSmlNR1\
JFVVROR1NGVXdNREJQVlVwQ1ZGVk9UbEpHVmpSU1dIQkNWV3RLYmxSc1drTlJWemxPVV\
RKemVFNVdSblZXYm5Cb1ZucFdjMWw2VGs1bFJWSlZVVlY0UTFvd05WZFJhMFpxVkZWS1\
IxUnVRbXRTTVZZMFVraHdRbFJyU201VWJGcERVVlV4VGxGdGVGTmlSMDE2Vld0U1VsWk\
ZSbXhTYm1OM1pWVXhSVkpZYkU1U1IwNHpWRzF3Ums1Rk1WVlRiVVpIWkhwQ05sUlZVa1\
psVlRGRldUTmtUMkZyVlRCVVZsSkxXVlV4UlU1SWFFWmxhMFpUVVcxa1QxWnJTa0ppTU\
RGRVlYcEZNVlZYTlZkbGJVWllUbGQ0YWswd01UUlNSbEpDVkVWS2JsUnNXa05SVjA1T1\
VXdGFUMk5IVWtoV1dHaElVa1ZHV0ZGdFpFOVdhMHBDVkZVeFJVMUdTakpaYkdSSFkwZE\
tjMU50ZUdGTmJYZzJXa1ZvUzJGSFRuRlJiSEJPVVdzeFNGRnViSGhTTVU1T1RrUnNRbG\
93VmtoUk1FNTRVakZPVGs1RWJFSmtNRlpKVVZSQ1NsRlZTa05oZWtVeVUzazVjRTU2Yk\
haVmJYUk1UbFpzYVZwV1FtNVBSbFpVVldwbmRtUllUWGhhUmtKV1lWWndTVlJZVW5aaE\
1VNXJZMVYwV0U1WFduVldNMDVEV2tOMGVGVnJkek5XTVVwdFdtMVdXR0V6Ykc1YVYwcD\
JVMjFhU21KSGVERmpiVTV3VFdwV00ySnRhSEJVTVZwRVVqSndiR1ZyU1RGVVZVbDNVak\
JGZUZaWFVrdFZWa1pZVkZWS1VsSXdUa1JqTUdSQ1ZWWldSMUZ1WkU1UmEwcHVXak5LUT\
Fvd1ZrZFJiRVpxVWtWb1JWRlZPVU5hTURWWFUwWkZORkZyUm0xUFJWWkRVVlV4UkZGcV\
VrSmtNVTVDVjFWU1YxVnFRbE5SYTFaR1pERkJNRk5YVW1waVZscDFXVlpvVDAxSFRuUl\
NibXhOVjBaS2MxbDZUbEprVjAxNVlrZDRhVll4V2pGWk0ydDRZVmRTUkU1WVZtRlhSaz\
VFVTBjMVMySkdiM2xpU0hCclUwVndiMWt5YTNoTlJuQlpWR3BDVDJGVVZqWlpWbVJYWk\
Vad1dFNVljRTFXTUc5M1ZFY3dNV0pIVWtWUlZYUkRXakprZUdGSGRIRlVNVUpTVlZWU1\
Fsb3dOVXBSVlZKRFVtdEdjRkZ1YUhOYVJVcHZWMjVGZDFKWVdURlRhM2Q1VlVoS1dGRX\
pValZWZWxwdlVrWnNXRTFZYkVSVWVUbFRXVmhXYVdORlRUTlVWMFpLVWtka1NtRkZSaz\
FWTUhCcFdqQjRkVm95YUdsWmEwWnVUVWRTYWxZd1dsWldiVGgyV2pCa1QwMURPWEZrTT\
NCTFYycENWR0pFU205T1NHaEtWMGR6ZUVsdU1Ua2lMQ0p6YVdkdVlYUjFjbVZ6SWpwYm\
V5SndjbTkwWldOMFpXUWlPaUpsZVVvMFRsZE5hVTlzYzJsVVZXeEtVV2wwVlZFd1RrSl\
pWVTV1VVZoa1NsRnJSbTVUVldSQ1YwYzFWMkZ1VGxaT1ZURkNZakJrUkZFelJraFZNRE\
F3VDFWS1FsUlZUazVTUkVJMFVUTndRbE5yU201VWJGcERVVlpzVlZGWGRFZFZhekZUVm\
xoa1JtUXhiRVZXYkVaU1V6QlNRbVZGZEdoV2VsWjFWVEl4YzJSV2IzZFVibHBxWW10R0\
5GSnVjRUpXYTBwdVZHeGFRMUZWTVU1U1IzUjNZMGRLZEZwRmRHaFdlbFoxVm10a1YyVn\
RVa1pVYTBwT1VUQkdXVkpHVWtwbFJURkZWMWhrVDFKRlJYaFVhMUphWlVVMVIySXhiRV\
ZsYlhNeFZERlNjbVZGTVhGVVdHaE9ZV3N3ZUZReFVsWk9WbVJ4VVd4T1RsVllUak5STV\
VaYVVrWmFVbFZWWkVaa01IQkRWbFpTUmxack1VTlVWV1JDVFZaV1JsRXlaRE5VVms1MF\
lraFdZVTFJUW5kWmJURnJVa2RKZWxOdVpFNVZhekV6VWxaR1dsSkdXbEpWVlZwR1pEST\
VNMVJXVWtwbGF6VkZWbFJLVDJWdFl6RlVWa3BxWkRCYVVsZFZVbGRWVmtaRlVrVkZNVk\
15UmxoT1Z6VlVZbGQ0TVZkcVFsTmlSMUowWWtkd1lWWkZTbUZVVlVwT1VqQktOV05WWk\
ZSVVZGRTFVVmRrUmxJd1RrUmpWV1JVVkZSUk5WRllaRVpUUlVWM1UxVkdRMUY2WXpWaV\
IyeG9WVzFPUTJGc2NHcFNWVlpaWkhwa2VWWlhWbWhrYmxKSVUydEdNVk5FVW5kaGVsSk\
tUa1JLTWxsVlNrNWpNVlY0VFZkc1RWSkZUa1JVUjNSWFlVaFNWbFpxU1hoaVdGcG9Vek\
JPTWxSWVozbFhVM1JVVkZka1VrOUhXbTFrTUhkNVRUTnZlbFpGYkZkUmJHUnhXa1pTUT\
JWck1VUmpNR1JFVVROT1NGRldSbFpTYTBvelVsZGtRMUZxYUZoVFJtTjRZVWROZVZKWV\
VtdFNNVm8yV2tWTk1XVnRSbGhXYmxKaFZucFdObFJHWkV0TlJYaDBUbGQ0YTFKSE9ERl\
VhMUpTWldzeFEwOUZaRUpOVmxaclUxaGtVbGRWTVVOWlZVWkhVbXhHVFdGck5UWlZSbm\
QyVlRGM2RtRXlPVEZoYkVZellXMWpNVkpVVm0xa2JtUnFWMWRLVGxGck1VaFJWRVpXV2\
tWd1VsVlZNVTVSVnpsSVVUQk9lbEl3UmxKV1ZWcERaREF4UkZSVlJUQlNNRVY0VmxkU1\
JXUXdWa05ZUXprelZWVldRbVF3YkVsYU1GSkNVekJLYmxvelJtOWhNbkJRVlVaR1VsSk\
ZSbTVVYTJoQ1VrVktSbEZYYkVOa1ZFNHpWV3RLVFdNd2NFNVZSRlo2VkZSQk0wMUZaM0\
pXVlZwNVpWVTFWazV0WkV4bGEzaFFWVzFPUjJWV1NsTlVNbmg0WTFWb2NGb3diRzVYUl\
U1MFUydDRWV1ZyVm5Oa2ExRjVZMGM1VEU1dFVqUk9iWGQ0V0VNNU1XVlhNVlZpYlVwU1\
VrVlNiVk50ZUdoa1NGWlpUV3hLZGxRd1ZUbEpiREJ6U1c1U05XTkRTVFpKYmxwMlpGZE\
9iMXBZU1hSaGJtUjZTekp3ZW1JeU5HbE1RMHBvWWtkamFVOXBTa1pWZWtreFRtbEtPU0\
lzSW5OcFoyNWhkSFZ5WlNJNkltRmlWbWMwVkVSSGVsTlVhbFpJYTFGc1RtVkpWek5CUW\
5VMVdsaGtUV3d4WTBWeGQyTkpRV3hJUmxjMFFuSnNSMkpQTFVSU1ZFdG1lVU5QUjNoVF\
Z6UTVMV3QwU21OeVZteFpaMHR4UXpSNGJWcHZlVEJSSW4xZGZRPT0iLCJjcmVhdGVkLW\
9uIjoiMjAyMi0wNy0wOFQwODo0MDo0Mi44NDhaIn19",
  "signatures": [{
    "protected": "eyJ4NWMiOlsiTUlJQm96Q0NBVXFnQXdJQkFnSUdBVzBlTHVJRk\
1Bb0dDQ3FHU000OUJBTUNNRFV4RXpBUkJnTlZCQW9NQ2sxNVFuVnphVzVsYzNNeERUQU\
xCZ05WQkFjTUJGTnBkR1V4RHpBTkJnTlZCQU1NQmxSbGMzUkRRVEFlRncweE9UQTVNVE\
V3TWpNM016SmFGdzB5T1RBNU1URXdNak0zTXpKYU1GUXhFekFSQmdOVkJBb01DazE1UW\
5WemFXNWxjM014RFRBTEJnTlZCQWNNQkZOcGRHVXhMakFzQmdOVkJBTU1KVkpsWjJsem\
RISmhjaUJXYjNWamFHVnlJRkpsY1hWbGMzUWdVMmxuYm1sdVp5QkxaWGt3V1RBVEJnY3\
Foa2pPUFFJQkJnZ3Foa2pPUFFNQkJ3TkNBQVQ2eFZ2QXZxVHoxWlVpdU5XaFhwUXNrYV\
B5N0FISFFMd1hpSjBpRUx0NnVOUGFuQU4wUW5XTVlPXC8wQ0RFaklrQlFvYnc4WUtxan\
R4SkhWU0dUajlLT295Y3dKVEFUQmdOVkhTVUVEREFLQmdnckJnRUZCUWNESERBT0JnTl\
ZIUThCQWY4RUJBTUNCNEF3Q2dZSUtvWkl6ajBFQXdJRFJ3QXdSQUlnWXIyTGZxb2FDS0\
RGNFJBY01tSmkrTkNacWRTaXVWdWdJU0E3T2hLUnEzWUNJRHhuUE1NbnBYQU1UclBKdV\
BXeWNlRVIxMVB4SE9uKzBDcFNIaTJxZ3BXWCIsIk1JSUJwRENDQVVtZ0F3SUJBZ0lHQV\
cwZUx1SCtNQW9HQ0NxR1NNNDlCQU1DTURVeEV6QVJCZ05WQkFvTUNrMTVRblZ6YVc1bG\
MzTXhEVEFMQmdOVkJBY01CRk5wZEdVeER6QU5CZ05WQkFNTUJsUmxjM1JEUVRBZUZ3MH\
hPVEE1TVRFd01qTTNNekphRncweU9UQTVNVEV3TWpNM016SmFNRFV4RXpBUkJnTlZCQW\
9NQ2sxNVFuVnphVzVsYzNNeERUQUxCZ05WQkFjTUJGTnBkR1V4RHpBTkJnTlZCQU1NQm\
xSbGMzUkRRVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFCT2t2a1RIdT\
hRbFQzRkhKMVVhSTcrV3NIT2IwVVMzU0FMdEc1d3VLUURqaWV4MDZcL1NjWTVQSmlidm\
dIVEIrRlwvUVRqZ2VsSEd5MVlLcHdjTk1jc1N5YWpSVEJETUJJR0ExVWRFd0VCXC93UU\
lNQVlCQWY4Q0FRRXdEZ1lEVlIwUEFRSFwvQkFRREFnSUVNQjBHQTFVZERnUVdCQlRvWk\
lNelFkc0RcL2pcLytnWFwvN2NCSnVjSFwvWG1qQUtCZ2dxaGtqT1BRUURBZ05KQURCR0\
FpRUF0eFEzK0lMR0JQSXRTaDRiOVdYaFhOdWhxU1A2SCtiXC9MQ1wvZlZZRGpRNm9DSV\
FERzJ1UkNIbFZxM3loQjU4VFhNVWJ6SDgrT2xoV1V2T2xSRDNWRXFEZGNRdz09Il0sIn\
R5cCI6InZvdWNoZXItandzK2pzb24iLCJhbGciOiJFUzI1NiJ9",
    "signature": "0fzuqVdyhemWsu_HQeF-CmQwJeLp9IStNf-bWZwz6SojrEOR4a\
Dq6VStyG8eWXjGHNZiRyyLJo7RP1rKatuS2w"
  }]
}
]]></artwork>
        </figure>
      </section>
      <section anchor="example-voucher-response-from-masa-to-pledge-via-registrar">
        <name>Example Voucher Response (from MASA to Pledge, via Registrar)</name>
        <t>The following is an example voucher response from MASA to Pledge via Registrar, in "General JWS JSON Serialization".</t>
        <figure anchor="ExampleVoucherResponsefigure">
          <name>Example Voucher Response</name>
          <artwork align="left"><![CDATA[
=============== NOTE: '\' line wrapping per RFC 8792 ================

{
  "payload": "eyJpZXRmLXZvdWNoZXI6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJsb2\
dnZWQiLCJzZXJpYWwtbnVtYmVyIjoiMDEyMzQ1Njc4OSIsIm5vbmNlIjoiZGRoSGQ4Ml\
FpUGtzMDBTck1USTlEUT09IiwiY3JlYXRlZC1vbiI6IjIwMjItMDctMDdUMTc6NDc6MD\
EuODkwWiIsInBpbm5lZC1kb21haW4tY2VydCI6Ik1JSUJwRENDQVVtZ0F3SUJBZ0lHQV\
cwZUx1SCtNQW9HQ0NxR1NNNDlCQU1DTURVeEV6QVJCZ05WQkFvTUNrMTVRblZ6YVc1bG\
MzTXhEVEFMQmdOVkJBY01CRk5wZEdVeER6QU5CZ05WQkFNTUJsUmxjM1JEUVRBZUZ3MH\
hPVEE1TVRFd01qTTNNekphRncweU9UQTVNVEV3TWpNM016SmFNRFV4RXpBUkJnTlZCQW\
9NQ2sxNVFuVnphVzVsYzNNeERUQUxCZ05WQkFjTUJGTnBkR1V4RHpBTkJnTlZCQU1NQm\
xSbGMzUkRRVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFCT2t2a1RIdT\
hRbFQzRkhKMVVhSTcrV3NIT2IwVVMzU0FMdEc1d3VLUURqaWV4MDYvU2NZNVBKaWJ2Z0\
hUQitGL1FUamdlbEhHeTFZS3B3Y05NY3NTeWFqUlRCRE1CSUdBMVVkRXdFQi93UUlNQV\
lCQWY4Q0FRRXdEZ1lEVlIwUEFRSC9CQVFEQWdJRU1CMEdBMVVkRGdRV0JCVG9aSU16UW\
RzRC9qLytnWC83Y0JKdWNIL1htakFLQmdncWhrak9QUVFEQWdOSkFEQkdBaUVBdHhRMy\
tJTEdCUEl0U2g0YjlXWGhYTnVocVNQNkgrYi9MQy9mVllEalE2b0NJUURHMnVSQ0hsVn\
EzeWhCNThUWE1VYnpIOCtPbGhXVXZPbFJEM1ZFcURkY1F3PT0ifX0",
  "signatures": [{
    "protected": "eyJ4NWMiOlsiTUlJQmt6Q0NBVGlnQXdJQkFnSUdBV0ZCakNrWU\
1Bb0dDQ3FHU000OUJBTUNNRDB4Q3pBSkJnTlZCQVlUQWtGUk1SVXdFd1lEVlFRS0RBeE\
thVzVuU21sdVowTnZjbkF4RnpBVkJnTlZCQU1NRGtwcGJtZEthVzVuVkdWemRFTkJNQj\
RYRFRFNE1ERXlPVEV3TlRJME1Gb1hEVEk0TURFeU9URXdOVEkwTUZvd1R6RUxNQWtHQT\
FVRUJoTUNRVkV4RlRBVEJnTlZCQW9NREVwcGJtZEthVzVuUTI5eWNERXBNQ2NHQTFVRU\
F3d2dTbWx1WjBwcGJtZERiM0p3SUZadmRXTm9aWElnVTJsbmJtbHVaeUJMWlhrd1dUQV\
RCZ2NxaGtqT1BRSUJCZ2dxaGtqT1BRTUJCd05DQUFTQzZiZUxBbWVxMVZ3NmlRclJzOF\
IwWlcrNGIxR1d5ZG1XczJHQU1GV3diaXRmMm5JWEgzT3FIS1Z1OHMyUnZpQkdOaXZPS0\
dCSEh0QmRpRkVaWnZiN294SXdFREFPQmdOVkhROEJBZjhFQkFNQ0I0QXdDZ1lJS29aSX\
pqMEVBd0lEU1FBd1JnSWhBSTRQWWJ4dHNzSFAyVkh4XC90elVvUVwvU3N5ZEwzMERRSU\
5FdGNOOW1DVFhQQWlFQXZJYjNvK0ZPM0JUbmNMRnNhSlpSQWtkN3pPdXNuXC9cL1pLT2\
FFS2JzVkRpVT0iXSwidHlwIjoidm91Y2hlci1qd3MranNvbiIsImFsZyI6IkVTMjU2In\
0",
    "signature": "y1HLYBFlwouf42XWSKUWjeYQHnG2Q6A4bjA7hvTkB3z1dPwTUl\
jPHtuN2Qex6gDxTfaSiKeoXGsOD4JWOgQJPg"
  }]
}
]]></artwork>
        </figure>
      </section>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="BRSKI">
          <front>
            <title>Bootstrapping Remote Secure Key Infrastructure (BRSKI)</title>
            <author fullname="M. Pritikin" initials="M." surname="Pritikin"/>
            <author fullname="M. Richardson" initials="M." surname="Richardson"/>
            <author fullname="T. Eckert" initials="T." surname="Eckert"/>
            <author fullname="M. Behringer" initials="M." surname="Behringer"/>
            <author fullname="K. Watsen" initials="K." surname="Watsen"/>
            <date month="May" year="2021"/>
            <abstract>
              <t>This document specifies automated bootstrapping of an Autonomic Control Plane. To do this, a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur when using a routable address and a cloud service, only link-local connectivity, or limited/disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8995"/>
          <seriesInfo name="DOI" value="10.17487/RFC8995"/>
        </reference>
        <reference anchor="I-D.draft-ietf-anima-rfc8366bis">
          <front>
            <title>A Voucher Artifact for Bootstrapping Protocols</title>
            <author fullname="Kent Watsen" initials="K." surname="Watsen">
              <organization>Watsen Networks</organization>
            </author>
            <author fullname="Michael Richardson" initials="M." surname="Richardson">
              <organization>Sandelman Software</organization>
            </author>
            <author fullname="Max Pritikin" initials="M." surname="Pritikin">
              <organization>Cisco Systems</organization>
            </author>
            <author fullname="Toerless Eckert" initials="T. T." surname="Eckert">
              <organization>Futurewei Technologies Inc.</organization>
            </author>
            <author fullname="Qiufang Ma" initials="Q." surname="Ma">
              <organization>Huawei</organization>
            </author>
            <date day="22" month="August" year="2023"/>
            <abstract>
              <t>   This document defines a strategy to securely assign a pledge to an
   owner using an artifact signed, directly or indirectly, by the
   pledge's manufacturer.  This artifact is known as a "voucher".

   This document defines an artifact format as a YANG-defined JSON or
   CBOR document that has been signed using a variety of cryptographic
   systems.

   The voucher artifact is normally generated by the pledge's
   manufacturer (i.e., the Manufacturer Authorized Signing Authority
   (MASA)).

   This document updates RFC8366, merging a number of extensions into
   the YANG.  The RFC8995 voucher request is also merged into this
   document.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-anima-rfc8366bis-10"/>
        </reference>
        <reference anchor="RFC5280">
          <front>
            <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
            <author fullname="D. Cooper" initials="D." surname="Cooper"/>
            <author fullname="S. Santesson" initials="S." surname="Santesson"/>
            <author fullname="S. Farrell" initials="S." surname="Farrell"/>
            <author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <author fullname="W. Polk" initials="W." surname="Polk"/>
            <date month="May" year="2008"/>
            <abstract>
              <t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5280"/>
          <seriesInfo name="DOI" value="10.17487/RFC5280"/>
        </reference>
        <reference anchor="RFC7515">
          <front>
            <title>JSON Web Signature (JWS)</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <author fullname="J. Bradley" initials="J." surname="Bradley"/>
            <author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
            <date month="May" year="2015"/>
            <abstract>
              <t>JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7515"/>
          <seriesInfo name="DOI" value="10.17487/RFC7515"/>
        </reference>
        <reference anchor="RFC8259">
          <front>
            <title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
            <author fullname="T. Bray" initials="T." role="editor" surname="Bray"/>
            <date month="December" year="2017"/>
            <abstract>
              <t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.</t>
              <t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="90"/>
          <seriesInfo name="RFC" value="8259"/>
          <seriesInfo name="DOI" value="10.17487/RFC8259"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="SZTP">
          <front>
            <title>Secure Zero Touch Provisioning (SZTP)</title>
            <author fullname="K. Watsen" initials="K." surname="Watsen"/>
            <author fullname="I. Farrer" initials="I." surname="Farrer"/>
            <author fullname="M. Abrahamsson" initials="M." surname="Abrahamsson"/>
            <date month="April" year="2019"/>
            <abstract>
              <t>This document presents a technique to securely provision a networking device when it is booting in a factory-default state. Variations in the solution enable it to be used on both public and private networks. The provisioning steps are able to update the boot image, commit an initial configuration, and execute arbitrary scripts to address auxiliary needs. The updated device is subsequently able to establish secure connections with other systems. For instance, a device may establish NETCONF (RFC 6241) and/or RESTCONF (RFC 8040) connections with deployment-specific network management systems.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8572"/>
          <seriesInfo name="DOI" value="10.17487/RFC8572"/>
        </reference>
        <reference anchor="RFC3629">
          <front>
            <title>UTF-8, a transformation format of ISO 10646</title>
            <author fullname="F. Yergeau" initials="F." surname="Yergeau"/>
            <date month="November" year="2003"/>
            <abstract>
              <t>ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="63"/>
          <seriesInfo name="RFC" value="3629"/>
          <seriesInfo name="DOI" value="10.17487/RFC3629"/>
        </reference>
        <reference anchor="RFC5652">
          <front>
            <title>Cryptographic Message Syntax (CMS)</title>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <date month="September" year="2009"/>
            <abstract>
              <t>This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="70"/>
          <seriesInfo name="RFC" value="5652"/>
          <seriesInfo name="DOI" value="10.17487/RFC5652"/>
        </reference>
        <reference anchor="RFC7950">
          <front>
            <title>The YANG 1.1 Data Modeling Language</title>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
            <date month="August" year="2016"/>
            <abstract>
              <t>YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7950"/>
          <seriesInfo name="DOI" value="10.17487/RFC7950"/>
        </reference>
        <reference anchor="RFC7951">
          <front>
            <title>JSON Encoding of Data Modeled with YANG</title>
            <author fullname="L. Lhotka" initials="L." surname="Lhotka"/>
            <date month="August" year="2016"/>
            <abstract>
              <t>This document defines encoding rules for representing configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7951"/>
          <seriesInfo name="DOI" value="10.17487/RFC7951"/>
        </reference>
        <reference anchor="RFC8366">
          <front>
            <title>A Voucher Artifact for Bootstrapping Protocols</title>
            <author fullname="K. Watsen" initials="K." surname="Watsen"/>
            <author fullname="M. Richardson" initials="M." surname="Richardson"/>
            <author fullname="M. Pritikin" initials="M." surname="Pritikin"/>
            <author fullname="T. Eckert" initials="T." surname="Eckert"/>
            <date month="May" year="2018"/>
            <abstract>
              <t>This document defines a strategy to securely assign a pledge to an owner using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher".</t>
              <t>This document defines an artifact format as a YANG-defined JSON document that has been signed using a Cryptographic Message Syntax (CMS) structure. Other YANG-derived formats are possible. The voucher artifact is normally generated by the pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)).</t>
              <t>This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8366"/>
          <seriesInfo name="DOI" value="10.17487/RFC8366"/>
        </reference>
        <reference anchor="RFC8792">
          <front>
            <title>Handling Long Lines in Content of Internet-Drafts and RFCs</title>
            <author fullname="K. Watsen" initials="K." surname="Watsen"/>
            <author fullname="E. Auerswald" initials="E." surname="Auerswald"/>
            <author fullname="A. Farrel" initials="A." surname="Farrel"/>
            <author fullname="Q. Wu" initials="Q." surname="Wu"/>
            <date month="June" year="2020"/>
            <abstract>
              <t>This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8792"/>
          <seriesInfo name="DOI" value="10.17487/RFC8792"/>
        </reference>
        <reference anchor="RFC8812">
          <front>
            <title>CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) Registrations for Web Authentication (WebAuthn) Algorithms</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <date month="August" year="2020"/>
            <abstract>
              <t>The W3C Web Authentication (WebAuthn) specification and the FIDO Alliance FIDO2 Client to Authenticator Protocol (CTAP) specification use CBOR Object Signing and Encryption (COSE) algorithm identifiers. This specification registers the following algorithms (which are used by WebAuthn and CTAP implementations) in the IANA "COSE Algorithms" registry: RSASSA-PKCS1-v1_5 using SHA-256, SHA-384, SHA-512, and SHA-1; and Elliptic Curve Digital Signature Algorithm (ECDSA) using the secp256k1 curve and SHA-256. It registers the secp256k1 elliptic curve in the IANA "COSE Elliptic Curves" registry. Also, for use with JSON Object Signing and Encryption (JOSE), it registers the algorithm ECDSA using the secp256k1 curve and SHA-256 in the IANA "JSON Web Signature and Encryption Algorithms" registry and the secp256k1 elliptic curve in the IANA "JSON Web Key Elliptic Curve" registry.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8812"/>
          <seriesInfo name="DOI" value="10.17487/RFC8812"/>
        </reference>
        <reference anchor="RFC8949">
          <front>
            <title>Concise Binary Object Representation (CBOR)</title>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <date month="December" year="2020"/>
            <abstract>
              <t>The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</t>
              <t>This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="94"/>
          <seriesInfo name="RFC" value="8949"/>
          <seriesInfo name="DOI" value="10.17487/RFC8949"/>
        </reference>
        <reference anchor="ON-PATH" target="https://mailarchive.ietf.org/arch/msg/saag/m1r9uo4xYznOcf85Eyk0Rhut598/">
          <front>
            <title>can an on-path attacker drop traffic?</title>
            <author>
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="I-D.ietf-anima-constrained-voucher">
          <front>
            <title>Constrained Bootstrapping Remote Secure Key Infrastructure (BRSKI)</title>
            <author fullname="Michael Richardson" initials="M." surname="Richardson">
              <organization>Sandelman Software Works</organization>
            </author>
            <author fullname="Peter Van der Stok" initials="P." surname="Van der Stok">
              <organization>vanderstok consultancy</organization>
            </author>
            <author fullname="Panos Kampanakis" initials="P." surname="Kampanakis">
              <organization>Cisco Systems</organization>
            </author>
            <author fullname="Esko Dijk" initials="E." surname="Dijk">
              <organization>IoTconsultancy.nl</organization>
            </author>
            <date day="7" month="July" year="2023"/>
            <abstract>
              <t>   This document defines the Constrained Bootstrapping Remote Secure Key
   Infrastructure (Constrained BRSKI) protocol, which provides a
   solution for secure zero-touch bootstrapping of resource-constrained
   (IoT) devices into the network of a domain owner.  This protocol is
   designed for constrained networks, which may have limited data
   throughput or may experience frequent packet loss.  Constrained BRSKI
   is a variant of the BRSKI protocol, which uses an artifact signed by
   the device manufacturer called the "voucher" which enables a new
   device and the owner's network to mutually authenticate.  While the
   BRSKI voucher is typically encoded in JSON, Constrained BRSKI uses a
   compact CBOR-encoded voucher.  The BRSKI voucher is extended with new
   data types that allow for smaller voucher sizes.  The Enrollment over
   Secure Transport (EST) protocol, used in BRSKI, is replaced with EST-
   over-CoAPS; and HTTPS used in BRSKI is replaced with CoAPS.  This
   document Updates RFC 8366 and RFC 8995.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-anima-constrained-voucher-21"/>
        </reference>
        <reference anchor="I-D.ietf-anima-brski-prm">
          <front>
            <title>BRSKI with Pledge in Responder Mode (BRSKI-PRM)</title>
            <author fullname="Steffen Fries" initials="S." surname="Fries">
              <organization>Siemens AG</organization>
            </author>
            <author fullname="Thomas Werner" initials="T." surname="Werner">
              <organization>Siemens AG</organization>
            </author>
            <author fullname="Eliot Lear" initials="E." surname="Lear">
              <organization>Cisco Systems</organization>
            </author>
            <author fullname="Michael Richardson" initials="M." surname="Richardson">
              <organization>Sandelman Software Works</organization>
            </author>
            <date day="10" month="July" year="2023"/>
            <abstract>
              <t>   This document defines enhancements to Bootstrapping a Remote Secure
   Key Infrastructure (BRSKI, RFC8995) to enable bootstrapping in
   domains featuring no or only limited connectivity between a pledge
   and the domain registrar.  It specifically changes the interaction
   model from a pledge-initiated mode, as used in BRSKI, to a pledge-
   responding mode, where the pledge is in server role.  For this, BRSKI
   with Pledge in Responder Mode (BRSKI-PRM) introduces a new component,
   the registrar-agent, which facilitates the communication between
   pledge and registrar during the bootstrapping phase.  To establish
   the trust relation between pledge and registrar, BRSKI-PRM relies on
   object security rather than transport security.  The approach defined
   here is agnostic to the enrollment protocol that connects the domain
   registrar to the domain CA.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-anima-brski-prm-09"/>
        </reference>
        <reference anchor="I-D.kuehlewind-update-tag">
          <front>
            <title>Definition of new tags for relations between RFCs</title>
            <author fullname="Mirja Kühlewind" initials="M." surname="Kühlewind">
              <organization>Ericsson</organization>
            </author>
            <author fullname="Suresh Krishnan" initials="S." surname="Krishnan">
              <organization>Kaloom</organization>
            </author>
            <date day="12" month="July" year="2021"/>
            <abstract>
              <t>   An RFC can include a tag called "Updates" which can be used to link a
   new RFC to an existing RFC.  On publication of such an RFC, the
   existing RFC will include an additional metadata tag called "Updated
   by" which provides a link to the new RFC.  However, this tag pair is
   not well-defined and therefore it is currently used for multiple
   different purposes, which leads to confusion about the actual meaning
   of this tag and inconsistency in its use.

   This document recommends the discontinuation of the use of the
   updates/updated by tag pair, and instead proposes three new tag pairs
   that have well-defined meanings and use cases.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-kuehlewind-update-tag-04"/>
        </reference>
      </references>
    </references>
    <section anchor="contributors" numbered="false" toc="include" removeInRFC="false">
      <name>Contributors</name>
      <contact initials="T." surname="Eckert" fullname="Toerless Eckert">
        <organization>Futurewei Technologies Inc.</organization>
        <address>
          <email>tte+ietf@cs.fau.de</email>
        </address>
      </contact>
      <contact initials="E." surname="Dijk" fullname="Esko Dijk">
        <organization/>
        <address>
          <email>esko.dijk@iotconsultancy.nl</email>
        </address>
      </contact>
      <contact initials="S." surname="Fries" fullname="Steffen Fries">
        <organization>Siemens AG</organization>
        <address>
          <email>steffen.fries@siemens.com</email>
        </address>
      </contact>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIABcU7mQAA+2865KjSJYu+l9PoR1tdibTJiMKdIlKpVnbTEgCJCJAIQcc
icm2bQiIAHFNQKFLW+1n2c9ynux8DkgKRURWZ8+cH7PNdlpVp4Qc9+Xr8q1v
Lffq6+vrVhmUkfetLZtauwieE89t03Tj+F7evsvL4Ml2yqL9lObtYZqWRZnb
WRYkz+3HPC1TJ42Klr1a5d5LNcH1S/1my02dxI4xq5vbT+V14JVP13YSxPb1
elscR11zg1axWcVBUQRpou8zjJ8KuthqFaWduP/TjtIEj8p847VaQZZXH4uy
w3EDrtOyc8/G+KT08sQrW9vnb+1qhbaZ5iGTUMrTTdYKt+dB12MmTcuxy2/t
onRbm8y1S6/41v7avb1ttbLgWxt//tJ27KS9Kby2nef2vv0peGrbUdTee8Xn
NvTg24Xfhvheq92GCr6xH/CxSPMy956Kb9UUrvdkbyJorkyPv+/j+mf2tWVv
Sj/Nv7Va1+0gwUP9pm0yGXOMrDWn+2lsF+enaY4daoEXe0nRvpPwxIvtIIJS
qoHX22rgvxf1iBsnjU+TKzdtEji+nbtFmpwWUNgjL7r8qV4F2veiGFrQ0qdy
C01XSi3Oa8ZO/q/MqP9eHIfeOHar5aRJmQerTcm2dt6Z4IReXp53lnp55BXF
+Xm1qrgpN7m39YK27jl+kkbpc+AVMJ5z82qzpVcv7BQ30PCN6x3XEW7a42Ad
nlYRijA9Pmle9vDoxsWjfw/SErIWsJCdOPubJDrOot20xTyoDFZPo5Xe05OX
nJ7+1AxFPfDmiQ28NEOS5rFdBi/eNwwfEu1++q1NxNHXwaCPB9Pr8c27MMmf
HOaUq6Bg72Bwv/OVaz7+3uf7zcevnf4AThQkT6+X0Cz9sV6h/3unHti97QyO
M932O8eZBn3u/JE/ToqFjx9/HxzHfv3Knz4OetVkM/X68U6fsI8IBTt/9hBY
V35ZZsW3335jarFzx4dQN2xnN1Ddb+zBb3Hx/Fth28+/xXw+2KS93fKQzJyn
r31hH3LE35T9wdffrupZa3C6YiGJf9LkOrNLv22Xpc2cB/iSZoAF++kpcP6t
fqWyUI0j19fXbXvFQMspW63/0Gfj2bd/pO+/sdgNEnie3XaD56C0IwBBDYRA
higCQDYA1rbZoOWdKl3X77htWZupbaDfBtYvEZp22Q6KI65uCoZLdnuU77My
fQaU+oHTVhAK9rPX1vZJae/an0aK9hnelG8cFg83Ld3HDKcpA0RY6m6cSr4X
Ow9sPEyfsJR3FusobpC0t1jCb2NOJkfuZZHtQJLVvnqhkna2WnsYq0HGSrzE
bQuJw0QEKrc/yTNN+NyOEZLQVBFDO4WDGMckmL3xRoZyxSbLAIH4PYvSPZO1
OK/PJmECZIBAL8/xcvoCQSHWTas1hWldN6iWw0TeDkIGlSx+uq3krL2bTeAA
9UvP/VI9vkIuigLAOd787ZhUkGD+dQ0wu4LMbmC3S+SVeu/PAWKUrc226O3s
OIuYFoFuWZ6+BK7n3tQuEweuGyHn/IVljkrbbIVW6+ruXWr8s8x41f773/+B
s/3xxytvqxxpZReQEHnJPvsAS0aVuq8uVyJenJZwHM9hg+69PeR9yu3Te0yA
/1HhDdbBpltXzVDLy1PAMLbCpH0JWP7FhGz8vzHwwHAYAuskBczVTrfILIUf
ZMzREBXeS+DAKHka4xuwf8M0gXlz9pbdTrxt/Ur7k4N8ncZsCvyTeXllKgSU
i5QVJJ+Zc8OuJ+du7MCUUXhw7Sg4VG+8dfBKPVir8t+//70BQkj9qXpyNNIY
wz63twEAw7kIueLo646T5i77xLaLBX4hMqGiBkT/+IPJ78GzWCJhs7wLQHCF
at5Xrvih0zpx47TwQCzAvOaVv7BUBWMwgDlyJ+z1n1XWaDgjjfQMwP/4o1Vp
hg1l+rArT2siDVOMWMg2wwH9GM7C5pc2kxbevzqrNGe7uUSvk8wf26OR/J0R
me8zydiA6kfTW1WAVQv9CdTzc+0HDI3+CVFPYFFb0kuctHKHIvOc4Cmoo668
BOCiDkdA6HtLrfIiDK6zPG5kiMEfVxAjhZTAT3df4QXjlg7iHKaLgGd4WmcG
2X6xGbhm5S+BMrRrHi2IN5FtV0EUlHumJTcAGcmZvNWezjmr+NIO6k1kVbQm
2KGLKM33x0077VeaAggBb+tklrKh7Ln3m4uRrteA+9HR3nlRUNHfVY1flYbz
CoqTtHYEBjuIwTwt6ig5C/2zKYs6pdqIOccLWApx0k3ktgv7yYv27GkKhR2O
kh3lKJkE2HJS0c5jsgEOMcLq7co6NR1zgAgTNenhC2x8BNCT71b+cHzzhfnX
pacxE3+Ujt+m8k0Jcx28eu9p1oh0hTmu2p9YOfS5PYF3YIZHOwcZLRmOPlWF
2itfZypuRGufeCDT6yrdlKfoZhm3cql3IVn4lQZhJQYzmKXOkO26OGKz/0oW
q8KEeXXpPad55YJINl77LirSK8aTAP7HeAk3nh95WzjTdb3IdWk/MzBtCJoY
7NpXRlObXaHUqnRQgdU/EKSdbOKVl9/8rTVlWcVjroYI2JVegwcsxdYZNzhC
5S/s7oZRAd3L46CqSvatCixC5Nst0kfRvlIMTb/6Uv/dVmfVZyLMjSkRxuyz
Nrl7eDh9aDUjtMnMeBifP53fHM0URVDH9ct42r541LpS7pb4hYHC1exRn87U
u4er90jFmE0dfwErgMG9SmbaonVB4Yajx//3f/M9RhXgUx2eZ3m0/vKV/72H
L1vfS+rV0gRBVn+FNvctAIVn52wWViA7dsbYMhAG9oZbbZOqTIb23jp+0Tj9
UxpF6bbKv9AuSp3WO+j/1vrWvoM3Jo0XVwPAY5F0MdVFwnv9GhZlcdI8qiap
OxwnTnXMOR8mHLx+8Sp2k5d1CmLR/Y4FMuVU1LY4MolG3DN8VnSJ/aLcaXcs
Y1ckqq4QGlgtav4E3HGfvTqeLtIkgjMpG4Cv8LJiUQzemiCu+iNfmlj7Fbd+
q+mKztjb9qcjo/Dczz/RdjXpEeKquIrBlCOvClQGPXayZ8knSqvcdkLyf0a8
f+g2p4SNOK+kYz40vNOE255BHj7NRrqga5/ZzsYehjTvM45929vk0fl9bKoe
fBQPTLnabYf9dAJbyGTo4tdPmk6mqvRu4tQpPeSoRkMYef21hmpWfiOS3muy
nujtovzbRf/y3uUqPHxPhhh/POeGY3FxqbULulg39xAb0Bx/075iUTJK44yt
ob0eWCHMWcbfby6lbHWalyuZ/vzNS6Wyqv26fSV5KBmQAD+eoyHh76d6K0Y9
mRjZJVCfAcY/Od0b2Vp3P9tVe/bCgtjbXjH68Aw2klzO1n0zV4USFRV0vRJ0
DY5SZ80KmC5tcinWG3e4DIvYDr2Kkx797lc1WSW/Cx5xrOFjVs8Ahs5RW3xp
2We62ow7suCmZ4Q5mCuhSrpu0O/IOZkHn12YXEYBtvpLAl8g+olUFe0q6bLt
/zN7P/Zr/oE31WXBOXKegucqd2zi2M5P3O1d+fWhoIiv/4U/VY/q79X/tttX
mb2PUtu9+tY+o1aFMO8L2c9fji+drYL3/qN5ep60njgHKgGOPpoa0j0ef24o
5nn2yxUu3mYvnoDm82n8H82nv7Xqb9Uu//6t/ZdG/MYkeFus1Vc19f76L/9F
f6jKvqOKPv8LUzToWHiNcc/JX68i76m8+qOmau8LysppVkeMPtZIFVty0tg7
o3nTkKl0Vtvq0nfeuMrrcQjSp01esjVPGef646VAS6r+gR1tzmF89A3UFozV
MlZ1wdx+jjS1LB9lo49z+UceUdHH/5zcJ9drJK/Fea6MWjbKPFfvUNN/apmz
j56WYSjzztY/cwGsa78llidQfd1UqjgaiiNG/4r2qWlS9VXAebzolVmaxupP
yVHtMIM+d0rOb0zZv+myHf7jioslE2zhqLC6g8DWzjesrfnOSQd9/qd4dm4l
JcfK99RquaSIH0DY671+a/4GbJzR6MougJAVEfjWvkIB9QzXOMPNVQ2f13Xt
xoZwfKfb69/+/nXweliSJg7Do6v+773O7eBrr9O5/cr1fu+8HtT0h6/rtTpc
p3PN/X7NfdW57jeO/9bp3dzyX63Xb2RBwvpqNZe+diAoe7P2yEa5ld/99a9X
rdd492c41zxogOAS9d47olBr/KcIxpz6gwBtnQHnbeh+jFBnAl2dr9q5e6yt
s2N/AbWsHT2zqpN1IZoSc9d3mv5Y9eN5dI2irBNiN/U/fk9zBEhcd0KqRhlC
ubbKZavxS9u7eb7BSoLW6d9e1ej2QUD0bvh3SXn61G5grDkIqHomZ7maevq1
ZDV2XDUthrf9v7/9+fqD9+svbvrcoP3p8X66+NxmXsM6Z1UNV2mcHdexIG2a
942YTJN/LmbtdycY/MT6F+/Q8XOz+ku3/WkskIv1K5M5Ppvvz3Z0+7bCmDIX
jE+JQYVHfWu9kabSIRIKyF9j2PfA3Yxhjc/jvorILnw8+/Qvv/3L55vWu6b9
sfUV7VkbId1WZTAQ1c4qlynqkhJrOeF5qu9sqglWhSO5XuYldRmXnOt56BnI
8tupks3bweUeT4bZV+KCurK/Ko2zlokTbap24GsyV8+J7aHOZqPghXjEuirH
kwRsojrDqs4cLx0DI3KYINqfC2+WTqIItkCt0k48NhFrpLx+69hZYyb90qrF
Ylvdsqy0/aB3x0ZXjQC4guNjV6+m+9JCVrUZWa5aQlXTsvSaEx2otWBHQs2Z
BakOzHI7/1zrxatNbmP5uq94ZLZfWqxhCrcr9kXpxcXF8Iw54qU8rEh4qg77
z2dCKBGYy315O7YJkdX5jO7cJa5VvWp2W3eYkRHr5mzBDvuSpkx+nV77NVdq
uro3rY8zIivn3qZD+0Ow/TAnMpz8doS2E29nKPXtTzDoNJDhxGtm/0E64pGP
vvzZgM45YTXEvN3+k5R12la9qzc566Mk84tp61Vn4pivLrjfmRZWR8I/p6NN
C/c1w/701zcE/oPjv5+z5v67vNL6C9YNXmxn3x41AVV7Zy37uWD5AYwrQaZf
PDuqo2U69l6m4yM5BXPN0oT536fHqpv3+XQXoIlnuLPDDiPwwur1oe6x65U3
a6SOswFMsGOGia4/XjMlXesP2hd2OI718y+n84Z6pesyvT6FbhsjWTQk9Za/
vBp3OvMoTuDrOF5WHmnkeQ7Wq/QuYKRB3uYkqdjUh1UIRjcoWMOPmRZM2G6P
08h7uV7a6fnGxie7fRXDVZwg3QAqoAMveQbvYwd4zYWSP/6oWsjNRYC3ZuO5
jyK46X/UMdrQmhWrGqrjJnYknTWWdS4sWxm9OhZnjdWPrB4URZX1nqrrCL9y
GHJse5zSf9Uhf3WUVANlVYG4bs5U8HaP/MUOLxs+p4MNdiXj2asarZXfpcVR
2uqQb81wtB5TvDnmLY83rPa1fMyFjuXK0fPqnnYBPy7OWF9UB9RHMSte1FwY
cKtQqOD2OFOdZ9p/fumg9t/6vO7N+UVUpE13CyY8bSSFQ9bmqmw3vVPv3tkN
2KOw3HbNjtGOrrxvQqtopD/eCCl+5TJJE7ZX1bRtNm1x1cyQV4JgyT+boVVh
cCVOfbHs9ejqN22zKl/9/G4CNoYhT8CS/JmxYygqI6/6eXY8RPz4Z+HY7b4M
AQxB0PxrhZ0Xrlvd2qmPDYtX3aGP/jRFdGV+LFeRqddNxKoJWO3yGGrvZGDH
hUfT/MdPIrLOZNV9zoo6NAfe7+bSLy4NAf9r8Sq60OxklSODAPWC82SRV8v4
uFlFAXimezoSrybGvP+hT6Yayxh/q0fenW3YHE3XjcigeHUgjPfu1Kly96V9
WwIf/eYsjTWGGllATlPgNguNi2TwW/YqUNpFGm1q/66WPp9ivzr2/dbMqNjP
gdMch34qPkME9egF7bYYwCrVqSibuv755mW9Pr3rQClp4YMMYWDllCy91gNP
3vQIm8JU/099AfKIZFW5x4h/czfq2AF7LWO7vp5Xr1appm1KJ8smdTvDfmaK
e5gqU10YN87P+kBOreyKv9dj1Jkq1CqpL9W+mXNUo2R1NxU0z8tfr/94zoDH
aK5k/Ddw4aZIxpZyuCY7+6z0OGOoc+eESbplibS66dZqmV5DxqMg9OpDQDsJ
m9Izr3Id6ELgbVlwNRk7YGrJNiWj9Sxky8DZREi4F3dOv0Apz2nbhF7sL+db
rZUPvblJW12nSsLT/Mc+fXUrLR29qX8qU01Sdo9sE7QfgmrGCeiBx66iBHaF
rg3Jq1Nh4V1emwNrdl/XPvVlgebaKFKCxuohrz08Fm5Va6ru0jXzHrnIW2Z1
3X6kpP2pOjNthmDuc0XyhrQHF1T9mMCK07Gr/WqSC27zpbpV9+ftZnaLqeLN
f738w47rhW9tVKKwOSBve7yWx87yoIQ200L7zUt/RfpsXfT9r7y9nFkLEj8s
rBfXVFNrMS2dmO5ckx7ccdZZdenaluh+us5+nyZq5MSRvxp9b/Eb1+QDjA5m
wXSr6NODOjY66uG5Pw22wSoebJYdg/3WIV2yueczonG9vTYRBRJZ+TykPTP8
3tqRR50LHkbyGmv6rkTDB3Owma7TQFnf7ZWA26p7bjsT59vZOOUU9m/Q6ynr
oc1WcSbyiyd9b0WlvSD9h4UcWZ3o4E5k3wn4tbWQOTaTbkTyfE1+zDl1aJpR
Ml+48jwUE81wh6YYdpVYDpgs/HDFueN5V5wYHMfNDHmoG6pKRNoji2xohHKi
R9Zobg7UeafYqVTc0CTz6YEWy4OqegIx5gZ2NLK4von517ohS3oyDAmPGSbZ
UD/OYPDqPN5pK0k5GCEhVBAjkjhbz+AFsohUgh2pXT3ORFXgDS0WJfcwvNUN
IrIRy647s0OD0ym5X+K7OvFFLxS1eezOaChjD/zYPuBF83urb3qxuFDN3Vrh
+B4RyVAXjrtQ1XlozRyJTOjCnxBBXBxn0DGrIsqdZeRKDmSRCy3e2Uq8u7UE
/96W1B/zKMPb/GSeRDvCq6o6joYWRyfQ8Om7y9HpXB/Kc0Me2YfvLaGj7QeZ
eohejLh8UGkUWHSYzESqG+vnF3eh7CxxSG2aTfUFebF5NXSMErJbG9pVR9ao
3Bmw0bZLeTm2Yrqwu1FimfKLFlvyStrxTqxmypp2V7Gf6bw1Jh0EYzjldWO6
JZywoya5N6i40GEjmRBOHTucOzQoleaJi93IidWVYTt8j8Q1EXxhbgwqW2qi
0IM945lAme3G8KWhy8NGQ9MgprEeavBm0eXvOM0k6xW1NkvqzxRJLUkSKaYo
M/8grqnsIWdAeYtfdsOdbZKxuvjeorYpqmNN6t+vxHS/mmShJmTpshPuFDFb
6uvhzNbp7ZK6pitmC3WRKZRLt7rE8SuJXfIpR1bne8vd2VL5Q+eHxDAIbNGH
3smIhGI2T/zCEuTUTIQtWSx5LdzujYm8mHdJ3zhYKRGjhbKIxvr+e2ugLRc0
cASlq0NsIrmyLYiKwWWBxe02VscPlogbRSJrylmUxl9fLM6dKaPBD7eb3Zvr
ob4aQ7spfFI2pWI3Tfi6h/7mzLBuVFwcEjIc6qmmEsyioo7YoDRYxC4N9TJi
pb5pJypVjZ9G7HjYm3ezoXaMNxoZc7OUjJDX6MKFpSKBRiLwiAw94XurZDG8
MTp84VJoNrHWq1DskSQb0lcRS6Ry60hyaQn1eBq6iC4iIqrVOfe9JS4RX7In
8IK5cGdEEHZ6SCxP6EsrrOfFBa/zJMfvP/SFr9oht8N3qlIX0aSqxkLtzuFT
okXwj2FASi4bUQr0CfmRjn0rlIrzjtvVqVquJtRWJsPtMuZDIk0PGjwYu+sS
yt7/3mIzWKLbGWA0ZAr7AtXlmRc7vE7ltctZpPJcCiwWBF7rMIzo6ytzx8OG
wCVSrhD3mU0F2QaKqYST+47h6ro+78/hh1X0HL9Do5ogbDVDHM0PTn8lRb4R
qyM7ytYENqJL9+DuqQl0T8hEC0VeG5OtfSCyOgbGYHaHN3aKGSlEUMe6VJr2
hFC6nu5WC8vXOLWjI0qe96ZW6rrpkplkxS633Svd9ECFyJxH7g9LJCMv5FlE
wxvUyZyKlIRyl5juaL72F5roID6+t5Q9WRDgsQUkU3iGjTQhNqx5q4vuvSLs
SmAlNPqVh+0IZhzNhErzobZwoTB+tMSORIlEomKH/VtD3L4Y/PbF7gx4OxK7
NjRMdBq7ibs2TbnGSF2klpDBIkB9c8Aw8kCYvxBqWCMXaK0bAtcglADUHC1G
g65hUCBoNLXgoxrHsElM7U72aIgiAVYneugPCXxXFudmNHJ1tYv8pDhcphpj
etD1u64iPOdYYe8ZfarG7oMX7h5hF8mjsqZ3djvH8DOLixITs6ilFu4ML6SF
G873jjR4UGPSU+PtDrLwnskbqxiYKZAYmcB3J3SpRPKLzhmDacQV04T0HTCC
6e00OXMI0LnDfSc7rDo9lt/9leSADciicZjyaiAfz9Yuzvqv7BV97ulj6aDp
azoJERne1OzeDTd9a+EqEe8IP7bO9C6aiGZvmEfSava9dT0m+v3TfjSTdprZ
G1yHpezkNFo+3/8Y9Xaxle65OWtF/vG31qtDs4YB1sSs4X8N/Xu6aD7+ClX8
sybk6X07X6UB+893zq2t95ORE+88jwJrZJf2atbJ2uaMrDdznW/9PaWp2/Qx
WGuN0fmqreakacia09Pk3AGqG3HVVOcJTiz1WPofiewn7PBzMzX7LwpWnpcc
b0CfjpxfcdqmVZqcBzfdxg9Gtz9d1QJeff5yPFNGZYPXqm54mm9RAtWl8/Hy
4rue+SX9Pk/9bh+E7aO4uA15oeXjCr9Iy9mJQV111x1V1FeszmKlA/vvxVas
n1Bfyqp+b5rG0AkSX5DmzS2l6zdi/p/J98FmIjeOwN6jg9OlkRMADULwqa4r
rTgRCCryug6kUR8OkXLPq5mKrDTnBoLNk+J+Pxh5kn941KbFNO6/rGI1Ysxd
DV1uFZS2YZQzJfR3RLBMm2Oo54mZYujcoKkCslUXu+hEySpGBfHRzkaQJ6Z9
ZErLlHaH5RqzSDYX/Vh1IhtPHpactTUpLRWDX5Dkbm+GVqh3pjtHjBgZ+rGM
LFsVMwl5NVpRWVxy5N5GNuB2ZiJawO4FGFHhmKoAtA/sAz2YOt7uiMh5RDVF
K0e1IDmiW9gCqgY92hq8H4JdiIwzWYbNy6ZuFrwaZbc0zHxTIlvTRP1jEhNc
16Sd3XxJae5R+kOP1JAu1B5kvqdgHMaaUgX5zZ8YkXXv8O5Gi2RfoeGWrmVO
FWkxj6hKOjvV0Idbh4Z7hbo+4eUpjXlUEtbtaizqtDvsLOn3lrFzqLhcCX2f
CtMDlfq520H9ZbgUMs2N0Om5YC5GYqlEF7fIlJoei7kW+zrtbA9gqjMNs6gb
EzWOkjxDq1ZqcH3qQZOrhe/rJt/DLkUbTIpw/a1O3S3eElddt5HB0mgsiw6Y
DPKGkPXAg0Y6LxaW6AfkQDXKuZrGg8sJbgA5TTOk97BR6XQzgx7EB8wQOiFP
tRjVFM/8BTPMUJlIeEclggxKSLdz3kK9OTCwwoTGmWbw7nQeqibtkoclZIce
cz2SwfJ2jxQ7IvdeTEUwNm0VWYtl3B+teGsDi64Vc9uhUsGvRIBFBD+Ilpyh
iy8uqgdLhCXEbEdDy9Qgy3RnJJSsFkSH3i1FpLk9cQne3BsdjqemLDkC+E9E
e1TaSaiIJT2ONGUsdGjkcgZPC1arWho0qYP/zRQ+M1HBafAZaxkavMFPt+ok
M8lB7BpgnSTkTRqRgKKyMkN/O+f6BbyE2pAlK/AL2Ixr6HFpKKG1x3ewTqsA
H1gwGYzI4DVTFGFLtguUS2BS/Bw+L+s2l2WsmsIM2LAjWCjqrCU8OlxJMjWj
yFhJc25pFluwHMOIVA2aHtOQmlpHLoxEXdhcX6PrOzBj8MSFK4mQoT+lZplS
3p3YQgQprQlqDQm1jziDz4L1YgYLviRTBQzUDjN7GcIbxHBrMS6/Vow+Zxku
tCYvrYO8wAwvxkGWNJFsSCQHmiDDmu7BE1WJJDTQJB+WMCp2DpkIY76DLo3L
FIxaVHVC7dB6ZNYlpixqcamSKLuHjrQ5rxYksqCHfmqZJfWocUDcr4ludJaw
kW/Di5eYxViJGeLC2lJeLFUKhi1msLC7XcWkNKAnU/LBmct7ykemmSAKIhmI
0rdt7Iin6kK2FLrcUljfFN0N3lSVMRVoB6gI/6CJHILjL3RKt6gbSsT2gnCo
GUOHX+I9h9VkVFmLPmqce02i4HFZQBFrqFoxK7fXEuJDL3hkbeF7P4CSAVjy
3uCJhJ3S1ViFFhhiWoaFepXmrggk5jOr9mpagB8zBPuBSgV6sUwzcjXFsHiT
eWQsbJ0JKvaw/2AgByAueCtHXASEIi7M0lwB+6DJR2r0fR2ViSkaW+DvjMAj
jZjbGYgrM6yjwggtyUE00pzZAiKP6VoENV/uaCISoIG21EWb8JmACkAlYX9J
TX5rw6edMfh+lL3Q8d2OeYMRAaUCxNGMroe21lF2q7HF0CCHT+7gzLk1Jj6N
oh7tZJIZcnt3TCwaw77YFVCtJJGvsd4Gyg19uFaostdCN1A6u8zg/JETGVsK
TSpm2V/qagos2cwjRGYXPjyWmWZ/mPiObLJkMU1tl3eBLxE8iPUpnL7CW+Ky
66qUy1hUmIhb+BOBJrOc+bgmkSkBslMjg89Y0AK0WwBHZ3Qx1PDkHvVjCZRc
Q5P80vBnSypTZ2KZyppK1li8N6lrkIj4SmfOQ7upxrsSQb2VURvzWeZu60Y0
NxGrkAn4Auw1KfyZLGjsLxjW421Dj6gJdHiAjKHNqyVWq/QimroBPYiocSEB
jQf9peEWJvzBTKiBnKkvzZ2FXRfwl4BKz3toegR82SoGeTQFK684w0gXl3tH
QCbkMhEo2dd5FehQmopEbi0DVQuczO5EypzLWKckdIFHxlpkvZhbzcxQJ0O7
LPevV3q4xVozSLswzOjRNrICeP2iiKSwWMbTo8PyIBewzcITSoqMtoUeRWS8
XIO/AGt1yuPX1GbRn8jaCuCBiITXL7fLg2gCRXkgt63zlkFC1bJDOYfPil4k
57aInImYFrt0LCJuRIbEBjADHkVl5AJDT1zmw29yQXaADBKyr2iJlu+F2DN2
tIMMcmkskBMhLWxjIzvcomYi2LdkCW5KO8gWiA7UyT3sSqOd6cESabCaDHem
yXOsDu1LWgLMMrLFEtzApdbEk0SC2DUZKiKbHIy1akHTD5YAdIjJxGYMSEx3
jDvY/HJPE+QAIHVG2Qw6T4156C6Qjybwhy0yG/QAjzP9HLu+BwYvbZH6igGO
E4G30Oleq/aArFYsI1/1REsgkcqsJ+nUR5ywXDCwaFftAn+IJ7IcOGBxA2bg
9oDcyGORAXzRdIYMNuNJZizSFVAK3MC2OR6ZnZjAXd2IdzbjBsxnKS+PqWjZ
+Lsgi8gmQp9S5EwFzCOCtVyL6hDf7IdmjF0kMrU75B5RMXNphkhltqC31NwB
b1zkTHcB9EC2hZ6APxp8l6oKlReVHiTxlqEl9PGA6DddMbpF7ILbwRYhGUFm
8BtgrURMZB8bv+UYr1LWme5D6hQedYsYtVhW1RnDoWJRcQMjBVMsQ5dlj9DS
VwZjIJRZ4sc8LGeUYwyJcQb4rYQ4xh6R6+KdzLzaiDOmBzB0SzPCPnAYeqAZ
8jVimjfAW1x4w7JjLjLThnane08agFGLj4YO/+yoE0cEZ4oym7ELu0OB/b65
grXBoe41auyBP9hFX0RGC1FZQE/I0yxbPOjmDpZTc9XMVMaZYAvkLGJqYcWH
KTwP5AMsACvAdjsw5tSmrCs9oB7LR4+YQTNpeliJPlXqXQCBaD4z/MVKF3Pg
T6hSIFRiwWczaYnfjVieGIkPZgBvgI1kk/kD9ACuWDNF4AtjRSxP6/DpFy+C
baSSRcVuaVgpBdfU14Sx/plFLaAoLF0Cu1UafwWGlaYe8qy3pK0koCT0gMhn
THEG60/gkZzOomA8rBmSLt5rwgA+j1lYXOhAKPATAZzbshGZM8p8NjJYj7fy
D2T6mQkOB41T5K8J8rjkhH0AGnghkGHOeJykdEgJr36kgpUCHSwvihYK03QI
9oGsaneAHgkQyyQPjGsyLdjItLD+gnZgI9NFZoc3syyroXop4ECI7UG0EiJw
yx34imUCoRA3IsvLyDiywbqZhMKW8S5k+UheGAsXVVvfMhaokZFVgJZAKLEL
mYqlwUsaLOSFMuPc0LRczkxfXYUySCVFXNX+YjGcBb7IKfIU4qIEl7SWmGEG
ficyvstYO/Sguh2VRaZGorTDfHoecsgmlq0A67AvxKZKGYqLJnCXgy16K0k4
2KC4lU+vZUSDWgAd1FX8zJkYt+qoEnIqqzyWjDMYwAeDcQGMBGOO+zO7I+zI
mgIlFZ4KqCNE+sMIB4EJ61KOqipqSgpkw+rZEpHJ9IJdRGqAuGBslWUTCVzA
oF3/wZJ2BAyJMZEAtcqtwTs86qcFKi2ditk99LRVIlSiyCSDQFkMLcSFZkuw
5trSvTDrWiYve0Z/shJ4Asb8wtDBBh7OFkMdXo+8XuaeSMqVUD4a0Et00Mz+
zBHTvWr6oSZafTNSZTWMShJHiGVlC9augTkyvfiIChk+KyFSS/iSCe45qk6b
gOWobqUSu3B7pj40PWm+18OMYFcy/GWtiOJGS1RNCTPWFkXFhcwq8RF43xyx
jriCpW8NHRN151uw1ZkHloVa31YmpAf/0VQJ0TqxIirImmb2dshzH5wgQi//
8AxRHfv2f+l8Ih7csvMJuhAvzifoYRjpEyqT/w4nisLAmOvgh/AU2tUR+wrH
3zYnimBRZAjPNAhqYjvkDvoiYyeKEhjFf/1EUbFD8fDqRPEengIuIhce8IlM
tdhf24a8WK5VE545oUkEjWXFkkfuYLswXarEuw0q3AK5tj9nB2ZS2aWQGbZP
ll2wqGNHXK5P707f2WleVw/V4ZzOO2ATnfnC2tFJugPfyFyjv7BFf2ss1Jx1
O4Z9lROnmigqLu9n2nqYEWPHqQmdGZK4mRu9LfI/aqvocTH6iuqZiHYY5fNI
fFkmTs80yp3N+E9PC33T4FAFraMHvQOm23XvYQej1oHPWKIAnHzA98SBvMSw
EDWqoAnQIcd0CN+fGroPTS57pPaVkSqI3XnHRWouX8wwurXXQ5F5GxHlLv7W
5kaUmIvpXpes3aojjjWO1eOqKA+XHF9qcZhDD7YDpm2DhbimKxuc0NU7/oOR
CAfTUGUy8TeGwKurZLiEHxlONLx3mV4WnqlGhE53Ch32kJ8294fhGLl+auvy
zuoOF+ZoWkxDXtYMecvObuaUlhYndvF9aHHRZI5ZnK1l7HhtVB7PPo7nw9VJ
Kmo96gngrFQ++vgLdp0rOiWryAKXd3hWjyvwTV+ANpWjR2F3I9R2qPldzEBu
50b/OIOKKCkqtOFlwaAE8Gh1lQnqcWRCgcfUosvxP3QdERZmfn3yfoyTiyj5
IFKBLH8Sq78aqYjpV7H6z52x6Z2yY/Nk6oK5+GQlzg8k9O8VSn1Nd3Jw5Kne
mW7Bqw8GB58WHN7t0gfDID9sk/aUseU88OoaFGKuxVHgQhZ3SoVpTqLtC7T1
w0LNoAluX6HRgzNx12Aya4dX+0sz0yCrAFnl5rRKPJ9WIYeocxpVvjvnRAJM
EazqnHW6NQSRaOL2BXqpzq40g6rz9bA5GSOJQd3RPCIvjKNGqheJocMR56GT
OQ/7MjHxptpRR6xKYbOYEv+jPvV+d+Z9X515s7M1xLDIgUEd7rlIgWbnGupX
e0yCGXVRffgz1/TBJu868MwAO1Dm/PbFiiyLSBlR48GYdTBFgRxk3gjVKeqI
ndKN0vna6FERedyUb7Xxc653dimqwQ7+1sgY9elCFCxJJe6Ba07GEI19Z/T/
w8kY93TY/KDu3vdis9j8z8ncE69H8Xwrew/ZYKqV6tP1yrS2h1stXefCjPTs
763xj1uqlXvpq2cu1tJEtQKy3z/I6e/kkc/vMbXW2f78ZOx4xnQ6IvmlU7Jf
PeX6lSOz84vNNeD6ZKz6f7Ao0+a46kt1Of0X72adLxk3M34w4eV8/02vaN26
8YBfdvzqoAW/+05XjZyEZMyp4EzFil0KSSxzzlzsYC3kbGluy1VCy2XMDndA
jsbCXjnMAQZOb/bm4AVlYqpJ854SsWAypPKgjIc6CgRD0yPhePCy7MrRckEA
a/zLih34rKdbZT0tlbGDf11D0Z1bgNitMv7eEjazcbg1A6yTDLNV3GdvhasO
79tmr1x26L46ovm/6eT/sHSyfDE6KirE4b1tyh0L4Osb86CUHnjRsGMXpaI/
8XTR0rrD7pLrq8uuqnum+MOIANUCP9Lqqy0hEoY4D1gqYYkEieDnqWQ0GM2p
KGBXMjH4kdJc0SCSSygnj6g0sFFZ3DK6Sg5kNPhRpZHRV6wv3yN+pg+8X4Ke
1lTM9HM7HMyNesaZFuLv0B3a7ALGxCfKHoWwrAvuyBAizug8c8t1tDAlf6kn
NHWQydTwOV8GSCH7QUyjSLAjobPiVBk6migJ1eacX7AWmXDwTH+k6r5hCjxd
Jtl0NiofWYOALqzHlSgLrN3rGCRc8mKXFTVPC+4/X52UdXUiXd53pJw1skM1
N/873Z5aw1Ds9hS77yjUHQsETkRkReClFc9CNeTq+48DVq3M8H2rGwBDntyC
rQMMSrAJQBUFb06xC4J6tUeiulY41lhEoBcyGPq0D46LFYcIQrXiI+zGkth1
O+7xNlTzBgkULgMUWbYbk4UeD2xTiBKqA2hjubqP5RmyYkZ+7vKuwRyYgKGo
J4YCELtgLAjRkcv1x3ND1OcHKwCsDVcmBde2umocESeSDzNUw9OtGTm5Kk0B
dG7fkviFc5An0KiEGjuwkRSUuC+bwvNB76KK4S1+NlH2RmJlcOKZDcdiFYE7
0gSfm8ckIyG1zcQK1M6gp8Ga4GOPTYVCZgKAdu2LDPTm3JSD34wReLLWQUCx
M4EfilDdShIMXhy6vJxopj/UdDI3TbnnTtSDJt7tMVMPjIrzIgo+CU7ZVfuW
sD0oAoEWUEGi4ldnM5Mfg0nN52aEesaSUQe+3HPWo8LJBpKQQhLV16JMg2VD
tZs9ugt1g1nBXTNUV7CRqHXkA4I+owiUhbYN3Em0ZanrnBj5H25Xye1EZckJ
6U0srD1LMVRX1kaHcTPuQ6q15ycPy6EYbdPNU6+zMLV7w1x7y/kkkTrz27ve
an33u/+ih8PugXcf4YhIkuvHSblRO3Nvd/s83ulPthbce+lCKmbjnmzOnufy
4/NPqdaJWNWk5GNm9ZYM/YRAtdut/w/D0vzWVl0AAA==

-->

</rfc>