<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.23 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-anima-voucher-delegation-01" category="std" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.5.0 -->
  <front>
    <title abbrev="delegated-voucher">Delegated Authority for Bootstrap Voucher Artifacts</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-anima-voucher-delegation-01"/>
    <author initials="M." surname="Richardson" fullname="Michael Richardson">
      <organization>Sandelman Software Works</organization>
      <address>
        <email>mcr+ietf@sandelman.ca</email>
      </address>
    </author>
    <author initials="W." surname="Pan" fullname="Wei Pan">
      <organization>Huawei Technologies</organization>
      <address>
        <email>william.panwei@huawei.com</email>
      </address>
    </author>
    <date year="2021" month="June" day="14"/>
    <area>Internet</area>
    <workgroup>anima Working Group</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>This document describes an extension of the RFC8366 Voucher Artifact
in order to support delegation of signing authority.  The initial voucher
pins a public identity, and that public indentity can then issue additional
vouchers.  This chain of authorization can support permission-less resale
of devices, as well as guarding against business failure of the
BRSKI Manufacturer Authorized Signing Authority (MASA).</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>The <xref target="RFC8366" format="default"/> voucher artifact provides a proof from a manufacturer's
authorizing signing authority (MASA) of the intended owner of a device.  This is
used by an onboarding Pledge device in BRSKI (<xref target="RFC8995" format="default"/>,
<xref target="I-D.ietf-anima-constrained-voucher" format="default"/>), and SZTP (<xref target="RFC8572" format="default"/>).</t>
      <t>There are a number of criticisms of the MASA concept.  They include:</t>
      <ul spacing="normal">
        <li>the MASA must be reachable to the Registar during the onboarding process.</li>
        <li>while the use of a nonceless voucher (see <xref target="RFC8366" format="default"/> section 4) can
permit the MASA to be offline, it still requires the public key/certificate
of the Registrar to be known at issuing time. The device owner is always
strongly dependent on the MASA service.</li>
        <li>the MASA must approve all transfers of ownership, impacting the rights of the supply chain distributors to transfer ownership as they see fit.</li>
        <li>if the Registrar has any nonceless vouchers, then it can not change it's public key, nor can it change which certification authority it uses.</li>
        <li>it is not possible for a MASA to pin ownership to a Registrar by Certification Authority plus DN.</li>
        <li>the creator of an assembly of parts/components can speak for the entire
assembly of parts in a transparent way.</li>
      </ul>
      <section anchor="requirements" numbered="true" toc="default">
        <name>Requirements for the Delegation</name>
        <t>This voucher artifact satisfies the following requirements:</t>
        <section anchor="device-onboarding-with-disconnected-or-offline-masa" numbered="true" toc="default">
          <name>Device Onboarding with Disconnected or Offline MASA</name>
          <t>A Registrar wishes to onboard devices while it is not being connected to the
Internet and MASA.</t>
        </section>
        <section anchor="resale-of-devices" numbered="true" toc="default">
          <name>Resale of Devices</name>
          <t>An owner of a device wishes to resale it which has previously been
onboarded to a third party without specific authorization from the
manufacturer.</t>
        </section>
        <section anchor="crypto-agility-for-registrar" numbered="true" toc="default">
          <name>Crypto-agility for Registrar</name>
          <t>The owner/manager of a registrar wishes to be able to replace its domain
registration key.
Replacing the registration key would invalidate any previously acquired
(nonceless) vouchers.
Any devices which have not been onboarded, or which need to be factory reset,
would not trust a replacement key.</t>
        </section>
        <section anchor="transparent-assemblersvalue-added-resellers" numbered="true" toc="default">
          <name>Transparent Assemblers/Value-Added-Resellers</name>
          <t>An assembly may consist of a number of parts which are onboarded to a local
controller during the manufacturing process.
Subsequent to this, the entire assembly will be shipped to a customer who
wishes to onboard all the components.
The sub-components of the assembly needs to communicate with other
sub-components, and so all the parts need to transparently onboarded.
(This is contrasted with an assembly where the controller acts as a security
gateway. Such a gateway might be a single point of failure)</t>
          <t>Assemblies may nest quite deeply.</t>
        </section>
      </section>
      <section anchor="overview-of-proposed-solution" numbered="true" toc="default">
        <name>Overview of Proposed Solution</name>
        <t>The MASA will issue a voucher that delegates it's signing authority for one
or more devices to a specific Registrar.
This is called a "delegation voucher".</t>
        <t>This Registrar can then operate as an authorized signing authority for the
manufacturer, and can subsequently issue additional vouchers binding the
pledge to new Registrars.</t>
        <t>This delegation can potentially be repeated multiple times to enable second,
third, or n-th level of resale.</t>
        <t>The delegation voucher may be stored by the pledge for storage, to be
included by the pledge in subsequent bootstrap operations.
The inclusion of the delegation voucher permits next Registrar with heuristics that
permit it to find the delegated authorized signing authority (DASA).</t>
        <t>The delegation voucher pins the identity of the delegated authority using a
variety of different mechanisms which are covered in <xref target="pinnedmechanism" format="default"/>.</t>
      </section>
    </section>
    <section anchor="terminology" numbered="true" toc="default">
      <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&nbsp;14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> when, and only when, they
appear in all capitals, as shown here.</t>
      <dl newline="false" spacing="normal">
        <dt>Delegated Authorized Signing Authority :</dt>
        <dd>
  the Delegated Authorized Signing Authority (DASA) is a service that can
generate vouchers for one or more pledges to provide bootstrap authority,
which is separated and delegated from the manufacturer.</dd>
        <dt>Delegation Voucher:</dt>
        <dd>
  a Delegation Voucher is an <xref target="RFC8366" format="default"/> format voucher that has additional
fields to provide details of the entity to which authority has been delegated.</dd>
        <dt>Intermediate Voucher:</dt>
        <dd>
  a voucher that is not the final voucher linking a pledge to its owner.</dd>
        <dt>End Voucher:</dt>
        <dd>
  a voucher that is the final voucher linking a pledge to its owner.</dd>
      </dl>
    </section>
    <section anchor="delegation-voucher-artifact" numbered="true" toc="default">
      <name>Delegation Voucher Artifact</name>
      <t>The following tree diagram shows the extensions to the <xref target="RFC8366" format="default"/> voucher.</t>
      <t>There are a few new fields:</t>
      <dl newline="false" spacing="normal">
        <dt>delegation-enable-flag:</dt>
        <dd>
  A global enable flag to the pledge that it can be delegated (true) or not (false). With default, this flag is false, which is consistent with the voucher artifact in RFC8366.</dd>
        <dt>pinned-delegation-cert-authority:</dt>
        <dd>
  An subject-public-key-info for a public key of the new DASA</dd>
        <dt>pinned-delegation-cert-name:</dt>
        <dd>
  A string for the rfc822Name SubjectAltName contents of the new DASA; (XXX- is it enough, should other DNs be considered?)</dd>
        <dt>delegation-voucher:</dt>
        <dd>
  One or a series of Intermediate Vouchers that delegate authority to the DASA. For the latter case, the series of Intermediate Vouchers constitute a nested structure, and the most inner voucher is from the MASA, which is called terminal voucher here</dd>
        <dt>intermediate-identities:</dt>
        <dd>
  A set of voucher identities being consistent with the series of Intermediate Vouchers</dd>
        <dt>delegation-countdown:</dt>
        <dd>
  Number of delegations still available. If zero or omitted, then this is a terminal voucher and may not be further delegated.</dd>
      </dl>
      <t>In addition, the serial-number field is no longer a plain leaf, but can also be an array (See <xref target="delegationmultidev" format="default"/>).</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
module: ietf-voucher-delegated

  grouping voucher-delegated-grouping
    +-- voucher
       +-- created-on                          yang:date-and-time
       +-- expires-on?                         yang:date-and-time
       +-- assertion                           enumeration
       +-- serial-number                       string
       +-- idevid-issuer?                      binary
       +-- pinned-domain-cert?                 binary
       +-- domain-cert-revocation-checks?      boolean
       +-- nonce?                              binary
       +-- last-renewal-date?                  yang:date-and-time
       +-- delegation-enable-flag?             boolean
       +-- pinned-delegation-cert-authority?   binary
       +-- pinned-delegation-cert-name?        binary
       +-- delegation-voucher?                 binary
       +-- intermediate-identities?            binary
       +-- delegation-countdown?               int16
]]></artwork>
      <section anchor="yang-module" numbered="true" toc="default">
        <name>YANG Module</name>
        <t>This module uses the grouping that was created in <xref target="RFC8366" format="default"/> to extend the
definition.</t>
        <sourcecode name="ietf-voucher-delegated@2020-01-06.yang" type="" markers="true"><![CDATA[
module ietf-voucher-delegated {
  yang-version 1.1;

  namespace
    "urn:ietf:params:xml:ns:yang:ietf-voucher-delegated";
  prefix "delegated";

  import ietf-restconf {
    prefix rc;
    description
      "This import statement is only present to access
       the yang-data extension defined in RFC 8040.";
    reference "RFC 8040: RESTCONF Protocol";
  }

  // maybe should import from constrained-voucher instead!
  import ietf-voucher {
    prefix "v";
  }

  organization
   "IETF ANIMA Working Group";

  contact
   "WG Web:   <http://tools.ietf.org/wg/anima/>
    WG List:  <mailto:anima@ietf.org>
    Author:   Michael Richardson
              <mailto:mcr+ietf@sandelman.ca>";

  description
  "This module extends the RFC8366 voucher format to provide
   a mechanism by which the authority to issue additional vouchers
   may be delegated to another entity

   The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
   'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY',
   and 'OPTIONAL' in the module text are to be interpreted as
   described in BCP 14 RFC 2119, and RFC8174.";

  revision "2020-01-06" {
    description
     "Initial version";
    reference
     "RFC XXXX: Voucher Profile for Delegation Vouchers";
  }

  rc:yang-data voucher-delegated-artifact {
    // YANG data template for a voucher.
    uses voucher-delegated-grouping;
  }

  // Grouping defined for future usage
  grouping voucher-delegated-grouping {
    description
      "Grouping to allow reuse/extensions in future work.";

    uses v:voucher-artifact-grouping {

      refine voucher/pinned-domain-cert {
          mandatory  false;
      }

      augment "voucher" {
        description "Base the delegated voucher
                     upon the regular one";

        leaf delegation-enable-flag {
          type boolean;
          description
            "A global enable flag to the pledge that it can be
             delegated (true) or not (false). With default,
             this flag is false, which is consistent with
             the voucher artifact in RFC8366. ";
        }

        leaf pinned-delegation-cert-authority {
          type binary;
          description
            "An subject-public-key-info for a public key of the
             certificate authority that is to be trusted to issue
             a delegation voucher to the Registrar.
             This is not used by end-vouchers, and only valid
             when delegation-enable-flag is true.";
        }

        leaf pinned-delegation-cert-name {
          type binary;
          description
            "A string for the rfc822Name SubjectAltName contents
             which will be trusted to issue delegation vouchers.
             This is not used by end-vouchers, and only valid
             when delegation-enable-flag is true.";
        }

        leaf delegation-voucher {
          type binary;
          description
            "The intermediate voucher that delegates
             authority to the entity that signs this voucher
             is to be included here, and only valid
             when delegation-enable-flag is true.";
        }

        leaf intermediate-identities {
          type binary;
          description
            "A set of identities that will be needed to
             validate the chain of vouchers, and only valid
             when delegation-enable-flag is true. MAY BE REDUNDANT";
        }

        leaf delegation-countdown {
          type int16;
          description
          "Number of delegations still available, and only valid
             when delegation-enable-flag is true. If zero
           or omitted, then this is a terminal voucher and
           may not be further delegated";
        }
      }
    }
  }
}
]]></sourcecode>
      </section>
      <section anchor="bundling-of-the-vouchers" numbered="true" toc="default">
        <name>Bundling of The Vouchers</name>
        <t><xref target="RFC8995" format="default"/> defines a mechanism to return a single voucher to the pledge.</t>
        <t>This protocol requires a number of additional items to be returned to the
pledge for evaluation:  the series of Intermediate Vouchers that leads to the
DASA, and the public keys (often as certificates) of the Registrars on the
Delegation Path that leads to each Authority.</t>
      </section>
      <section anchor="delegationmultidev" numbered="true" toc="default">
        <name>Delegation of Multiple Devices</name>
        <t>A MASA MAY delegate multiple devices to the same Registrar by putting an
array of items in the "serial-number" attributes. (XXX-how to describe this
in the YANG, and the detailed mechanism, are TBD)</t>
      </section>
    </section>
    <section anchor="enhanced-pledge-behavior" numbered="true" toc="default">
      <name>Enhanced Pledge Behavior</name>
      <t>The use of a Delegation Voucher requires changes to how the pledge evaluates
the voucher that is returned to by the Registrar.</t>
      <t>There are no significant changes to the voucher-request that is made.
The pledge continues to pin the identity of the Registrar to which it is
connected, providing a nonce to establish freshness.</t>
      <t>A pledge which has previously stored a Delegation Voucher and DASA
, SHOULD include it in its voucher request.
This will be in the form of a certificate provided by the "previous" owner.
This allows the Registrar to discover the previous authority for the pledge.
As the pledge has no idea if it connecting to an entity that it previously
has connected to, it needs to include this certificate anyway.</t>
      <t>The pledge receives a voucher from the Registrar.
This voucher is called the zero voucher.
It will observe that the voucher is not signed with its built-in manufacturer
trust anchor and it can not verify it.</t>
      <t>The pledge will examine the voucher to look for the "delegation-voucher"
and the "intermediate-identities" attributes within the voucher.
A certificate from the set of intermediate-identities is expected to validate
the signature on this zeroth end-entity voucher.
(XXX- This attribute can be replaced by the CMS certificate chain)</t>
      <t>The contained delegation-voucher object is to be interpreted as an
(Intermediate) Voucher.
This first voucher is called the first voucher, or "voucher[1]".
Generically, for voucher[i], the voucher found in the delegation-voucher is
called voucher[i+1].</t>
      <t>If voucher[i] can be validated by a built-in trust anchor, then the process
is done.
If not, then voucher[i] is examined in a recursive process until there are
no further embedded vouchers.
The last voucher[n] is expected to be validated by a built-in manufacturer
trust anchor.</t>
      <t>Once the top (n-th) voucher is found, then the pinned-certificate-authority
is added to the working set of trust anchors.
The "pinned-certificate-name" attribute is used along with the trust anchor to
validate the certificate chain provided with the (n-1)th voucher.
This is repeated (unwinding the recursive processing) until the zeroth
voucher has been validated.</t>
    </section>
    <section anchor="changes-to-registrar-behavior" numbered="true" toc="default">
      <name>Changes to Registrar Behavior</name>
      <t>The Registrar is the component that authenticates the pledge, makes authorization decisions, and distributes vouchers. If the vouchers is delegated, then the registrar need to co-ordinate MASA and DASA.</t>
      <section anchor="discovering-the-most-recent-delegated-authority-to-use" numbered="true" toc="default">
        <name>Discovering The Most Recent Delegated Authority to Use</name>
        <t>The pledge continues to use its manufacturer issued IDevID when performing
BRSKI-style onboarding.
The IDevID contains an extension, the MASA URL (see
<xref target="RFC8995" format="default"/> section 2.3.2).
The IDevID certificate is not expected to be updated when the device is
resold, nor may it be practical for an intermediate owner to be able
to replace the IDevID with their own.
(Some devices may support having an intermediate owner replace the IDevID, in
which case this section does not apply)</t>
        <t>The Registrar needs to be informed that it should not contact a MASA using
the URL in the IDevID, but rather to contact the previous owner's DASA.</t>
        <t>This can be accomplished by local override, as described in
<xref target="RFC8995" format="default"/> section 5.4:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
Registrars MAY include a mechanism to override
the MASA URL on a manufacturer-by-manufacturer basis, and within that
override it is appropriate to provide alternate anchors.  This will
typically used by some vendors to establish explicit (or private)
trust anchors for validating their MASA that is part of a sales
channel integration.
]]></artwork>
        <t>The above override needs to be established on a per-device basis.
It requires per-device configuration which is very much non-autonomic.</t>
        <t>There are two other alternatives:</t>
        <ol spacing="normal" type="1"><li>The Manufacturer could be aware of any Delegation Vouchers that it has
issued for a particular device, and when contacted by the Registrar, it
could redirect the Registrar to its DASA. And the DASA may redirect the
Registrar to its delegated DASA, this process is recursive to the final DASA.</li>
          <li>The Pledge could provide a signed statement from the manufacturer
providing the Registrar with a pointer to the DASA.</li>
        </ol>
        <t>Option 1 requires that the Registrar still contact the MASA, violating most
of the goals from <xref target="requirements" format="default"/>.</t>
        <t>Option 2 requires a signed artifact, and conveniently, the Delegation Voucher
is exactly the item needed.
The most difficult problem is that the Pledge needs to (a) store one or more
Delegation Vouchers in a non-volatile storage that survives factory reset
operations, (b) attach these items to the pledge's voucher-request.</t>
        <t>The extension to the <xref target="RFC8995" format="default"/>
voucher-request described below provides for a contained for these Delegation Vouchers.</t>
      </section>
    </section>
    <section anchor="applying-the-delegation-voucher-to-requirements" numbered="true" toc="default">
      <name>Applying The Delegation Voucher to Requirements</name>
      <section anchor="case-1-resale" numbered="true" toc="default">
        <name>Case 1: Resale</name>
        <t>This case has many application scenarios.</t>
        <t>The simplest is that a device, previously owned by one entity is sold to another entity.
This would include many large home appliances (furnace, stove, refriderator) which are either sold with the home (because they are attached), or for which there is a frequent resale market.
Entire systems (HVAC, physical security, elevators) in commercial buildings also fall into this category.
Many of these devices exist for decades.</t>
        <t>The initial onboarder would obtain a delegated voucher, and would keep this voucher safe.
Should the device need to be resold, this voucher is provided to the new owner.
This protects the first owner from situations where the manufacturer is unwilling, or goes into bankruptcy.</t>
        <t>A creditor, such as a bank, which may take the property, including required systems as collatoral for a loan could require that a delegated voucher be obtained.
A bank would find a building that needed new systems installed difficult to resale should the bank have to foreclose.
It is likely that this requirement would make devices which do not come with delegated vouchers significant liabilities, and that financial institutions (banks, insurance companies) might refuse to lend in this case.</t>
        <t>As a different example,  an owner might initially start with some hosted Registrar (in the cloud perhaps, as a service).  Later on, the owner wishes to bring the Registrar in-house (or just change who is providing the Registrar service).
Such an activity is effectively a "resale".</t>
        <t>It is common when a company goes bankrupt that many of it's assets (routers, switches, desktops, as well as furniture) are sold by the court.
There are many resellers of digital equipment, and they typically take the devices, factory reset them, verify that they work, and then list them for resale.
Such an entity would want to have a delegated voucher for each device.
Whether the delegated voucher would be obtained from the original (bankrupt) company, by the court, or directly from the manufacturer is probably a legal problem.</t>
        <t>Further, the pledges may be resaled many times, and when onboarding, they will receive all vouchers in order with the sale chain, firstly masa vouchour, then 1st intermidate, 2nd intermidate, till to the final dealer. In this case, the pledge's authorization form a signed voucher chain.</t>
        <t>The following illustrates a delegation voucher for a pledge:
   {
     "ietf-voucher-delegated:voucher": {
       "created-on": "2020-07-14T06:28:31Z",
       "expire-on": "2022-07-31T01:61:80Z",
       "assertion": "logged",
       "serial-number": "JADA123456789",
       "delegation-enable-flag": true,
       "pinned-delegation-cert-authority": "base64encodedvalue",
       "pinned-delegation-cert-name": "base64encodedvalue",
       "delegation-voucher": "base64encodedvalue",
       "intermediate-identities": "intermediateId1",
       "delegation-enable-flag": 1,
     }
   }</t>
      </section>
      <section anchor="case-2-assembly" numbered="true" toc="default">
        <name>Case 2: Assembly</name>
        <t>In some application, many pledges which come from multiple component assembled by a system integrated.
They need to to be assembled together in the first sale.
In this time, the owner is assembly controller, so the pledge's voucher need to include these  delegation options.</t>
        <t>In addition, there are also transparent assembly, for example rail wagon scenario.
Firstly, the assembly onboards normally to get all pledges' vouchers, then this assembly acts as intermidate registrar, who "sell" these pledges to every rail wagon registrar.</t>
      </section>
    </section>
    <section anchor="pinnedmechanism" numbered="true" toc="default">
      <name>Constraints on Pinning The Delegated Authority</name>
      <t>TBD</t>
    </section>
    <section anchor="privacy-considerations" numbered="true" toc="default">
      <name>Privacy Considerations</name>
      <t>YYY</t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <section anchor="delegation-vouchers-do-not-expire" numbered="true" toc="default">
        <name>Delegation Vouchers do not expire</name>
        <t>A significant feature of the <xref target="RFC8366" format="default"/> voucher is that it can be short-lived, and often renewed if needed.
This goes along with the arguments that renewal is better than revocation explained better in <xref target="RFC8739" format="default"/>.
However, in order for a delegated voucher to be useful it has to have a life longer than the pessimistic expected life of the manufacturer (MASA).
This argues for the expiry time of a voucher to be rather long (decades), if not actually infinite.</t>
        <t><xref target="RFC8995" format="default"/> makes arguments for why a Pledge dos not need to have a clock that it can trust, because it can use a nonce to verify freshness of the resulting Voucher.
The Delegated Voucher can not use a nonce to verify the chain of delegated vouchers presented, although it can use a nonce for the last (non-delegated) voucher.</t>
      </section>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document requires the following IANA actions:</t>
      <section anchor="the-ietf-xml-registry" numbered="true" toc="default">
        <name>The IETF XML Registry</name>
        <t>This document registers a URI in the "IETF XML Registry" <xref target="RFC3688" format="default"/>.
IANA is asked to register the following:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
     URI: urn:ietf:params:xml:ns:yang:ietf-voucher-delegated
     Registrant Contact: The ANIMA WG of the IETF.
     XML: N/A, the requested URI is an XML namespace.
]]></artwork>
      </section>
      <section anchor="yang-module-names-registry" numbered="true" toc="default">
        <name>YANG Module Names Registry</name>
        <t>This document registers a YANG module in the "YANG Module Names" registry <xref target="RFC6020" format="default"/>.
IANA is asked to register the following:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
     name:         ietf-voucher-delegated
     namespace:    urn:ietf:params:xml:ns:yang:ietf-voucher-delegated
     prefix:       NONE
     reference:    THIS DOCUMENT
]]></artwork>
      </section>
    </section>
    <section anchor="acknowledgements" numbered="true" toc="default">
      <name>Acknowledgements</name>
      <t>Hello.</t>
    </section>
    <section anchor="changelog" numbered="true" toc="default">
      <name>Changelog</name>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization/>
            </author>
            <date year="2017" month="May"/>
            <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>
        <reference anchor="RFC8366" target="https://www.rfc-editor.org/info/rfc8366">
          <front>
            <title>A Voucher Artifact for Bootstrapping Protocols</title>
            <author initials="K." surname="Watsen" fullname="K. Watsen">
              <organization/>
            </author>
            <author initials="M." surname="Richardson" fullname="M. Richardson">
              <organization/>
            </author>
            <author initials="M." surname="Pritikin" fullname="M. Pritikin">
              <organization/>
            </author>
            <author initials="T." surname="Eckert" fullname="T. Eckert">
              <organization/>
            </author>
            <date year="2018" month="May"/>
            <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="RFC8995" target="https://www.rfc-editor.org/info/rfc8995">
          <front>
            <title>Bootstrapping Remote Secure Key Infrastructure (BRSKI)</title>
            <author initials="M." surname="Pritikin" fullname="M. Pritikin">
              <organization/>
            </author>
            <author initials="M." surname="Richardson" fullname="M. Richardson">
              <organization/>
            </author>
            <author initials="T." surname="Eckert" fullname="T. Eckert">
              <organization/>
            </author>
            <author initials="M." surname="Behringer" fullname="M. Behringer">
              <organization/>
            </author>
            <author initials="K." surname="Watsen" fullname="K. Watsen">
              <organization/>
            </author>
            <date year="2021" month="May"/>
            <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-constrained-voucher" target="https://www.ietf.org/archive/id/draft-ietf-anima-constrained-voucher-10.txt">
          <front>
            <title>Constrained Voucher Artifacts for Bootstrapping Protocols</title>
            <author fullname="Michael Richardson">
              <organization>Sandelman Software Works</organization>
            </author>
            <author fullname="Peter van der Stok">
              <organization>vanderstok consultancy</organization>
            </author>
            <author fullname="Panos Kampanakis">
              <organization>Cisco Systems</organization>
            </author>
            <author fullname="Esko Dijk">
              <organization>IoTconsultancy.nl</organization>
            </author>
            <date month="February" day="21" year="2021"/>
            <abstract>
              <t>   This document defines a protocol to securely assign a Pledge to an
   owner and to enroll it into the owner's network.  The protocol uses
   an artifact that is signed by the Pledge's manufacturer.  This
   artifact is known as a "voucher".

   This document builds upon the work in [RFC8366] and [BRSKI], but
   defines an encoding of the voucher in CBOR rather than JSON, and
   enables the Pledge to perform its transactions using CoAP rather than
   HTTPS.

   The use of Raw Public Keys instead of X.509 certificates for security
   operations is also explained.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-anima-constrained-voucher-10"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization/>
            </author>
            <date year="1997" month="March"/>
            <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>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="RFC3688" target="https://www.rfc-editor.org/info/rfc3688">
          <front>
            <title>The IETF XML Registry</title>
            <author initials="M." surname="Mealling" fullname="M. Mealling">
              <organization/>
            </author>
            <date year="2004" month="January"/>
            <abstract>
              <t>This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="81"/>
          <seriesInfo name="RFC" value="3688"/>
          <seriesInfo name="DOI" value="10.17487/RFC3688"/>
        </reference>
        <reference anchor="RFC8572" target="https://www.rfc-editor.org/info/rfc8572">
          <front>
            <title>Secure Zero Touch Provisioning (SZTP)</title>
            <author initials="K." surname="Watsen" fullname="K. Watsen">
              <organization/>
            </author>
            <author initials="I." surname="Farrer" fullname="I. Farrer">
              <organization/>
            </author>
            <author initials="M." surname="Abrahamsson" fullname="M. Abrahamsson">
              <organization/>
            </author>
            <date year="2019" month="April"/>
            <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="RFC8040" target="https://www.rfc-editor.org/info/rfc8040">
          <front>
            <title>RESTCONF Protocol</title>
            <author initials="A." surname="Bierman" fullname="A. Bierman">
              <organization/>
            </author>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
              <organization/>
            </author>
            <author initials="K." surname="Watsen" fullname="K. Watsen">
              <organization/>
            </author>
            <date year="2017" month="January"/>
            <abstract>
              <t>This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8040"/>
          <seriesInfo name="DOI" value="10.17487/RFC8040"/>
        </reference>
        <reference anchor="RFC6020" target="https://www.rfc-editor.org/info/rfc6020">
          <front>
            <title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund" role="editor">
              <organization/>
            </author>
            <date year="2010" month="October"/>
            <abstract>
              <t>YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6020"/>
          <seriesInfo name="DOI" value="10.17487/RFC6020"/>
        </reference>
        <reference anchor="RFC8739" target="https://www.rfc-editor.org/info/rfc8739">
          <front>
            <title>Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME)</title>
            <author initials="Y." surname="Sheffer" fullname="Y. Sheffer">
              <organization/>
            </author>
            <author initials="D." surname="Lopez" fullname="D. Lopez">
              <organization/>
            </author>
            <author initials="O." surname="Gonzalez de Dios" fullname="O. Gonzalez de Dios">
              <organization/>
            </author>
            <author initials="A." surname="Pastor Perales" fullname="A. Pastor Perales">
              <organization/>
            </author>
            <author initials="T." surname="Fossati" fullname="T. Fossati">
              <organization/>
            </author>
            <date year="2020" month="March"/>
            <abstract>
              <t>Public key certificates need to be revoked when they are compromised, that is, when the associated private key is exposed to an unauthorized entity.  However, the revocation process is often unreliable. An alternative to revocation is issuing a sequence of certificates, each with a short validity period, and terminating the sequence upon compromise.  This memo proposes an Automated Certificate Management Environment (ACME) extension to enable the issuance of Short-Term, Automatically Renewed (STAR) X.509 certificates.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8739"/>
          <seriesInfo name="DOI" value="10.17487/RFC8739"/>
        </reference>
      </references>
    </references>
    <section anchor="extra-references" numbered="true" toc="default">
      <name>Extra references</name>
      <t>RFC Editor, please remove this section.
This section lists references in the YANG. <xref target="RFC8174" format="default"/>, <xref target="RFC8040" format="default"/>.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAG6Ox2AAA51c63IbR3b+P0/RgX4IyAIwScmyhPxYQyJlMRFJhaQs2+st
V2OmAfRyMI1Mz4CCWUrtgyRVeZY8yj5JzqVvA0CWHVXZAjB9OX2u3zl9RqPR
KGt0U6qJOFWlWshGFWLaNktT62Yr5qYWL41pbFPLtfjetPlS1WJaN3ou88Zm
cjar1WYiCj93tOExWWHySq5g2aKW82akVTMfyUqvpB8xcnO0qUZHx1lmG1kV
v8jSVDCpqVuVZXpd00fbnBwdvTg6yWSt5EScV42qK9Vk94uJoDXFB1Pf6Woh
vqtNu87u7uOg0Snun+WymQjbFFm21hMBfx6JXFaitUrIupZb0ddzIctSbJUd
CDj1UtqlADJVJkRj8gk+gI/W1E2t5nZCSxRqLtuysTDCP9+u+DF+zSQxcpJl
I6Er+PFiLK51vpR1YU0Fo5lDF/iTKruPTA2HuwGWqHIFhN6YeXMPx6eT4kZq
JXU5Eau8/hPy9lvrh45z6bf7MBbvZNzng9LuOy3+ppX38MutypeVKc1Cq2Td
e12WWq7Ga1nBoG+XNHacm1WWVaZegdg2agLDr1+/en78zVP/8cmzZ/7jixdf
T8TL65t/O4cfzken40QFclOhRukqKgwwSVfznaWfPHv+3K/39Tcn/uPR0yP3
8dnRyRGydzQScoZL5k2W3S61FaB/7UpVDcjI5rWeKQuqItTHRlUWVE6YuWiW
yhO9p9pADHCpgF9AtLZdr0HuImosTrd6UaHOSW8tYyFuYUld6UbLUnhLWIMs
hBTrdlbqXOgCiILBQyCnABJkE55U7hFpJhBXCW1tCwpaFBo3lWXm1rS0FZwS
FEYTMY6IX5k6XMATvVb1CtZBMyuVtaJWVpYqgzmF2uhcWaDEinsFug9/L1rQ
QDrVAla2jZi1FsQE8+agFy0oIDMuI8mKC1m1yC54UHu38St4kBvHm+hJ+hfT
m+lgzLJa6aIAGrJHaKa1KdocyUbJKfHw4GTy6ZNnIZgoS0Wsa7MBDhI/awOk
zGuzgi+rhI7HNvPcQBL2xORI8RqgwVEA5wth7ivYCnnpOOOZrG0GfqIQsy2q
kKlmxvHoXamKhXKjYSFWd9F/eBjRp0+fhtnDw5d1/9OnAavDzU+373C603f4
fUxMqdFLwX+ialczJhJ0utG5tivrD4KnErB6rtYNq+IWaMrLtgBzyv45jlm1
KFcFmiBBf2alQh0nY1ALDW64FkVb4/nwt+S4wHFQFzvGxe6XGufBAHShxLQK
tyYV82LrW9WVp1UkaPF0gCoKJkzK2UTSgJAZLjcvgT9DAY9sA54ISP2PVoPm
0khnL3dq+1WuUDM0eHf0096m6Ri1rN1ydxWIVoChoTnRufQKhIvK5kTHogdR
y/JebsmPg1pWi3ILI9aKDBM4Eem0qiYN2eerXKOOKoolQENl52CuSBntYZd6
DcdarUFXPYdrvVg2QYpotrAtG3aB59CztjE1xRi/YFwMbbZBSSOr57ohivQu
HyCYgX5t90UExs+OpiGfUZkGd65AqXXz2CacHsKzmsboMAR0IF+KKAKUbLQy
GAeqwdqikfe0+tqAK0KVQ2Qhg9DX6MXCmeAHmVAPdveqs0n0KuuyteL0Msgh
B50GZpFCAjHWqtUMuAlf1+BD7FcQwNYAMCrgN/nItZJ3RApORu9L8X5vHtq2
ZO7Dd1QGUBPY9NEjIJM0c0Vr+pVOY6B4eFQnIz656LTn2CyMtnPtNHxuytLc
o4Kkkye44SNYnHT2KhrmvW6W4lRbMP4KLAx9WS2u2IiIxVk2Tfh5r+1SkT45
4/aRwFl1lNZM4fJxWfYTmcdW5LNw/TFTdk2hBbnGNAICmlb7fjUhgIMR7sjK
hIq6BkSpTWuB/zOlqswRyduDFJYaKEaxbOngpm1Qjjmqx04YpOCABKfhwdH6
qt6uGzOSC116oBs4xIGI6P4KpsqFp78+wENwMN6H1mpdSowEDeIPAFJV5mcQ
PWBH4+yaBgXj33ku7k1bFqBvG1nqAtwa2W3CEpmTQhRZPxjzIFjzGPi9TaVJ
LAVvxMJUIXqpYog6wiMqxbyFkyCTTL1FuahmmDExOJlQOHGAjkjIio5DzLxN
LGPKxgPUfPW9LFs1mhaw3Qh0AyAG/Eo6ESxsBdAbIyIwwUWREOHY8phEjH47
elCaHAARzAVPjQunQSvKuxO3btqZBXtCKkmTNbs/Z/iRKAS/yA10Rmu/Xw4M
MCuFTDPZvgmRv0cPFDzMmLTItrNR4nWclw9bIe9pHRizaiuKZGzPpkHw2J3O
KMGasBvzyAswcVDovDy/xlnf4RhB7JIWbZk2SZ3kPeEMPkNgKmZ5GGMkxu4W
fW6GeR66P3HTomSE+w6gDuIYmQNgLoidQJ3RFYnVYccByJ53Q0eHogdk2QhQ
6AZDMaiWc6pXG4yv6h7nvqsNBA3ElKZsI0ykyEGCciA5+FTC1D4htRzI9kEg
GjwwNYO/VqZWwWhI1sGfBJcwzgILgfdAjRS9JB1we/fGzr9HZxuwvAGsQ/ZM
iYiMWPkwbbtui0XPwN5rMQhtN0MIrkDMIJ9w9pCtGajC2SpgaiDOenKTk+AO
a9OgScBBt4wTIUyiyqwg19Vr9HUAoIhVqiLfB7phqmKYkW8mz1KNQLtKtYG0
FmTIbp6xrNhnG6kC2hv4HsbZpNtMNDIDH4AXHrKXyhyq3R2pU96IWShbMOdh
P2eSND1NAg9QxMAUTetj0wmdDVYFwBAAl+aWdC1zIFaTV5lrSutULIn8tqz7
py4v+gxrKHukPMVnh12i4/rwCHM1WDzbyBoyDhpa6DkARmTISiFuo4whOtUc
sCryHHj38AB7QVYSxn36hNYobvF4VCHYMpUcpmrwW72L9ze3vSH/LS6v6PP1
2b+/P78+O8XPN2+mb9+GD5kbcfPm6v3b0/gpznx1dXFxdnnKk+FX0fkp611M
f+yxJfSu3t2eX11O3/aQ9qaT8uPBOJ5hcldD9CQ22czXAui8L1+9+9//OX4K
5/4nyFBOjo9fQIbCX7CkAV/AI1a8m6nYQVYUMLYZoHwF6oCwEDxQLte6kSVn
0naJ2Qb6UuBetldUO5wdT7JJChy/NJyVhhIWn4qw28OsaqEq9jTBFThfJ7yv
Y3shA3YJdWItQZsg/JOawC5WQVRhXauKRPM8wBI7ACvBv9/78s4EaN3/nc5Q
dZJELgJ13TklMLEMAkC5LDr0F6qBGBPiqzMVGOBUPbAOVyIkFE4B9BKgXalC
I9s6FHeocKiYELpOnK0AoE3lRymip0XvQRAS1j8Drv3msn98yUeHmBmqV2Sn
MYtoasgO4XSLWq5IQXnHUA2zvgJwoPiyU4GYQwDBIMIigJQkKeNyNBjNS7nA
Y07FojQzOJOLEvi738gfis7Pyecs9Wl9rABTIRY53p+DdanBWHxA/+uqrkO2
eloV/8YhQxF01qFKStZwFu66l3aBAbsDj7EyjO4vrUtjbjsKukNnohjzN0iH
Rpwcj8AbjrBy6TLamDJ7XURunVIS9pkNqDpL/MJsH8Tl08h6nj8/ObmEx4C1
aNNp2dBXRGgpnvR7/Ivo//DDDyM8P3BVVaZdLIcoccTxhCghW0YDYPYU6Pv/
POgIcRP19Ip9BvkYRGyw2SFLsV3IlRibEzZSNhav3alK2cAaIHIUF5U8vrA6
Vcx00zZUAVOEXoFTLbkbX0cFH2QsChSTzU10LsFFIWBM1YNhXEPBLbE7Kvln
OiFk5CIv0OikpAjUhk3C45gv72neF87YkUBu2qopwNBxu8uQD8UR1lXF5AZ8
HprWWJzPxa+qNiguA2CkwQSPYGfjYKvcPyoyjkA4JYdi3takIF3HGNxulJUs
Ry5LIyfAbhHysQrzZPRXWLoqlZwPxaxl2wbb5Ey58tctN1QajGcibAkgnGue
55c3Z9e3v7w+/+6X19dXF/Dh7ZmgIurO7RGYEzq3cQMwDVACZQ8/Ti+/Exem
aLHETPh2RV+oHkWnWOA1EYNjibUcy4Ujj4OiD0SIi06SNAxkNKfivqn+GInf
nk5vz8ZbCRt6Gl+2VVEiBSBY9NVREWLxWNB+VOwOmIzLDKD4VUyzQjBJXauH
9hAgG5ObpISa5thJ4gA52MoXNHiHWPBJoLjaQFJPEpuI32W9xGLQhsIHmeyU
LNGbbXSYVvTNHJiNKCop7NrBXmHXumJsCjTeSTK1dDOsb0fUxKllMgNWvfAZ
jStYiYdHB1QSy2eUbwL8jG4uZENJ6kgMQQfdqV6u24aqvQDOWPthZ2a35ppy
r2NWPQEeksq+yo7ZoUPIxuU9fiWrztxkVPfITgZCmKx5lRlS5L59eTpA1HBW
wa85PHeXFy/VUm60cTWvUMw/AC6CAnH5l85LdMVw7pRD2SyNth7kpFrlMrck
v05QBngTSpRQ/lWT7pcsO0J6sHzgl1/JQnGC56jBIKmr1gFdx63dNKpzWeCi
Ay6Xharn0IFMRmNUdSPlsg24Xm2XEGKUXVZ8MzL1mx+sZ7oE9yB7UYAEE4bC
ZUUuzSV6KgJ/m0QUsL8rSvhylTsh4mcWYmJEHiiHnLnnyep5SElrSYSMdp8z
BVaXN4ojuJ+6X7IIzmdqU71ANoBQYX+JlxMI+Ji75IMN3cw6xO4AYWRahpPT
EjRdC4W6mWcSxbn0wLLacpE+0Yha5UpvyAd6VgZ8sFvqSTCExwowioJsQMbn
DTPfzDALc3A2VX2XMaA2+5IbynHW6rIB1NjJmzJXY63ypWF1SG5lgPV6jpcq
3QPR7uqjXGGlv2NzGJBNvNvo7SO8XuZ9Ru8zcCd1RES807Bw/mmH44GVDiB9
ZlVkivq4DjcKvtJNPgM5JRu6Z3bYBTkObIMYPHI6ErZnrMt66wn1qYQrVAd9
f3Vx0yGWLtgGzEx0FHQhK/a5BLJF4E1J2oGSAvr0fhr4Bt6gnRrNdW2bzyhT
5xmVzXruy89/Of75r71x9h3m8hqnbIcky/Bc//zXYUfic0CNhfcBB86BLo23
jmv8CXZBKDPvrOtZ6AXDN99RaVM9DShT+TJ7RpWYCnwALAuq60Z0NiANIKUt
+GqtxuKyBdP0qwiAwJpq3BwTMnAfHqAqCJJ4p5Bce9xSXhGZ+fNfKr9NVLTf
ONJn7RC4c0UOf4lOfy36WNgcdBIM5HvKBk7yEl2LGSTyRhZFAFZYRqMs31lM
urM7Ve/AepgwJraJVFCDAjZPLWLO0fEnjcnClRLV+HdtIUaIsAAc9ngAnzcd
jaZI7irC/ba6j3XmfTHCg0EUpbNl38USazFBLFTYeBXjfYxBXZwSf3fFk3BH
wj4YOY7egvBjEomGIOk7ZXfuCQuVayqDMIwKt+4q3pNThpWYG7EhAPxE/PGK
0N/K5GZk8J4WOU0o0kd6B0hdZEUe0sUGprHXEKjgLIda8mDF91ZlnwU6COEw
xqQqzdcEhTgHmHt+SoVMrHAjUoBtuZdnZJttmfZ7sP65Kc5FdpuohrH34f31
W2r3SNMX3+1xMn4yPhl0l0u0z8XIHUtt12yn956xvsvGZgC3TFlwRwLmr5rS
1zU2f6Gr5EJM1Qk/7hI6XtdmyXVtE+nyqq+pxQIizI1ZRYCPm/m2KtRGgvSH
9tlfGUBL5eqpWPjg0OYZVBjFPJDY+zHYVfGAdSj6oNBUEYCSq+1Q5wbKKG98
WwVdBlBQReG4wOCpwcS8lo2DCn5mB9zRUR5br6rcb8aRQeZobwh+2ZPSXaxA
La7Bg1AZPC21H1KKr8dPJ1mGnZhJVof5lQd0O0mvX5ymdNQOu0462j6abUcd
7Z9Jq51tBxQjG1rJL+uaHqh7Z12TKJPqsiyx4YFRJftm1xqG+Isp2q45TAvf
KmZRczYAW1zvTswXQNMh44UN+6CosNkGYQOvkvp/jvfsGZ2DBbXkjhmX8uD1
L0N9vF+ztAbyrFIlqeWC770cZpQzbEwKJ07VKhCHvSPIzzXVL8jiiHuEdUMG
mDwF1ZnrRes6GEJ5DTbZQoaM3QWAQcDdmsqsdN5J85p742qSnr+IzUErjrk5
q9NcmJOao+5RGyw1+GwP5FE2WAZEF2SIc32uOouV37wtsceN6HdagU7GGUGE
jEExMePApZgGyOCACc5aOkkSul2udU4dsj6lvjC57UzKUqX382Lpm8sjjSve
EBiikOtDq4MOfF3gjPOEOfbOxwOkMyivTz9Axg13bhy8t0GyYqbbPRw3C/CF
fqw0uc2v1iSA47RLT+6yhyuWqaPhgiz4mpL1G+u3mcvKF0aWrnb78NBpoPoU
NzxJa1rujL6y767LTQUWqOmqfJhesCUKkzEYzfE2nQoEwCOyDUQjt76ujNeo
qDjUggrxY8XAwx3T8T1YVF8OONdPr90O3Iq5xrKKYDqyoVT+rpsXt229oYS1
05iTxRvtoejPBggFsdQFpFgVC3kR9jy2u1UT5xJiP3S4APKeOtuZkXj0mSrN
fezFZdOKSZTLOe0hbltCeFOMcx7wHKiFEPKLQiec9ArD5vHENZmFeGS5urBC
b4Dh0/cIWgBQstbGupNaDQELj+HlJoMHSAo0GPPI/lFuLt3EQA14g+sU7K/4
iS+/uI4tDltECPgXrHpgBCCasOJmRR8SmErijiDjDfxVqzl64hpbFgfJpbzS
tAvtGsA4rdafqVy2hB/Ulm/kSPSqGFD+OA9NXZw5UeF/XruWCNdtt5L1nQIN
OOO2J7u1pDH9N99PXwE3lltLMMo3/AwFCGiDNNoB6it2Kqk6xxZ3zJ/QW1gu
8M/xMhw8hHHVGHA3C1DacXaBTGHTthFOqY/Y9YUkAwCXhfKi8g30voGpdiw2
M1QwEpz3lSF3Ji9Oo+6UWvP+Ps2wcg7Z6A0DpQRKJn1vHlI2O5WfkBM588B7
trRchtV1hS1SMZ1nBEiuy+qmdRc2sblqB5cLzKBKvAogAS4QChILZ7K6q9t1
k2+prJhjBGkw4bbUdoWCxSH+SguDTAO5jU/FwUOg6Fgtk07SIsibympliYL1
oBmAnKxCmKPx0Vh2eE6N2jM2eawEITFOBNQDI4N28BLsUomDngJ8wYBLEtG9
xqZQGwVGa1MjY0P3rCovjVWESYCDpb5T5dZ7Y4qVwXc4ijDr2+mLLIwDzSvX
cLd3QtupQoMVz7BXVCubvLuBUbgiW9DukpLE3UeKLbIfPDhaPyWoAGbxNoMb
5cD4yZCNKJUv3DiPhgJH+cbeHayWgPsaCnoDgTSMV3G2QrVlBIN0EoKeS0MX
pTEC910KALxrC4RwS7nmlpXQRDIAXPtWYoT3yR3vlXS71vvgQFcjEBWcBfHs
3xDBhgZxE41of17YNONOwgq7DfXG+VwFZ8evKFopeqwU2GDHQkcvRIAT74sc
d7dsPt5yWEIr53uoDxCbHcFa+7WB7B673y0wDGQNn8D/3DVm3X0dBj22RlMd
kLMlj+zQIVhJTRV4D2dpo9q3uXLv1QL7ggSq4xq1MVzTbJOEIVhteB+nE+zx
0WroC8AeclAH1l1YrwL1tDyULNk33HnGulDGxnAvuQGWDOqQZdM9HwIK9x5M
9mGpOFXs9J354fcemnt3EPGlqYEFiFP7XigDL6thh5Hk/BgiA0sO4lOnSjM5
I41AKkqPxkAtXnN1cJjAHusbC5kdBYuImhcT3B8rHkPHWX7jhK4KqL9rk6A1
fiks3uujp6L62ZD9P/U0W3e/ACdzpaFj6k2gK3isawzFCdl88gPh4w62LxQs
Xo/FeeIa0uM93q1j0c1PgMJePETdeLclCHZrqfGc0POBxkOXMNFO+LadeKD0
UvQO33FP/K3CxA+Eoe5WfWQq+Ll3cnRyNDr6ZnT89Pbo2eTk+eTJ8U+9oR/8
j7//FyTGoAEw+h9//+8J/gAzTnDGk+Pbo+PJs+PJ86Of4FmY00N7rpFsXL80
i4Uq4oo7t6ow4l+np9PjkydPv372zfMXycDDPUw9fg81DvtSgxBuAdmyevZU
VbmBaIfXoar3xQWonvuluQcucL405XPXOpPuo/Pi+Pfw4tiN+ZTR/wImP5n4
nv8tNYzYAHsZig/Z7LxJuiIYDiIzD9fosYTrWtJ9lZ7hQihouLxsG9veuaoX
JjVmwe7KX4gSLmOH6G0JnUAa4bSNjfCx/X2IvfaH0qiwd7x+RGTbeUN07VqO
95pofC8dQub0nSJPAN/0uJAvaqlLcNmLJKcZZ6/Z1fAJ4utK7MmwllivOLYY
scD3dMC1OP4/3n31i9gRlvD9/olriiXtIUX0Hka4njtx0kqqqOaTkFsnl/ug
K/69x4a6N96BKexkgJ0y98Oj3W5k8GAvsXlGvMOSWb6lFTl9QkZn2Y8//oiP
b1zesvf80aGeSeuBIDsfhNop6psrdxs5d+nx/supOpacXHkUkCtYdQnho3Dt
w9TWAkJW91gQnSf1BZhNoGXn7gYSyJbfKaO1aSqCTLwwofY5+BlX3BiX72JR
kYOvG0CdTH9Gcr958gLLJm/MPYpoGKMYu/j9gO4q8BYQaukqaQleKPVc+W4v
ooIMBC97VtQVHyv5NNJxrhPJ/cvAfHULR1Xx3TmSA0dpLm12qXJFa+JW3+WN
kPvqORfQYQNSfF1RqxZCaZbZixdfg8zc7U9gLufL6GT8u7yGK/Hevt2ZATPn
dx0xU6kWMIzLx92v9O8JxB4RB9pCg4hnBnxHrwdHSC6LUzvwhRB//X94XUJP
/g3wA+nLGgFkRfdTssQ35RbLQ4TOQ2MmuEl8rSxG9UG8+6M/j8T59HK6Z1nd
N+47L+tGxEEzJVX/+VVGsv3zs9vX4oeLtz4v2O6vhr/jcaR4f30eWqb2JvbY
OvHfDEB1p+3Itd2xKP1CXbKAkuw/4Q/HNthgIgDzTxDkTLDpfWUnH1flBEjG
/r3JYfDDk31mA0S/4jrnhI44vTy/mIoP33npI+VjngL0T8TlV9OhUwuqtAG5
dFC6bMMTIj6AIIFInEjdaXIU2BJsfxcDaZbrhvSM3Fup5z33ljmK/8jCH+No
ZCj/yxP+z29xLxyShv9/ZQAqP9cf/Y6XV5dn/Dv8jJm0W/32zfmNOL169f7i
7PLW8RTLkjm+Kk6OwNUd30CoM8mlNEBM/hcMZjK/o3a6jyDwuDpMAYaJM1eq
geiICKlWK7Pp3vk53+dvwzB7s8kyIuntG7uoQ++kDN2Xo6ckkuz/AKiB/7LA
RQAA

-->

</rfc>
