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.7.17 (Ruby 2.6.10) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-anima-jws-voucher-12" category="std" consensus="true" submissionType="IETF" 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-12"/>
    <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="2024" month="September" day="12"/>
    <area>Internet</area>
    <workgroup>anima Working Group</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 67?>

<t>I-D.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>
    <?line 74?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>"A Voucher Artifact for Bootstrapping Protocols" <xref target="I-D.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"/> 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>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).
This document should be considered as enhancement of <xref target="I-D.ietf-anima-rfc8366bis"/>,
as it provides a new voucher form with media type "application/voucher-jws+json" and the related serialization.
It does not extend the YANG definition of <xref target="I-D.ietf-anima-rfc8366bis"/>.</t>
      <t>Another example of an enhancement of <xref target="I-D.ietf-anima-rfc8366bis"/> is <xref target="I-D.ietf-anima-constrained-voucher"/>.
It provides the serialization of voucher data to CBOR <xref target="RFC8949"/>,
with the signature in form of COSE <xref target="RFC8812"/> and the media type "application/voucher-cose+cbor".</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>
    </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.
<?line -6?>
      </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 Manufacturer Authorized Signing Authority (MASA) service that indicates to a Pledge the cryptographic identity of the domain it should trust, per <xref target="I-D.ietf-anima-rfc8366bis"/>.</t>
        </dd>
        <dt>Voucher Data:</dt>
        <dd>
          <t>The raw (serialized) representation of "ietf-voucher" YANG module without any enclosing signature, per <xref target="I-D.ietf-anima-rfc8366bis"/>.</t>
        </dd>
      </dl>
      <t>MASA (Manufacturer Authorized Signing Authority):
The entity that, for the purpose of this document, issues and signs the vouchers for a manufacturer's pledges. In some onboarding protocols, the MASA may have an Internet presence and be integral to the onboarding process, whereas in other protocols the MASA may be an offline service that has no active role in the onboarding process, per <xref target="I-D.ietf-anima-rfc8366bis"/>.</t>
      <t>Pledge:
The prospective component attempting to find and securely join a domain. When shipped or in factory reset mode, it only trusts authorized representatives of the manufacturer, per <xref target="I-D.ietf-anima-rfc8366bis"/>.</t>
      <t>Registrar:
A representative of the domain that is configured, perhaps autonomically, to decide whether a new device is allowed to join the domain, per <xref target="I-D.ietf-anima-rfc8366bis"/>.</t>
      <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 "General JWS JSON Serialization Syntax" of <xref target="RFC7515"/> to support multiple signatures,
as already supported by <xref target="RFC8366"/> for CMS-signed vouchers.
Note, "JWS Compact Serialization" is limited to one signature.</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="7.3" sectionFormat="of" target="I-D.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 "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 escaping 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>To validate voucher signatures all certificates of the certificate chain are required up to the trust anchor.
Note, to establish trust the trust anchor SHOULD be provided out-of-band upfront.
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": "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 Pledge-Voucher-Request (PVR) reveals the IDevID of the component (Pledge) that is in the process of bootstrapping.</t>
      <t>A PVR is transported via HTTP-over-TLS. However, for the Pledge-to-Registrar TLS connection a Pledge provisionally accepts the Registrar server certificate during the TLS server authentication.
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.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 anchor="sec-normative-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.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="8" month="July" year="2024"/>
            <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-12"/>
        </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 anchor="sec-informative-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-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="26" month="August" year="2024"/>
            <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 new endpoints
   for the Domain Registrar and pledge, and 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 Key Infrastructure (e.g., domain CA).

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-anima-brski-prm-15"/>
        </reference>
        <reference anchor="I-D.ietf-anima-constrained-voucher">
          <front>
            <title>Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI)</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="8" month="July" year="2024"/>
            <abstract>
              <t>   This document defines the Constrained Bootstrapping Remote Secure Key
   Infrastructure (cBRSKI) protocol, which provides a solution for
   secure zero-touch onboarding 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. cBRSKI 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 data is
   encoded in JSON, cBRSKI uses a compact CBOR-encoded voucher.  The
   BRSKI voucher data definition 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 DTLS-secured CoAP
   (CoAPS).  This document Updates RFC 8995 and RFC 9148.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-anima-constrained-voucher-25"/>
        </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:
H4sIAGKl4mYAA+1863Kjypbmfz2FxididlWcsjfo4ipXzJ7TlgRI2CArgUSi
q6MDATaIawGyLif2PMs8yzzZfAlIsmxXneru+dEdMTv2PiWhJHPlunzrWyuz
zuXlZasMysj72pZNrV0ET4nntmm6dnwvb9/mZfBoO2XRfkzz9iBNy6LM7SwL
kqf2Q56WqZNGRcteLnPvuZrg8rl+s+WmTmLHmNXN7cfyMvDKx0s7CWL7crUp
DqMu+U6rWC/joCiCNNF3GcZPBF1stYrSTtx/taM0waMyX3utVpDl1cei7HDc
Dddp2blnY3xSennila3N09d2tULbTPOQSSjl6TprhZvToMsRk6bl2OXXdlG6
rVYWfG3jn7+0HTtprwuvbee5vWt/CB7bdhS1d17xsY2d+3bhtyGw12q3semv
7Ad8LNK8zL3H4ms1hes92usIuirTw++7uP6ZfW3Z69JP86+t1mU7SPBQv2qb
TKocI2td6X4a28XpaZpjT1rgxV5StG8lPPFiO4ighmrg5aYa+E9FPeLKSePj
5MpVmwSOb+dukSbHBRT2yIvOf6pXgb69KIYWtPSx3EC3lRqL05qxk/+VmfGf
isPQK8dutZw0KfNguS7Z1k47E5zQy8vTzlIvj7yiOD2vVhXX5Tr3Nl7Q1j3H
T9IofQq8AuZyrl5stvTqhZ3iChq+cr3DOsJVexSswuMqQhGmhyfNyx4eXbl4
9E9BWkLWAhayE2d3lUSHWbSrtpgHlcHqabTSe3z0kuPTH5qhqAdePbKB52ZI
0jy2y+DZ+4rhA6LdTb62iTj8cnPTx4PJ5ejqRUjkj86X7vX1MijYaAzrd75w
zcfPfb7ffPzS6d/AfYLk8eXkmqU/1HP3P3fqgd3rzs1hput+5zDTTZ87feQP
k2Lhw8fPN4exX77wx483vWqyqXr5cKuP2UcEgZ0/eQiiC78ss+Lr778zhdi5
40OoamdXUNrv7MHvcfH0e2HbT7/HfH6zTnvbxT6ZOo9f+sIu5Ii/Lvs3X36/
qGetgeiCBSP+TZPLzC79tl2WNnMbYEmaAQLsx8fA+Vv9SmWbGjMuLy/b9pIB
lFO2Wj9UMYvTIIGX2W03eApKO0LQ1zAHFIgiwF8DT22bDVrcqtJl/Y7blrWp
2ga2rWHpEmFol23M2KDmumCoY7eH+S4r0ycApR84bQVubz95bW2XlPa2/WGo
aB/hOfnaYb5/1dJ9JtNhygDRlLprp5Lv2c4DGw/TRyzlncQ6iBsk7Q2W8NuY
k8mRe1lkO5BkuateqKSdLlcexmqQsRIvcdtC4jARgbntD/JUEz62Y4QfFFXE
0E7hIJ4xCWZv/I8hWrHOMsAdfs+idMdkLU7rs0mYABngzstzvJw+Q1CIdQVL
wJiuG1TLYSJvCyGDShY/3VRy1v7MJnCA6aXnfqoeXyDTRAHAGm/+fkgZSB9/
XQG4LiCzG9jtElmj3vtTgHhka7Mtels7ziKmRSBZlqfPgeu5V7WTxIHrRsgo
f2F5odI2W6HVurh9k/h+lvcu2n//+w+97M8/X/hZ5UJLu4Bsrl3aJ+uzlFMp
+uJ8DeLFaQmX8Rw26M7bQdLH3D6+x5b+bxWqYB1st3XRDLW8PAXYYhNMzueA
5VVMyMb/jQEFhsMEWCcpYKh2ukH+KPwgYy6GePCeAwfmyNMY34Dwa6YDzJuz
t+x24m3qV9ofHOThNGZT4N/MyysjIZRcJKYg+cjcGhY9unVjAaaMwoNTR8G+
euO1a1fqwVqV5/797w3oQepNACBwzgKrOHi046S5yz6xrWGyX4g/qKMBxz//
ZLJ68B+WGtgsb8IM2b+a94XDveuaTty4JvzsPKqP239/B40Sqk0fPHDENAHP
YLHBBlQ/mt6yCmS7cp4PIFwfay2xKP3zzxbz/F+R9BhE9d69xEkrBRaZ5wSP
Qe2T5TkwFbWzAlqgvFd+v8yLMLjM8riRIQaHWkKMFFICV9xdFUeMXzmIAnhB
hDjH0xoxZfvZZqCTlb8EVq8hs/DTdeSy9Vh+h5orDCiwKyzteNUYKPCnwfqp
hReCMz9lzn5whcoIlQv+smbbB1vkXsQg7dzvr1oTFh1YKElLgFXpNaMZVNTI
ERzi46eCw9VuMQUTsoG8KpSTf9PumXHfGpVpE0jB8t6BsLP1Ji+0xCR+E8+v
Y3k4mJIm4BiXYMquVFm9fHTmF64+ZNmkeQE8pIa4X4vAtPD+6izTnIWgeVgE
7gVysgyioNyx+d0ArC1niqkc/5Twi0/MB5inZxXgJZDKBdDlu0NkOO0XywLH
YdmaCaRsKHvu/e5ipOs1mfGgjNNGT8kOLy3rFFCFYV7lsSSt1cuQG9CWp0Wt
5pPQP5qyqPmIDY9zvIDlX6cKjMJ+9KIde5oiqvYHyQ5ylEwCbDmp+PkhUwPK
GbOHZ9Z5/ZBAxfToaJ9go0MOeuERLIs3bz4zY52bjeHAe1zmdVCvS5hr37hY
mjUiXWCOi/YHVil+bI8BIZjhwc7B2kuWih6rGvYFIDIVN6K1j7SZ6XWZrsuj
AzK6UuHOFeMEupfHQVWK7FoVOoZIvxtkmKJ9oRiafvGp/rOtTqvPRJgZEyKM
2GdtfHt/f/zQakZo46lxPzp9Or05nCqKoI7ql/G0ffaodaHcLvAL8/6L6YM+
maq39xdvoZlRnNqXAlbngoSVFQK2zrjcYPjwf/4332PMAfrp8DxLq/WXL/zn
HsuxvpfUq6UJHKb+CiXtWnB6z87ZLKwqduyM0WZEC0AT6LtJqtr4qvU//hYB
LdqX13/7n63XKbBysprsRVG6qdI1NI2Kp/Um731tfW3foh5PGutUA0BukaMx
1Q+JA8zH7N/MVE1SNzWOdOuQcN/Ntnj97FXsLC9rUGJe+4YWMEVVfLc4EI9G
3BMsVExKecmjbqsmADzbPSa55hGw6YNyq91+ZIha8bC6vGhgpagp2APqkyev
Wu2cS8DFk7IBuAovKiLGwrvJj1Xr5FMbXO0fZpTXtqj4kb1pfzhgved+fMce
F9WMjZ4u6lQWg14jJzHAZyFnJzsGulFaJf4jgv2aWEw70NGvqvPj14bcVGph
yvx0hJ9snWfIFbWyXrgpEkBRrFn+h3GZeMVLL6vbYOfM+DegY2WT4gokvV2A
FCN8lqldU9LsUC3UJU21BcaOfPvZYwnm0Jlq18p0vGrlJpRh2+jgW+dzoj7E
jBsWdnZVh9UU4Lja+WLLaqn08bEKzzP3YtwWKQebQcZo52nk1fjy/oK/YqXa
Q2vd40WWOKu5nTTO0qTCqxLhkZUNYwfVqUu2oiphADyrlAFN48FXbRM41GZF
SsaAukIhpvw0ZzmtgOrgY16VuSvYqvwcBjx5xktPfYZtmwh5acVf2xqpaszc
BkDcvpr1VdgdOgPIhI/BE1ZwqxV8O6skS5M0DlizYfeJqeDIGLzKijX3bIqx
gLFlACb2gZGVak7r/JrY/xCIj/wfTLKKZobKg1tNuO4Z5P7DdKgLuvaRIcHI
w5DmfVbQXvfWeXR6H0qoBx8E07yqtm532E/HtAyZDF388kHTyUSV3kycOqVX
Hs2EkZdf6qTO+lrIU2+Rp57o9aL860X/8ra+r5jo29qq1XrJIg6V/LnWzohv
DQ3INtAcf9W+YHlnCI9na2gvB1b5+yTj56tzKVud5uVKpp+/ea5U1g67bF9I
HupzwMb7czRV8NupXotRTyZGLFarFPxvnO6VbIiXH+yqPX1meORtLpirPyGU
kvPZuq/mqrCiqixdrwSxh6PUIVGl+nObnIv1yh3OwyK2Q68qcatM9otarAqr
M7Z5aJPFrJnAqrFjjiuqGvNQ+TbjDgV104jFHMyNhop22XCJQ+a5aqmIj08/
d6yiHQVxUNZQkSYvFmfOf/J+ch5A0NIv7bemV695UNGu2DDTXNW0+0XVHTqq
/8AR6wbFKehqNIX64tjOjwXCmxr0XUERmv8L/1R9479X/9tuX2T2Lkpt9+Jr
+wR4FTi94YcfP346vHQyKt775+bpadJ6YuRibMt7b2pI93D4ualjTrOfr3D2
NnvxiFEfj+P/bD79S6v+Vu3y71/bf2nEb0yCt8VafVWj/Y/f/oP+UDWgDir6
+BtTNOqk8BLjnpI/LiLvsbz4s66h3ra2KqdZHuD9UIhXZYzDONQxETSN00pn
ta3OfeeVq7wch4B4XOdVTj0mq8v3l0Jar3p/drQ+5vKjb6CAjZf1ecBZSfVj
kKpleS+RvV/GvOcRVV3375P76HqN5LU4T5VRy0aZpz4i1PTvWubko8dlGMq8
sfWPXIBRm9dV3hGPXzZ/KzbFqBRqsaJ9bB5VDSZG/qIXZmmOPl6WImeVSO0w
N33umNffYFCX7fBn7TKWgYLi6LR1F7Pq9a3ZkcMb97zp8z9EslPHMXnZwXun
Jn4HvF7u8uuh8Pr6Aocu7ALYWKWHr+2LKH16glOcgOaiBs7LZM3Mx4ZwfKfb
619//nLzcliSojJhP/c/9zrXN196nc71F673ufNyUHN2c1mv1eE6nUvu8yX3
Ree6Xzn+a6d3dc1/sV6+kQUJay7WXPbSgaDszdoXG+VWHvfHHxetl0j3M4Rr
HjQQcI53b11QqDX+Q+xi7vxOaLZOUPM6aN/HphPrrm42oK5q+/X47NC+KmCs
6Ik1gliTq+n6bPtO06OvfjyNrvGTNdrspiLA76zs9eO60VY16xHEtVXOm62f
2t7V0xVWErRO//qixrV3QqF3xb9Jx5PHplQtm0O6qiV3kqtpcb2UrEaNi3da
5D9Z9+btuvOrPnfT/vBwN5l/bDNvYQ3ZqjVSaZodmrPgbI7VGvGYBn8uXu1v
R+D7wDryb/DwY7P6c7f9YSSQs/UrUzk+m+9nO7p+XY5MmOvFx1TACN7X1itp
Kt0hhWSsXVGj8huobsawSv+wryKyCx/PPvz2+28fr1pvjtMOHVXUy1V1CTAr
WFuvxrGibthgKSc8zfTtG5tqzJoUn9gxsJfUNV9yaqdBz0CU349tIhTr53s8
GmZXiQuuy/6oNM4aD060rrrML3hFMye2h7KejYL34RFrcB7O/VjRz86Vq5P/
c8fAiBwmiHasDE6ZpgKXWexND72oO5sv323S3EtDN0bO2anO93XApKiPCtjA
qvEAX3D8ND/QdSYXIn4ZBYXfDHg99OCSy9M5dTtdl5fpI5hPwhZ4zGHVpl6p
ewoFO+pOmur15GX9q37NQ5q2/FXr/ZzzVLVBzhOO/S6cvZt1GBJ9PYDHkRMz
HPj6TpQfB7BIfMmW3wF6Hkj/6WcDOqdU8I/J7nEz9V5e5YL3wPsX08GLNsEh
D5yxqRPRqq5B/JjgNcdaLznrhz9eUeK3dchPeGj/DV63/oJ1g2fb2aFsrI9H
6+K4lr3u1l02818SuDUcFiBLCWvxPnt200ycjLznyegYFMdm3od6ho/HlleD
qk3PkL2wfHm3gR1YtjF7dQDG7iE0ZTA7Kxrr+sMlU9mlfq9dtcfpBgLkp65t
I2yZXh47cW2MZBGRNAo4dsiPh2g1yDmOl5X1Tk7vsk4oOyZ7EeHuOj+QOTZz
M4I1E1kf2WkObysQbM4Ki3V9Zs36eEHBWtvMC0BD7fYojbzny4Wdnq4wfbDb
FzG8ygnSNTANGvKSJ1Avdo7f3LD688/qYKW5J/Pawjz3Xog3fYs6iBtmsWQ7
qbq7rJ2YNU7gnDlB5R/V3RHWI3/PQZp+OCZnt3V+fox8bJPbL6622C+OCYsd
cCuuiL/r5mzzr3fHn+3tvEVzPC9nd5WevOowofJH1smv5azawCsGrvWY4tUp
c3m4Zrir5Xt5sJM3vl+f68Avk+o+aNM8uGItwYOYFTlp7tO4VYhUSHyYiVkD
2/r5nZzareuz2FfneVGRNv0oGO+4kbTukMNQldUmt+rtG4sBoBR22HrJjkgP
nr5rWsBFI/3hqlTxK7esmnC+qKZts2mLi2aGvBIES/5shlYF05U49e3Kl6Or
37T1snzx85sJ2BhySLcnuoyhKEu86ufp4YD4/Z+FQ3/63PkxBOHy1wpgz1y3
us5WHwkXL5oy7/3T1K6V+VnHjTGal62/qnVX7fIQZG9k0DzvaJp//kEs1smu
Oiyqbls1lxnezKWf3aZDkqjFq4r5ZifLHGkGkBicJou8WsaHdUVU2BFmc92h
mhjz/rM+nmgsrfxLPfL2ZMPm2kHd/wuKF4f9eO9WnSi3n9rXJZDRb86WWT+m
kQUMMQWcs9A4SxK/Zy8CpV2k0br272rp0w2FF0f6X5sZFfspcNp1Pfuh+AgR
1IMXtNtiAKtUl23Y1PXPV8+r1fFdB0pJwdQe2cDKKVkOrgcevekBNoWp/nt9
C/iAZFWtxdh3c2nw0Hh6KWO7vqlar1appm1KR8smdS/BfmKKu58oE10YNc7P
2i9OreyKRNdj1Kkq1Cqpb5a/mnNYo2R1QRsM0Mtfrv9wSo+HaK5k/Fv7w6FC
ZfnZ86pDtUqPU4Y6t06YpBuWYqsroK2WiVqhOl+OgtCrqbCdhE3dl1dZDjQi
8DaH41P8EjC1ZOvyUwvokjGIddYR8vHZxetPUMpT2jahF/vT6Wp35UOvrpNX
tw2T8Dj/obteXddMh6+KkMpU45Rds1wH7fugmnEMduGxu2iBXaFrwwTrJFh4
5/dJQajdlwUIm7Curj7fsOtKGitKvPbgUD5VfaG6OdbM+yPedVlRow/VvYHD
UX96YiwfX/H54IzFHxJYcbx6YL+Y5Iz6fKounf68y8vuUFXk+o/zf9j1FeFr
+7dvv7Wr8+TN4dYqO32DEtpMC+1XL/2B9Nk6a7dfeDs5s+Ykvp9bz66pptZ8
Ujox3bom3bujrLPs0pUt0d1klX2eJGrkxJG/HH5r8WvX5AOMDqbBZKPok706
Mjrq/qk/CTbBMr5ZLzoG+61DumR9x2dE43o7bSwKJLLyWUh7ZvittSUPOhfc
D+UV1vRdiYb35s16skoDZXW7UwJuo+64zVScbaajlFPYf0Gvp6wGNlvFGcvP
nvStFZX2nPTv53JkdaK9O5Z9J+BX1lzm2Ey6EcmzFfk+49SBaUbJbO7Ks1BM
NMMdmGLYVWI5YLLwgyXnjmZdcWxwHDc15IFuqCoRaY/Ms4ERyokeWcOZeaPO
OsVWpeKaJplP97RY7FXVE4gxM7CjocX1Tcy/0g1Z0pNBSHjMMM4G+mEGg1dn
8VZbSsreCAmhghiRxNl4Bi+QeaQS7Ejt6nEmqgJvaLEoufvBtW4QkY1YdN2p
HRqcTsndAt/VsS96oajNYndKQxl74Ef2Hi+a31p904vFuWpuVwrH94hIBrpw
2IWqzkJr6khkTOf+mAji/DCDjlkVUe4sIldyIItcaPHWVuLttSX4d7akfp9F
Gd7mx7Mk2hJeVdVRNLA4OoaGj99djk5m+kCeGfLQ3n9rCR1td5Op++jZiMt7
lUaBRQfJVKS6sXp6dufK1hIH1KbZRJ+TZ5tXQ8coIbu1pl11aA3LrQEbbbqU
l2MrpnO7GyWWKT9rsSUvpS3vxGqmrGh3GfuZzlsj0kEwhhNeNyYbwglbapI7
g4pzHTaSCeHUkcO5A4NSaZa42I2cWF0ZtsP3SFwRwRdmxk1lS00UerBnPBUo
s90IvjRwedhoYBrENFYDDd4suvwtp5lktaTWekH9qSKpJUkixRRl5h/ENZUd
5Awob/GLbri1TTJS599a1DZFdaRJ/bulmO6W4yzUhCxddMKtImYLfTWY2jq9
XlDXdMVsrs4zhXLpRpc4fimxS2/l0Op8a7lbWyq/6/yAGAaBLfrQOxmSUMxm
iV9YgpyaibAh8wWvhZudMZbnsy7pG3srJWI0V+bRSN99a91oizkNHEHp6hCb
SK5sC6JicFlgcdu11fGDBeJGkciKchal8Zdni3OnyvDmu9vN7szVQF+OoN0U
PimbUrGdJHzdwH51VFf3MM7O5hgO9VRTCaZRUUdsUBosYheGeh6xUt+0E5Wq
xg8jdjTozbrZQDvEG42MmVlKRshrdO7CUpFAIxF4RAae8K1VshheGx2+cCk0
m1irZSj2SJIN6IuIJVK5cSS5tIR6PA1dRBcREdXqjPvWEheIL9kTeMGcu1Mi
CFs9JJYn9KUl1vPigtd5kuP37/rcV+2Q2+I7VamLaFJVY652Z/Ap0SL41zAg
JZcNKQX6hPxQx74VSsVZx+3qVC2XY2or48FmEfMhkSZ7DR6M3XUJZe9/a7EZ
LNHt3GA0ZAr7AtXlqRc7vE7llctZpPJcCiwWBF7rMIzo60tzy8OGwCVSLhH3
mU0F2QaKqYST+47h6ro+68/gh1X0HL5Do5ogbDRDHM72Tn8pRb4Rq0M7ylYE
NqILd+/uqAl0T8hYC0VeG5GNvSeyOgLGYHaHN7aKGSlEUEe6VJr2mFC6mmyX
c8vXOLWjI0qedqZW6rrpkqlkxS632SnddE+FyJxF7ndLJEMv5FlEwxvU8YyK
lIRyl5jucLby55roID6+tZQdmRPgsQUkU3iGjTQhNqx5rYvunSJsS2AlNPqF
h+0IZhxOhUrzoTZ3oTB+uMCORIlEomKH/WtD3Dwb/ObZ7tzwdiR2bWiY6DR2
E3dlmnKNkbpILSGDRYD65g3DyD1h/kKoYQ1doLVuCFyDUAJQczgf3nQNgwJB
o4kFH9U4hk1ianeyB0MUCbA60UN/QOC7sjgzo6Grq13kJ8XhMtUY0b2u33YV
4SnHCjvP6FM1du+9cPsAu0gelTW9s906hp9ZXJSYmEUttXBreCEt3HC2c6Sb
ezUmPTXebCEL75m8sYyBmQKJkQl8d0wXSiQ/65xxM4m4YpKQvgNGMLmeJCcO
ATq3v+tk+2Wnx/K7v5QcsAFZNPYTXg3kw8HW2RH7hb2kTz19JO01fUXHISLD
m5jd28G6b81dJeId4fvGmdxGY9HsDfJIWk6/tS5HRL973A2n0lYzezeXYSk7
OY0WT3ffh71tbKU7bsa6lX/+S+tFm7JhgDUxa/hfQ/8ezzqUv0IVf9apPL5v
58s0YH+v7Uj/3pmMHHnnqT8G1ljdSK1YJ7uty8h6M9fp5utjmrpNH4NdFWd0
vuq5OWkasmb+JDl1gOpDmWqq0wT2z7uQ9dTsouLS85LD7fbjSe8LTtv0U5PT
4KYL+c7o9oeLWsCLj58OB7qobPBa1ShP8w1KoLp0PtylfNNOP6ffP9buB8L2
caLl54K8WOEXaTk7W6ir7rrTivqK1VmsdGB/dXLJ+gn1Narq96azDJ0g8QVp
3twtOv4t7KZu+K/J98FmIjeOwN6jvdOlkRMADULwqa4rLTkRCCryug6kUe/3
kXLHq5mKrDTjbgSbJ8Xd7mboSf7+QZsUk7j/vIzViDF3NXS5ZVDahlFOldDf
EsEybY6hnidmiqFzN00VkC272EUnSpYxKoj3djaEPDHtI1NaprTdL1aYRbK5
6PuyE9l4cr/grI1JaakY/JwktzsztEK9M9k6YsTI0PdFZNmqmEnIq9GSyuKC
I3c2sgG3NRPRAnbPwYgKx1QFoH1g7+ne1PF2R0TOI6opWjmqBckR3cIWUDXo
0cbg/RDsQmScyTJsXjZ1s+DVKLumYeabEtmYJuofk5jguibtbGcLSnOP0u96
pIZ0rvYg8x0F4zBWlCrIb/7YiKw7h3fXWiT7Cg03dCVzqkiLWURV0tmqhj7Y
ODTcKdT1CS9PaMyjkrCulyNRp91BZ0G/tYytQ8XFUuj7VJjsqdTP3Q7qL8Ol
kGlmhE7PBXMxEkslurhBptT0WMy12NdpZ7MHU51qmEVdm6hxlOQJWrVSg+tT
D5pczn1fN/kedinaYFKE62906m7wlrjsuo0MlkZjWXTAZJA3hKwHHjTUebGw
RD8ge6pRztU0HlxOcAPIaZohvYONSqebGXQv3mOG0Al5qsWopnjmL5hhispE
wjsqEWRQQrqZ8RbqzRsDK4xpnGkG705moWrSLrlfQHboMdcjGSxv+0CxI3Ln
xVQEY9OWkTVfxP3hkrfWsOhKMTcdKhX8UgRYRPCDaMEZuvjsonqwRFhCzLY0
tEwNsky2RkLJck506N1SRJrbY5fgzZ3R4XhqypIjgP9EtEelrYSKWNLjSFNG
QodGLmfwtGC1qqVBkzr431ThMxMVnAafsRahwRv8ZKOOM5Psxa4B1klC3qQR
CSgqKzP0NzOuX8BLqA1ZsgK/gM24hh6XhhJaO3wH67QK8IE5k8GIDF4zRRG2
ZLtAuQQmxc/g87Juc1nGqinMgA07goWizlrAo8OlJFMzioylNOMWZrEByzGM
SNWg6RENqal15MJI1LnN9TW6ugUzBk+cu5IIGfoTapYp5d2xLUSQ0hqj1pBQ
+4hT+CxYL2aw4EsyVcBA7TCzFyG8QQw3FuPyK8Xoc5bhQmvywtrLc8zwbOxl
SRPJmkRyoAkyrOnuPVGVSEIDTfJhCaNi55CJMOZ706VxmYJRi6pOqB1aD8y6
xJRFLS5VEmV30JE249WCRBb00E8ts6QeNfaI+xXRjc4CNvJtePECsxhLMUNc
WBvKi6VKwbDFDBZ2N8uYlAb0ZEo+OHN5R/nINBNEQSQDUfq2jR3xVJ3LlkIX
Gwrrm6K7xpuqMqIC7QAV4R80kUNw/LlO6QZ1Q4nYnhMONWPo8Au857CajCor
0UeNc6dJFDwuCyhiDVUrZuV2WkJ86AWPrA187ztQMgBL3hk8kbBTuhyp0AJD
TMuwUK/S3BWBxHxm1V5NC/BjhmDfUalAL5ZpRq6mGBZvMo+MhY0zRsUe9u8N
5ADEBW/liIuAUMSFWZpLYB80+UCNvq+jMjFFYwP8nRJ4pBFzWwNxZYZ1VBih
JTmIRpozW0DkEV2JoOaLLU1EAjTQFrpoEz4TUAGoJOwvqMlvbPi0MwLfj7Jn
OrrdMm8wIqBUgDia0tXA1jrKdjmyGBrk8MktnDm3RsSnUdSjnUwyQ27njohF
Y9gXuwKqlSTyNdbbQLmhD1YKVXZa6AZKZ5sZnD90ImNDoUnFLPsLXU2BJetZ
hMjswodHMtPsdxPfkU0WLKap7fIu8CWCB7E+hdNXeEtcdF2VchmLChNxC38i
0GSWMx/XJDIhQHZqZPAZC1qAdgvg6JTOBxqe3KF+LIGSK2iSXxj+dEFl6owt
U1lRyRqJdyZ1DRIRX+nMeGg31XhXIqi3MmpjPsvcbtyI5iZiFTIBX4C9JoU/
kzmN/TnDerxt6BE1gQ73kDG0ebXEapVeRFM3oAcRNS4koPFNf2G4hQl/MBNq
IGfqC3NrYdcF/CWg0tMOmh4CXzaKQR5MwcorzjDUxcXOEZAJuUwESvZ1XgU6
lKYikWvLQNUCJ7M7kTLjMtYpCV3gkbESWS/mWjMz1MnQLsv9q6UebrDWFNLO
DTN6sI2sAF4/KyIpLJbx9Gi/2MsFbDP3hJIio22gRxEZL9fgL8BanfL4NbVZ
9CeytgR4ICLh9YvNYi+aQFEeyG3rvGWQULXsUM7hs6IXybktImcipsUuHYmI
G5EhsQHMgEdRGbnA0BOX+fCrXJDtIYOE7CtaouV7IfaMHW0hg1wac+RESAvb
2MgO16iZCPYtWYKb0g6yBaIDdXIPu9JoZ7K3RBosx4OtafIcq0P7kpYAs4xs
vgA3cKk19iSRIHZNhorIJntjpVrQ9L0lAB1iMrYZAxLTLeMONr/Y0QQ5AEid
UTaDzlNjFrpz5KMx/GGDzAY9wONMP8eu74DBC1ukvmKA40TgLXSy06o9IKsV
i8hXPdESSKQy60k69REnLBfcWLSrdoE/xBNZDrxhcQNm4PaA3MhjkQF80XSG
DDbjSWYs0iVQCtzAtjkemZ2YwF3diLc24wbMZykvj6ho2fizIPPIJkKfUuRM
BcwjgrVci+oQ3+yHZoxdJDK1O+QOUTF1aYZIZbag19TcAm9c5Ex3DvRAtoWe
gD8afJeqCpXnlR4k8ZqhJfRxj+g3XTG6RuyC28EWIRlCZvAbYK1ETGQfG7/l
GK9S1pnuQ+oUHnWNGLVYVtUZw6FiUXEDIwVTLEOXZY/Q0pcGYyCUWeL7LCyn
lGMMiXEG+K2EOMYekevircy82ogzpgcwdEszwj5wGHqgGfI1Ypo3wFtceMOi
Y84z04Z2JztPugGjFh8MHf7ZUceOCM4UZTZjF3aHAvt9cwlrg0PdadTYAX+w
i76IjBaisoCekKdZtrjXzS0sp+aqmamMM8EWyFnE1MKKD1N4HsgHWABWgO22
YMypTVlX+oZ6LB89YAbNpOl+KfpUqXcBBKL51PDnS13MgT+hSoFQiQWfzaQF
fjdieWwkPpgBvAE2kk3mD9ADuGLNFIEvjBWxPK3Dp5+9CLaRShYV24VhpRRc
U18RxvqnFrWAorB0CexWafwFGFaaesiz3pK2lICS0AMinzHFKaw/hkdyOouC
0aBmSLp4pwk38HnMwuJCB0KBnwjg3JaNyJxS5rORwXq8lX8g009NcDhonCJ/
jZHHJSfsA9DAC4EMM8bjJKVDSnj1AxWsFOhgeVE0V5imQ7APZFW7A/RIgFgm
uWdck2nBRqaF9ee0AxuZLjI7vJllWQ3VSwEHQmzfREshArfcgq9YJhAKcSOy
vIyMIxusm0kobBlvQ5aP5Lkxd1G19S1jjhoZWQVoCYQSu5CpWBi8pMFCXigz
zg1Ny+XU9NVlKINUUsRV7S8Ww1ngi5wiTyEuSnBJa4EZpuB3IuO7jLVDD6rb
UVlkaiRKO8ynZyGHbGLZCrAO+0JsqpShuGgCdznYoreUhL0Nilv59EpGNKgF
0EFdxk+ciXHLjiohp7LKY8E4gwF8MBgXwEgw5rg/tTvClqwoUFLhqYA6QqTf
jfAmMGFdylFVRU1JgWxYPVsgMplesItIDRAXjK2ybCKBCxi0699b0paAITEm
EqBWuTZ4h0f9NEelpVMxu4OeNkqEShSZ5CZQ5gMLcaHZEqy5snQvzLqWycue
0R8vBZ6AMT8zdLCBh9P5QIfXI6+XuSeScimUDwb0Eu01sz91xHSnmn6oiVbf
jFRZDaOSxBFiWdmAtWtgjkwvPqJChs9KiNQSvmSCew6r0yZgOapbqcQu3J6p
D0xPmu30MCPYlQx/WSmiuNYSVVPCjLVFUXEhs0p8BN43Q6wjrmDpa0PHRN3Z
Bmx16oFloda3lTHpwX80VUK0jq2ICrKmmb0t8tw7J4jQyz88Q1RHvv0fOp+I
b67Z+QSdi2fnE3Q/iPQxlcl/hhNF4caY6eCH8BTa1RH7CsdfNyeKYFFkAM80
CGpiO+T2+jxjJ4oSGMV//ERRsUNx/+JE8Q6eAi4iFx7wiUy02F/ZhjxfrFQT
njmmSQSNZcWCR+5guzBdqsTbNSrcArm2P2MHZlLZpZAZtk8WXbCoQ0dcrk/v
jt/ZaV5XD9XBjM46YBOd2dza0nG6Bd/IXKM/t0V/Y8zVnHU7Bn2VEyeaKCou
72faapARY8upCZ0akrieGb0N8j9qq+hhPvyC6pmIdhjls0h8XiROzzTKrc34
T08LfdPgUAWtonu9A6bbde9gB6PWgc9YogCcvMf3xIG8xLAQNaqgCdAhx3QI
358Yug9NLnqk9pWhKojdWcdFai6fzTC6tlcDkXkbEeUu/tRmRpSY88lOl6zt
siOONI7V46ooDxYcX2pxmEMPtgOmbYOFuKYrG5zQ1Tv+vZEIe9NQZTL214bA
q8tksIAfGU40uHOZXuaeqUaETrYKHfSQn9Z3+8EIuX5i6/LW6g7m5nBSTEJe
1gx5w85uZpSWFid28X1gcdF4hlmcjWVseW1YHs4+DufD1Ukqaj3qCeCsVD74
+DN2nSs6JcvIApd3eFaPK/BNX4A2lYNHYXdD1Hao+V3MQK5nRv8wg4ooKSq0
4WXBoATwaHWVMepxZEKBx9Siy/HfdR0RFmZ+ffJ+iJOzKHknUoEsP4nVX41U
xPSLWP23nbHpnbJj82Tigrn4ZCnO9iT07xRKfU13cnDkid6ZbMCr9wYHnxYc
3u3Se8Mg322T9pSR5dzz6goUYqbFUeBCFndChUlOos0ztPXdQs2gCW5fodG9
M3ZXYDIrh1f7CzPTIKsAWeXmtEo8nVYhh6gzGlW+O+NEAkwRrOqcdbIxBJFo
4uYZeqnOrjSDqrPVoDkZI4lB3eEsIs+Mo0aqF4mhwxHnvpM597syMfGm2lGH
rEphs5gS/70+9X5z5n1XnXmzszXEsMiBQe3vuEiBZmca6ld7RIIpdVF9+FPX
9MEmbzvwzAA7UGb85tmKLItIGVHjmxHrYIoC2cu8EaoT1BFbpRuls5XRoyLy
uClfa6OnXO9sU1SDHfypkRHq07koWJJK3D3XnIwhGvvO8P/ByRj3uF9/p+7O
92KzWP/reOaJl8N4tpG9++xmopXq4+XStDb7ay1d5cKU9OxvrdH3a6qVO+mL
Z85X0li1ArLb3cvpZ/LA53eYWutsfnwydjhjOh6R/NIp2a+ecv3KkdnpL8Y2
14Drk7Hq/1CjTJvjqk/VnfVfvJt1umTczPjOhOfz/Se9onXtxjf8ouNXBy34
3Xe6auQkJGNOBWcqluxSSGKZM+Zie2suZwtzUy4TWi5idrgDcjQSdsp+BjBw
etNXBy8oE1NNmvWUiAWTIZV7ZTTQUSAYmh4Jh4OXRVeOFnMCWOOfl+zAZzXZ
KKtJqYwc/Ocaiu5cA8SuldG3lrCejsKNGWCdZJAt4z57K1x2eN82e+WiQ3fV
Ec3/Tyf/xdLJ4tnoqKgQB3e2KXcsgK9vzIJSuudFw45dlIr+2NNFS+sOuguu
ry66qu6Z4ncjAlQL/FCrr7aESBjiLGCphCUSJIIfp5LhzXBGRQG7konBD5Xm
igaRXEI5eUilGxuVxTWjq2RPhjffqzQy/IL15TvEz+Se90vQ05qKmX5uhzcz
o55xqoX4M3QHNruAMfaJskMhLOuCOzSEiDM6T9xiFc1NyV/oCU0dZDI1fMoX
AVLI7iamUSTYkdBZcqoMHY2VhGozzi9Yi0zYe6Y/VHXfMAWeLpJsMh2WD6xB
QOfWw1KUBdbudQwSLnixy4qaxzn3769Oyro6kc7vO1LOGtqhmpv/mW5PrWAo
dnuK3XcU6o4FAicisiLw0pJnoRpy9f3HG1atTPF9oxsAQ55cg60DDEqwCUAV
BW9OsQuCerVHorpWONRYRKBnMhj6pA+OixUHCEK14iPsxpLYdTvu4TZU8wYJ
FC4DFFm2G5O5Ht/YphAlVAfQxnJ1H8szZMWM/NzlXYM5MAFDUY8MBSB2xlgQ
okOX649mhqjP9lYAWBssTQqubXXVOCJOJO+nqIYnGzNyclWaAOjcviXxc2cv
j6FRCTV2YCMpKHFfNoWnvd5FFcNb/HSs7IzEyuDEUxuOxSoCd6gJPjeLSUZC
apuJFaidm54Ga4KPPTQVCpkKANqVLzLQm3ETDn4zQuDJWgcBxc4EvitCdStJ
MHhx4PJyopn+QNPJzDTlnjtW95p4u8NMPTAqzoso+CQ4ZVftW8JmrwgEWkAF
iYpfnU5NfgQmNZuZEeoZS0Yd+HzHWQ8KJxtIQgpJVF+LMg2WDdVu9uDO1TVm
BXfNUF3BRqLWkfcI+owiUObaJnDH0YalrlNi5L+7XSW3E5UlJ6Q3sbB2LMVQ
XVkZHcbNuHep1o4f3y8GYrRJ14+9ztzU7gxz5S1m40TqzK5ve8vV7Wf/WQ8H
3T3vPsARkSRXD+NyrXZm3vb6abTVH20tuPPSuVRMRz3ZnD7N5IenH1KtI7Gq
Scn7zOo1GfoRgfq//kmC2EtgAAA=

-->

</rfc>