<?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.4.17 -->
<!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-richardson-iotops-iot-iot-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="iot-iot">Involuntary Onwership Transfer of IoT devices: problem statement</title>
    <seriesInfo name="Internet-Draft" value="draft-richardson-iotops-iot-iot-01"/>
    <author initials="M." surname="Richardson" fullname="Michael Richardson">
      <organization>Sandelman Software Works</organization>
      <address>
        <email>mcr+ietf@sandelman.ca</email>
      </address>
    </author>
    <date year="2021" month="July" day="12"/>
    <area>Internet</area>
    <workgroup>anima Working Group</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>This document details a problem statement relating to ownership of IoT devices.</t>
      <t>The problem details is that of changing ownership or possession of a device when against
the consent or knowledge of the device and/or manufacturer.</t>
      <t>Examples relating to outer door control are used to illustrate the problem statement in an intuitive scope.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>Much has been written about how to secure IoT devices against both physical attacks and those that are done through network protocols. (Insert survey articles)</t>
      <t>In most cases, the goal of the security mechanisms is to make sure that the device remains under control its lawful or intended owner.
One example of such a definition of this control could be to mean that the device accepts commands only from that owner and that the device provides information only to destinations that the owner specifies.</t>
      <t>This document explores the problem of what happens when the physical or legal ownership of the device does not correspond to the logical ownership of the device.</t>
      <t>There are many ways to explain, scope, and illustrate the general problem.
It is much easier to understand with concrete examples, and in this example the front-door lock scenarios are used an easy to understand way to connect to real life intuition.
It is believed that most other IoT authorization and ownership problems are probably subsets of the situations outlined here.</t>
    </section>
    <section anchor="door-locks" numbered="true" toc="default">
      <name>Door Locks</name>
      <t>Most people live in some kind of dwelling with at least one door.
When there is more one door, one of them is usually the front-door.
This is the primary method of entry and exit, and it usually connects to the street and thus to the rest of the world.
It is where both strangers and friends arrive and depart, while other doors (side, garage, balcony, basement and back doors) may lead only areas from which further egress may be impossible, difficult, or deadly.</t>
      <t>The door lock is among the simplest of IoT actuator: after potentially many layers of system, there is a single output pin from the lock microcontroller which operates some kind of solenoid.
When the solenoid is operated, the door unlocks.</t>
      <t>Of course, some doors may be much more complicated with automatic opening or closing motors, sensors to make sure there is clearance before opening, and that the door is clear before closing.
Some doors may slide, lift, rotate or perhaps in the future, modulate to alternate dimensions in order to create an opening.
None of those details matter to this document.</t>
      <t>Also irrelevant to this document are the mechanical details of the door lock itself.
While the physical characteristics of the lock are terribly important to actual lock design, it is assumed in this document that the mechanical aspects of the lock is of sufficient quality to resist the expected amount of brute force that is anticipated to be applied to it.</t>
      <t>The history of physical door locks is frequent tussle between lock makers who attempt to make locks more resistant to attack, vs thieves who use ever more sophisticated methods to attack the locks.
There is an obvious relationship to cryptography and cryptoanalysts, and it is hardly surprising that many cryptographers and cryptoanalysists are also competent lock pickers. <xref target="blazepicking" format="default"/></t>
      <section anchor="human-relationships-to-doors-and-door-locks" numbered="true" toc="default">
        <name>Human Relationships to Doors and Door locks</name>
        <t>Homes and apartments come with a complex set of ownership conditions, often via laws established over many centuries.
Many places have very ancient laws about when and how a Hotel may evict people.</t>
        <section anchor="single-owner" numbered="true" toc="default">
          <name>Single owner</name>
          <t>The simplest situation is that of a freestanding dwelling, owned by a single individual.</t>
        </section>
        <section anchor="family-home" numbered="true" toc="default">
          <name>Family home</name>
          <t>To the single individual one adds a spouse, some children of a variety of ages, grandparents,
sisters, brothers, neighbours, cat-sitters, etc.</t>
          <t>Some members of the household may be trusted to open or close the door from the inside only.
For instance a younger child might be allowed to open the door when inside, and only when there is someone else in the house.</t>
          <t>The child would not be allowed to leave the house and lock the door, and preventing such an young child from locking themselves out might a useful feature.</t>
          <t>Many homes choose to have deadbolts which require a key to lock the door when leaving.
Pulling the door shut is insufficient to lock the door.</t>
          <t>Other owners prefer that the door lock itself when pulled closed, and so might use a spring-bolt lock.</t>
          <t>Still others have double deadbolts which require a key in the inside in order to lock or unlock the door. People prefer these if they are concerned that a thief will enter their home through a window, and then will go out the front door with their stuff.
The double deadbolt requires a key to unlock from the inside.
The downside of the double deadbolt is that in the event of a emergency, it is not possible to use the door without the key.
As a result, many homes with a double deadbolt will have a key hanging nearby, but not within reach of a window.</t>
        </section>
        <section anchor="roomates" numbered="true" toc="default">
          <name>Roomates</name>
          <t>One scenario where there are multiple unrelated individuals in a dwelling is when it is shared by roomates.
Each roomate will have co-signed the lease and will have an equal right to be in the apartment.
It would be inappropriate for any roomate to have the power to lock out the other roomates.</t>
          <t>This is constrasted with a owner (or renter) who sublets one or two rooms to other people.
In that case, this primary owner should have more power over who can enter and exit, subject to some legal restrictions.
The degree to which subletter have legal rights varies by jurisdiction.</t>
          <t>Can any of these individuals give a "key" to girlfriend/boyfriend?
This is definitely a complexity of the situation which is usually not seen in the family home.</t>
        </section>
        <section anchor="apartment-building" numbered="true" toc="default">
          <name>Apartment building</name>
          <t>An apartment building consists of many dwellings with some common space.
(This is distinguished from a multi-tenant building where each tenant has their own front-door.)</t>
          <t>Residents of an apartment buildings must pass through a common front door.
Historically access to such buildings was via a kind of guard, the door-man.
This has now been replaced with some kind of master-key on the front-door, which a telephone mediated system that allows visitors to "buzz" up to the appropriate apartment.
The resident of that apartment then activates a circuit to unlock the front door.</t>
          <t>Historically, these telephone systems were hardwired private handsets present in each apartment.
This meant that anyone who was in the apartment could let anyone else in.</t>
          <t>More modern system are tied into the public telephone system, and a DTMF tone is used to unlock the front door.
With such a system, if the phone number attached to the apartment is a mobile phone, then a resident can buzz themselves while outside the apartment, and then buzz themselves in.</t>
          <t>The modern apartment system does not usually provide for multiple numbers to be attached to the system, and a guest in such an apartment would be unable to, for instance, let medical people in, if the primary resident took ill.</t>
        </section>
        <section anchor="rented-or-leased-dwellings" numbered="true" toc="default">
          <name>Rented or Leased Dwellings</name>
          <t>Many dwellings are owned by one person, but occupied by another person based upon a rental agreement.</t>
          <t>Historically such agreements were based upon leases of many months to years, but intermediation of the relationship by a number of dotcom companies have reduced the lease time to days, and the same rental systems are expected to accomodate what is more like a Hotel relationship.
That situation is handled in the <xref target="hotel" format="default"/> section.</t>
          <t>In many cases the owner (or property manager) of the home has a legal right to enter, under  certain circumstances.
For instance to effect repairs, to show the dwelling to a new potential tenant, and in emergencies, to do things like shut off water or gas to avoid damage.</t>
          <t>Notice is often required for most activities, most laws allow a landlord to enter without notice during emergencies to do things like shut off water when there is a leak.
A landlord can also be compelled to open the door for a police warrant, and in cases where the police suspect harm, they often will enter without a warrant.</t>
          <t>This situation is even more complex in apartment buildings, even where the apartments are owned (and occupied by the owners).
There is still a building manager, and there are still water leaks.</t>
          <t>There is additionally, many common areas to which many people should get access.
Some areas like common rooms are multi-access, but during a reserved time, are exclusive to the person who made the reservation.</t>
          <t>Additionally, there are secondary areas that are private to each residents, such lockers for bicycles and parking spaces.</t>
        </section>
        <section anchor="hotel" numbered="true" toc="default">
          <name>Hotels</name>
          <t>Placeholder.</t>
        </section>
      </section>
      <section anchor="rented-automobiles" numbered="true" toc="default">
        <name>Rented Automobiles</name>
        <t>Automobiles have doors, locks, and ignition locks.
There are sometimes different keys for the different locks.
The valet key for instance, allows the driver door to be opened and the car to be started, but does not provide access to the glove compartment or the trunk.</t>
        <t>Automobiles are rented in a variety of ways:  from hourly rentals by car-sharing companies (e.g., <xref target="communauto" format="default"/>, <xref target="zipcar" format="default"/>, <xref target="tribecar" format="default"/>..), to traditional daily  rentals by well-known companies, to yearly car leasing.</t>
        <t>During the valid period of rental, the motorist probably needs to have complete control of the vehicle.
If any other party had any control of the vehicle, it might significantly change the legal liability for activity done with the vehicle.</t>
        <t>This is usually done by giving them a key which they must insert into the ignition.</t>
        <t>Some car sharing companies have schemes involving lockboxes (with master physical keys!) to share the  car-specific key.
(This is rather akin to Kerberos tickets: one key is used to unlock another key)</t>
        <t>Increasingly automobiles are going "keyless", and it is sometimes sufficient for the "fob" to be just near the vehicle, but the fob is essentially still a key.</t>
        <t>Many manufacturers are now using the individual's smartphone to unlock the car via Bluetooth or NFC, and once inside the vehicle, the phone serves as the "fob", authorizing the vehicle to run.</t>
        <t>Integration with the smartphone has a transaction cost to it:  the phone/car connection must be onboarded in some way, and is therefore only suitable for car owners, or longer-term leases.</t>
        <t>Shorter term leases may transition to use of a smartphone, but today, they are mostly based upon passive RFID FOBs or physical keys.
Today, when used via smartphone, there is a satellite or LTE based care security system that the drive interacts with via the Internet.
There are reports of people being stranded in the woods for days, because the were too far away from the LTE tower, and the vehicle would not unlock or start without authorization.</t>
        <t>At the end of the rental period, the access for the motorist must be revoked.
This is akin to getting rid of roomate (<xref target="roomate" format="default"/>).
But there are some caveats: there has to be some kind of grace period or interlock with the renting agency, as the vehicle might not yet have been returned properly.
They could just be late.
The vehicle could stall meters from the proper location and need to be restarted.
Once at the proper location, the motorist might still need to access the trunk or other compartments to retrieve their belongings.</t>
        <t>But, once properly returned, the vehicle should no longer be accessible to the original renter.</t>
        <t>The next renter may be standing waiting, particularly if the vehicle is late.
The transition from one renter to another needs to have a standardized ceremony.</t>
        <t>For long-term leases the process may be more complex at the end.
While some significant grace period (compared to rental period) is appropriate for short-term, for longer term leases, the owner likely needs to be able to disable the vehicle some few number of days after the end of the lease.
But, never before.</t>
      </section>
      <section anchor="additional-third-parties-who-need-access" numbered="true" toc="default">
        <name>Additional Third Parties who need access</name>
        <t>In addition to this obvious arms race, there are specific third parties that bring their own interests to the locks in the front-door lock scenario, e.g. law enforcement or fire departments.</t>
        <t>In some places there are locks which accept keys carried by fire, police or postal personnel.
For instance, the service key in a building allows the fire department to override the elevator controls.
The electrical panels and gas systems in the buildings may also be accessible by the fire department in  order to cut off electricity or gas during a fire.</t>
        <t>The mailboxes of an apartment (and the outer door to get to the mailbox) can be opened by the postal carrier in order to deliver the residents mail.
The French PTT T-10 key is an example of such a key, and there is a law and regulation around it as well.</t>
        <t>This is an example of a master key necessary in most multi-tenant buildings.</t>
        <t>It is hardly surprising that there was significant concern when the fire/police "master key"
for the city of New York was being openly sold on ebay. (see <xref target="huffpostkey" format="default"/> and <xref target="fdnymaster" format="default"/>)</t>
        <t>A digital door (and elevator control) key that could be safely deployed as a replacement for this physical key would be a significant improvement over the physical keys.
It would be easier to add new users and revoke old users, and an audit log of who used what key in which building could be easily generated.</t>
      </section>
    </section>
    <section anchor="death-of-a-home-owner" numbered="true" toc="default">
      <name>Death of a Home Owner</name>
      <t>Start from a single freestanding dwelling, owned by a single individual, and ask what happens when the individual dies.
How do the inheritors (or the executors of the estate) take possession of the property?
Prior to electronic door locks, a physical key can be used, and if one is not available, then a locksmith can be engaged.
This may require a legal statement from an appropriate authority, at which point the locksmith may make use of a drill, or maybe even some other implements such as saws or battering rams.</t>
      <t>The same techniques can probably be used against electronic door locks that do not use keys, but can this technique be used against, for instance, smart toasters, furnaces or automobiles?</t>
      <t>Repairing a hole in a front door is a nuisance.
Replacing a furnace or other large appliances due to a death is unacceptable.</t>
      <t>In particular, automobile locks are usually designed to resist significant amounts of force as they are often the target for thieves.
The vehicles are left unattended in public parking lots among many other automobiles for many hours at a  time, and it is even a common occurance that a person legitimately walks up to the wrong automobile (having forgotten exactly where they parked) an attempts to unlock it.</t>
      <t>Any tool or protocol that the locksmith can employ against the automobile could also be employed by a malicious attacker.
Any mechanism that the automobile maker includes in the system to allow a locksmith (or legal court) to open the vehicle would be the target of attackers.
This is fundamentally why security protocols do not include back doors (<xref target="RFC1984" format="default"/>).</t>
    </section>
    <section anchor="roomate" numbered="true" toc="default">
      <name>Multi-person Dwelling: how to kick that that deadbeat roomate out?</name>
      <t>The situation above was for a single dwelling.
Many dwellings are occupied by multiple people, often jointly.</t>
      <t>Should any of the occupants be allowed to change the locks, that is, change the entry authorization for other occupants?
Under normal circumstances, the answer should probably be no.
Under the situation of a legal injunction, the answer may be yes.
How can the door lock system know?
How can the party which is asking for the injunction know that the door lock has no other secret authorizations?</t>
      <t>If the legal system must be a party to this activity, how does the home owner, not involved in such a process know that the legal system's computers haven't itself been compromised?
This is one of the major arguments against official escrow: the escrow system is now a very high value target.</t>
    </section>
    <section anchor="getting-rid-of-the-abusive-spouse" numbered="true" toc="default">
      <name>Getting rid of the abusive Spouse</name>
      <t>The situation where a couple separate under duress requires that access to the original home be restricted.
That is, the door locks must be rekeyed.
Digitally, this means removing the access to the abusive spouse.</t>
      <t>Is this different than the case of roomates?
Not really: multiple people had access to the door lock before, and one must be removed.
For the case of roomates, each had a legal right to access, and no roomate should be allowed to revoke access for the other roomate.</t>
      <t>Now, in the case of separation, the remaining "roomate" must now be permitted to revoke access for the other "roomate"</t>
    </section>
    <section anchor="what-is-ownership" numbered="true" toc="default">
      <name>What is ownership</name>
      <t>One technical definition of ownership might be that the device has an identity certificate from the owner.
This is a good definition, and it is currently what is used in <xref target="RFC8995" format="default"/>, <xref target="MATTER" format="default"/>, and many
other similar systems.</t>
      <t>In the security space, the vernacular term, "p0wned" is often used to refer to a device that is no longer under the control of the legitimate owner.
That is, an attacker has taken control of the device, usually through some security vulnerability, and now the attacker controls what code the device will run.</t>
      <t>So a deeper notion of what it means to own a device is that it could involve control of what software a device runs.
Whomever controls the software in a device controls what the device does, and whose commands it obeys.
This can generally be expressed in the form of an authorization from a Trust Provisioning Authority (<xref section="7" sectionFormat="of" target="RFC9019" format="default"/>).</t>
      <t>Control and access decisions are not usually changed by changes to the firmware of the device. (Not withstanding the dispute between the FBI and Apple: <xref target="applefbi" format="default"/>)
For good or bad, all devices of a particular type run the same firmware that the manufacturer has provided.
The decision as to who is in control of the device is determined by the firmware based upon the identities of the parties.</t>
      <t>All of the challenges in the previous section boil down to finding a way to express the question as to whether an identity is allowed control.</t>
    </section>
    <section anchor="questions-and-opportunities" numbered="true" toc="default">
      <name>Questions and Opportunities</name>
      <t>While the example of the front door lock was used as an exemplar, essentially the same question applies to pretty much all forms of actuator.
Access to some sensors may be significantly simpler, but other sensors will be as complex as any actuator.</t>
      <t>A primary question is whether the front door problem is a superset of all other problems.
If so, then a solution to the front door ownership can provide for all other actuators.</t>
      <t>Or, if there some other physical world interaction which is more complex, then the front door may be a subnet of it.
Alternatively there may be some other master pattern which does not overlap with the front door and it would provide a different model.
Some actuators might be a subset of these two models.</t>
      <t>The various modes of front door interaction need to be named.
Based upon the above description, these would include: roomates, spouses, ex-spouses, renter/owners, tenant/superintendant,  fire-department, police officer, young-children/parent,
adult-children/seniors...</t>
      <t>The automobile, personal or medical device interactions are mostly variations on the front door.  Instead of superintendant, substitude mechanic, leasor or ER doctor.
Instead of child, substitute neighbour-who-borrows your tools.</t>
      <t>The IETF has created a number of authorization systems.
This starts with SPKI <xref target="RFC2393" format="default"/>, OAUTH2 <xref target="RFC6749" format="default"/>, Authorization in Constrained Environment <xref target="RFC7744" format="default"/>, SAML (<xref target="oasissaml" format="default"/> and <xref target="RFC7522" format="default"/>).
There are many others: most are based on the providing virtual access to a virtual resource (computer, web resource,etc.) rather than authorizing physical access to a physical resource.</t>
      <t>Can the required policies be representing in the existing frameworks?
If so, are the frameworks we have sufficiently small as to live within a front door lock?
Perhaps a better question is: what is the price point that society is willing to pay for a front-door system which satisfies the various needs of the multitude of stakeholders involved?</t>
    </section>
    <section anchor="privacy-considerations" numbered="true" toc="default">
      <name>Privacy Considerations</name>
      <t>There is a significant tussle between having policies which are clearly asserted (and auditable) and having privacy for the individuals or groups named.</t>
      <t>For instance, it may be entirely appropriate for a front door to make it clear who is allowed access in the event of emergency, such that those people can easily be found.
On the other hand, it may be inappropriate for the front door to list one's current romantic interests as having access. (Such access might even be "aspirational")</t>
      <t>A significant mix of abstract identities ("The Superintendant of the Building"), along with pseudonymous identities will be required.</t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This entire document is about a proposed set of authorization systems.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This documents makes no IANA Requests.</t>
    </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>Informative References</name>
      <reference anchor="RFC9019" target="https://www.rfc-editor.org/info/rfc9019">
        <front>
          <title>A Firmware Update Architecture for Internet of Things</title>
          <author fullname="B. Moran" initials="B." surname="Moran">
            <organization/>
          </author>
          <author fullname="H. Tschofenig" initials="H." surname="Tschofenig">
            <organization/>
          </author>
          <author fullname="D. Brown" initials="D." surname="Brown">
            <organization/>
          </author>
          <author fullname="M. Meriac" initials="M." surname="Meriac">
            <organization/>
          </author>
          <date month="April" year="2021"/>
          <abstract>
            <t>Vulnerabilities in Internet of Things (IoT) devices have raised the need for a reliable and secure firmware update mechanism suitable for devices with resource constraints. Incorporating such an update mechanism is a fundamental requirement for fixing vulnerabilities, but it also enables other important capabilities such as updating configuration settings and adding new functionality.</t>
            <t>In addition to the definition of terminology and an architecture, this document provides the motivation for the standardization of a manifest format as a transport-agnostic means for describing and protecting firmware updates.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9019"/>
        <seriesInfo name="DOI" value="10.17487/RFC9019"/>
      </reference>
      <reference anchor="MATTER" target="https://buildwithmatter.com/">
        <front>
          <title>Connected Home over IP Specification</title>
          <author initials="C.S." surname="Alliance" fullname="Connectivity Standards Alliance">
            <organization/>
          </author>
          <date year="2021" month="July" day="01"/>
        </front>
      </reference>
      <reference anchor="blazepicking" target="https://www.mattblaze.org/papers/notes/picking/">
        <front>
          <title>Notes on Picking Pin Tumbler Locks</title>
          <author initials="M." surname="Blaze" fullname="Matt Blaze">
            <organization/>
          </author>
          <date year="2003" month="November" day="07"/>
        </front>
      </reference>
      <reference anchor="fdnymaster" target="https://www.schneier.com/blog/archives/2012/10/master_keys.html">
        <front>
          <title>Schneier on Security: Master Key</title>
          <author initials="B." surname="Schneier" fullname="Bruce Schneier">
            <organization/>
          </author>
          <date year="2012" month="January" day="10"/>
        </front>
      </reference>
      <reference anchor="huffpostkey" target="https://www.huffpost.com/entry/daniel-ferraris-new-york-master-keys_n_1928826">
        <front>
          <title>Daniel Ferraris, Retired Locksmith, Sells NYC Master Keys On eBay</title>
          <author>
            <organization>Huffington Post</organization>
          </author>
          <date year="2012" month="January" day="10"/>
        </front>
      </reference>
      <reference anchor="communauto" target="https://www.communauto.ca/">
        <front>
          <title>Communauto Car Sharing</title>
          <author>
            <organization/>
          </author>
          <date>n.d.</date>
        </front>
      </reference>
      <reference anchor="zipcar" target="https://zipcar.com/">
        <front>
          <title>ZIP Car</title>
          <author>
            <organization/>
          </author>
          <date>n.d.</date>
        </front>
      </reference>
      <reference anchor="tribecar" target="https://www.tribecar.com/">
        <front>
          <title>Tribe Car</title>
          <author>
            <organization/>
          </author>
          <date>n.d.</date>
        </front>
      </reference>
      <reference anchor="applefbi" target="https://www.eff.org/deeplinks/2016/02/apple-americans-and-security-vs-fbi">
        <front>
          <title>Apple, Americans, and Security vs. FBI</title>
          <author>
            <organization/>
          </author>
          <date>n.d.</date>
        </front>
      </reference>
      <reference anchor="oasissaml" target="https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security">
        <front>
          <title>OASIS Security Services (SAML) TC</title>
          <author>
            <organization/>
          </author>
          <date>n.d.</date>
        </front>
      </reference>
      <reference anchor="RFC1984" target="https://www.rfc-editor.org/info/rfc1984">
        <front>
          <title>IAB and IESG Statement on Cryptographic Technology and the Internet</title>
          <author>
            <organization>IAB</organization>
          </author>
          <author>
            <organization>IESG</organization>
          </author>
          <date month="August" year="1996"/>
          <abstract>
            <t>The Internet Architecture Board (IAB) and the Internet Engineering Steering Group (IESG), the bodies which oversee architecture and standards for the Internet, are concerned by the need for increased protection of international commercial transactions on the Internet, and by the need to offer all Internet users an adequate degree of privacy. This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="200"/>
        <seriesInfo name="RFC" value="1984"/>
        <seriesInfo name="DOI" value="10.17487/RFC1984"/>
      </reference>
      <reference anchor="RFC8995" target="https://www.rfc-editor.org/info/rfc8995">
        <front>
          <title>Bootstrapping Remote Secure Key Infrastructure (BRSKI)</title>
          <author fullname="M. Pritikin" initials="M." surname="Pritikin">
            <organization/>
          </author>
          <author fullname="M. Richardson" initials="M." surname="Richardson">
            <organization/>
          </author>
          <author fullname="T. Eckert" initials="T." surname="Eckert">
            <organization/>
          </author>
          <author fullname="M. Behringer" initials="M." surname="Behringer">
            <organization/>
          </author>
          <author fullname="K. Watsen" initials="K." surname="Watsen">
            <organization/>
          </author>
          <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="RFC2393" target="https://www.rfc-editor.org/info/rfc2393">
        <front>
          <title>IP Payload Compression Protocol (IPComp)</title>
          <author fullname="A. Shacham" initials="A." surname="Shacham">
            <organization/>
          </author>
          <author fullname="R. Monsour" initials="R." surname="Monsour">
            <organization/>
          </author>
          <author fullname="R. Pereira" initials="R." surname="Pereira">
            <organization/>
          </author>
          <author fullname="M. Thomas" initials="M." surname="Thomas">
            <organization/>
          </author>
          <date month="December" year="1998"/>
          <abstract>
            <t>This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="2393"/>
        <seriesInfo name="DOI" value="10.17487/RFC2393"/>
      </reference>
      <reference anchor="RFC6749" target="https://www.rfc-editor.org/info/rfc6749">
        <front>
          <title>The OAuth 2.0 Authorization Framework</title>
          <author fullname="D. Hardt" initials="D." role="editor" surname="Hardt">
            <organization/>
          </author>
          <date month="October" year="2012"/>
          <abstract>
            <t>The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.  This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849.  [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="6749"/>
        <seriesInfo name="DOI" value="10.17487/RFC6749"/>
      </reference>
      <reference anchor="RFC7744" target="https://www.rfc-editor.org/info/rfc7744">
        <front>
          <title>Use Cases for Authentication and Authorization in Constrained Environments</title>
          <author fullname="L. Seitz" initials="L." role="editor" surname="Seitz">
            <organization/>
          </author>
          <author fullname="S. Gerdes" initials="S." role="editor" surname="Gerdes">
            <organization/>
          </author>
          <author fullname="G. Selander" initials="G." surname="Selander">
            <organization/>
          </author>
          <author fullname="M. Mani" initials="M." surname="Mani">
            <organization/>
          </author>
          <author fullname="S. Kumar" initials="S." surname="Kumar">
            <organization/>
          </author>
          <date month="January" year="2016"/>
          <abstract>
            <t>Constrained devices are nodes with limited processing power, storage space, and transmission capacities.  In many cases, these devices do not provide user interfaces, and they are often intended to interact without human intervention.</t>
            <t>This document includes a collection of representative use cases for authentication and authorization in constrained environments.  These use cases aim at identifying authorization problems that arise during the life cycle of a constrained device and are intended to provide a guideline for developing a comprehensive authentication and authorization solution for this class of scenarios.</t>
            <t>Where specific details are relevant, it is assumed that the devices use the Constrained Application Protocol (CoAP) as a communication protocol.  However, most conclusions apply generally.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7744"/>
        <seriesInfo name="DOI" value="10.17487/RFC7744"/>
      </reference>
      <reference anchor="RFC7522" target="https://www.rfc-editor.org/info/rfc7522">
        <front>
          <title>Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants</title>
          <author fullname="B. Campbell" initials="B." surname="Campbell">
            <organization/>
          </author>
          <author fullname="C. Mortimore" initials="C." surname="Mortimore">
            <organization/>
          </author>
          <author fullname="M. Jones" initials="M." surname="Jones">
            <organization/>
          </author>
          <date month="May" year="2015"/>
          <abstract>
            <t>This specification defines the use of a Security Assertion Markup Language (SAML) 2.0 Bearer Assertion as a means for requesting an OAuth 2.0 access token as well as for client authentication.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7522"/>
        <seriesInfo name="DOI" value="10.17487/RFC7522"/>
      </reference>
    </references>
    <section anchor="personal-devices" numbered="true" toc="default">
      <name>Personal Devices</name>
      <t>There is an increasing number of devices that a person might have on their person or around them.
The list is endless, and goes from step trackers, to watches, to recreational (exercize) heart monitors, shoes, shirts with displays (for fun or for the disco), to intimate devices that might be worn at unusual times.</t>
      <t>Some devices may belong only temporarily to a person.
For instance, a tread-mill or weight-lifting machine, or even a kitchen appliance.
After the user is finished with the device it may need to reset to be ready for the next user.</t>
      <t>A kitchen appliance (a blender or microwave) might have only a small number of legitimate users (the members of the household), but when one person is using it, it might remain exclusive.</t>
      <t>The same appliance, however, might also be purchased for use in a workplace kitchen, and so the number of legitimate users might range in the hundreds.
The users will want the appliance to remember their personalized settings.</t>
      <t>The names of the previous users should not be easily divulged, but at the same time, the name of the  person who used it should be available to a privileged user (owner), for the case the finding out who broke the device.
In this case, it might seem obvious that the device has a privileged owner, and may also have just users.
But this interaction may be quite complex, and is subject to a wide variety of locally significant social compacts.</t>
      <t>In addition, devices get lent.
This could be akin to thinking about there being users vs owners, with the owner always being the one responsible for the device.
However, passing on a coffee maker to one's child who is moving to another city is not always a loan, and not always a gift.
Which one it is may not be obvious to the people involved until later on.
The parent may forget about it, thinking they have given it away, while the (adult) child might pass it on to a friend.
Only when the friend tries to "own" the device, do they find out that the
parent is still the owner.  Now what? Does the device have to be returned to the parent to physically give away ownership?</t>
      <t>If the answer to the above question is no, then does this in essence enable theft?
Is this a kind of theft that we need to care about?
Does it matter if this is a $50 coffee maker, vs a $600 espresso machine?
Or can we even set a meaningful threshold?   Theft of a $600 espresso machine might not be a problem for some people, while the loss of a $50 coffee machine might be a rather big problem.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAFWY7GAAA51ca4/bRpb9rl/B7SyQbqykbnsySdzAwtu247Ex8WPdPQh2
vwQlsiQxpkgNi2xZMfzf9577qCrKjwF2gEHaFFl169Z9nPuoWiwWs6EeGn9d
nL1s77tmbAfXH4s37cH3YVvvi7vetWHt+6JbFy+7u6Ly93Xpw3Wx77tV43dF
GNzgd74dzmZuter9/XVRd8OC/j+rurJ1Oxq76t16WPR1uXV9FboWv3b7sNAX
F1cPZjMap61+d03X0gdDP/pZve/5rzA8vLp6dPVw5nrvrouX7eD71g+zw+a6
cG29c8VvXf++bjfF3/pu3M/eH9JLi2eYela64ZoorWazfX1d0P++K0rXFmPw
het7dyzO63XhmqY4+nBRdH2xdWFbbH3vZ0UxdOU1fqA/Q9cPvV+Hax6i8ms3
NkOgN+z3405+xj9nbhy2XX89my2KuqWHr5bFu8gDeluY8wqPfDP9qetpcbfE
Ed/siNDbbj0caPm8Ukzkd65urotd2f9H7Yf1fwV7dVm62azt+p0b6ntPc9ft
Ov2rKN49f/ro6sEj/Pnq5u7ul3f4i9aoQvC0a1tfDr4qXnQ7X3T3tPMv3xa3
e1/W65rYWHftmXzh+o0nrp5th2Efri8vV2PdVId62NJkxPxl2e0u5VXjQ8H/
k1XbTPV9PRyLW2w+Fl/cNE3t2tLLlxXJ1nXx8Orhg8XVTywmRbFq3J9+X5fY
8Snxr7vBh6Jri7fyK/23Le7GHclpX/zale/DV0g/HA5LUM1DL4n3l3u3JwW4
bDHipU72rdW8oq+LJ/h8SvjVXxYPQDsIX1ftcecC8WZK9m25bX0NFaON9uXY
E0dILPjN4u/++A2ig37KzF413ebS9eWWtjpcPrx68PDywdWlzPj7e38My+2w
a76xiCf9WPrCyJku5MFDYv/iwRUWsh3X630XBhrz+uu02VtMG9mH/nhZkbr6
ZkHmpHd9HRatPyyOJNELIXIBIn9vf3/w6OHPPz/88WzCpWf8bfFcv50X7/xQ
9ySovLE7krs5ca9pQvH6f55m3AtkzAr/xB2/tHBWs7MXRCnt7wDJIYK/vnBa
yW5saYjuVGvsefHU9cUt6TGN9419SwORvpJc0Zt/1vvSnUjG/5Lq0YBfGUi+
UD2Dnerrlf9sjDs8/cYoIMe+TGO5/b7x61U9HesGT+fFzc6TLSe/MCf7W0WZ
Le7Dsnj+5OU3JvLrNatX5f2+qdv3LKY/Xl49vOQJF85GXtDAi6ADL+7Dgmhh
wjoX6hDcrvmG5PE7i27vW54MzK7JJJFSDOXvW7Jry/12//iw+V0c1n/aPFOB
e3Nz+/I2Le7W9+z5ivPbm1e/XhR3T4mexWJRuFUYelcOs9ndtg4FOb0R7pC8
w0A2OhTuc1dZ9L4hU0oWiiSmO7Tqa6cudokBffzYhqMphq0b8DL5i3aDUbIh
+oJ0LvgQyFDjHafDFYetbwu3ceSJhtlAA5ddG0ALffK+7Q6NrzYeX+A3/YY2
4ZJ+JrcyrmmFY0+WZjb75YPb0WaF6SpG6FvV0es08NB3TQF/RR62ws9104xg
0+B5/M85Qpaa/FzdDmMNV1WEkvZvKRze1VXV+NnsO7j1vqvGEm5oNns1llt4
6mLlaW2HHptMw6yIlmLbHTAvb63P2Wo8KFbdsC3222MggSNih8GRHWGBJgsR
vHAZa6gIktC/CFtstgVhigNZLKyAcEHXkMifvyRG9kMRxv7eH+mToS6JPRez
2cu22JFBIaxBOzLnlW86mky5bHJX7Dy2sg472d6OOP7eYzylItuSHp6/DcVI
/j6xuiYQ0rjDemywncRFTz9XIhfL2Rui38umYeoAtkEuyOjVg8rJANm14cpu
bCriKpPiaV9OqXBl6fdDYINIHIPTbY7Fuu92KpyYWHk5/ZL4dl9XtA0Rl2B+
fE1z0XOSJ34W0pcyWBAIonqRK5r/sG+63oeJZNGSDhhgS4bF02gs/vyC7Tgx
qvEb/JErYEZq1dGYhABolT0Nv+9aFmW8QZ5Wxvjyp6K6vWfxIQYdi4M78saC
Vtq/uci32M8T3dh4GpPG1pUsZy8HSMUOu+bJshEvaCDef8bMBTAXtq7s/RA3
Wm1z3crO2vZjAtqmdliwqjbkO4kU35LD6kLSWNpymup4OpHjJ6UgN/xJgLwp
mnrtTXO71uhd+ab2914lgNWAFA5wknRRvHD9p2w/xk6c1HULNfiHW5F0hHEV
PEmcqU49jConpO3kSmgicHwJK/EMS2NYQDYCE+99h8U3MCzEkQBoS4iuwmjV
gUADjBizkUhtaOVEa+vZmi1nv6nkEDXYBpK0+OOc/xKSdvh1DCNFEccTNi9F
YGuTUApZeig98YBJYHDEXPAf6kE3boiDKb+DCR/JiveDatcYH5OIDsYeMlFN
ZTtxYNrZ3EHM2g0xmr9e97WH8lIIBM7gUeX3ZL/m9E0NY8EbhiWQ2wuktvNi
43q3of+uXEN0HfFHEAuOz1dkQ+X9C5L7I3hZiXYjdgtiIWhsEuX12PPofkOE
B36bDE69g/uqV4AZVU2wrKQAaw5drWio5qhOMQkvrc/tOvgglgoW/cE8KXyW
GwjuFRQEerhGMoxDzVxltWzcEcyAUTwSYNzN00Y7Gq3dgAnjsCeHsifBUQPn
ZepdXfadmkxEGLIuUmuocphKWega33Z1lcQpPsJk+lElPoJXN7aYBNbuzRoG
uQ/EEh5T9kMZxmaBhZJsMWGqEsOoLBO8hIEtMXzLOIE8RtNhXfQJ8YWMBEGA
gOFOnI4ygfwY7TeFYzTVmiVfRpqf2HYQbK/bqzrTcnY7JTo0LEhkNWhjyYvC
7gG2+J5sdRCLRdozAm7Mic5qbNg0dhSgI6jHP6qaRC6w+tP7XV+JUSQLiF/J
eimdy9nrqKHw6QaiJEQVzclcCTH7pgmEVsjeN/7etcNnr7BVAoHqs+EFbFTz
AUk4h+CbNfa8VtsbvQ9ifRJPgrvk8sr4LX/GU1CcU8PwQSP6QUlhgW7kLXKW
9YY8Sc1K7kIg+pLBj/TGTcoIdnCmw3TSWtQAoVBZ48N/0kwAJ2zmCVDLKOTA
JD9AWje2rGmrnrBfQXteKlwBOaRmZb1nYaQBSFAB8GsFg4OqMRFKUnjEIJEx
kXtsMNe9/+fIyxhDaCCGwwFgTxSQBLaHfesA3/xuP0QxlgFYL4R4YyDDvDmF
KmAT+Sf5HIkgj1wHfxG6/Za3hckXOx3S15FnYalunhdcdKv7uhsNFpNswpux
VB73Q7fpHa2R9UYeuNY1ZHRCtPc0ChJA7Ox68hKsp+I9YauyYcyA5wMRweIy
HSQYxsDD2AmnkMGgj5bFx495+uTTJ3KX3xUvRuSY3mVk82qfscpinmdxT2Yz
5IXkqYOrgIwxDvRqdMQO+Q9kWVg6kmMnU1kxRKAld2tA9fvaAbYSPKENWjV1
2AK08j7wimlsAsiAfK/wb4JOAPBbR86KXgIzRVR5DMH9EuYQdQgAXPGCLH7D
ZgfAzJAAUAKt+1YNPCgUgYwOJOKLPN5yEEfPWAhbY8hhziOQ8zsmp0Fmvyac
Syqkcz13u5p2FtEnTaWO/PRdhhOuqtj77EmWzOSXZECq3mtEd09ozQ+sNuSL
iZskFG1Fu4G9mM8gCh62fdWzA6e/Wl9vtis4kTkFI8MiIFTCP/xQEoFsoXd+
t1JnCOK2mH7bURygnoYzsaLAsK7mTHyyedE9UoBCNp4d/3L2nCMScA2BQ3Ek
s7FB6IIlkQ/dbAc2D03THbLR46C8oTKgaArDicMElIFHYJ1vgjcHwvSrnZG5
DhzVANBP5yOnde/TNzwJa43RIPPue7IQLce7EkG1shYdnRePz0RrCcD6BuYF
QimrdDAzCNHW5KVGxqos1lvWqHLbMTM7kW/AnVWH5LLACtjBGtpdvPdskycU
Cj+wEHZ6b0eBtPHnsB3ZvhAfk4E/HQRQgyGZqCwWjMT/1Mtnfk0m3dNcxEcW
hUo4RfZHVszcJElGNmyB1fDnELiBgh6Bl6rPVTcS6PsXy9atVfHKPT+TFVFT
WlLxVqB/XIuHhLCEMybluAmVAkUzjt0CLQ30+XaQb+qeNykmARz93lbdwWAQ
sg/4YMN5kIT+dW9gF2WUMBD7lwphJwu2lYa0w7qWE62yrw+qY4Y5pqOZ1VKO
seSK8SCw3lOIWR4NOUAhDHTztLlKg3ZbEpG1nN2AQCKTYfkuia8a/1M6mC28
wbIsy1i1BBRXiB5obBCAz4lWwm+A0OvIYbWe7zogWdRUkMuwgFUjmyGF2kRV
je0eW3bCjIfMuDJUdCneqzUpIFwI5HrFhvc613L2C4jRf2YrKbsFkBeLjOdw
UWxGtlYKnwGfip7VQACQbkX0mhyeHSzTUrcEkPqOVMUJmCrAW5vcrAJDSLJb
mczr5kiolmiPISfSfBT1hRQWaELlnOboWcQvGAMF7BxAYct4fDh0PBxDARnd
nOdLTQghrTUXuGlBreZqtrwsJpkRldDMnh1TofYmypWCXpr+D80qsMuT3AyC
2r7mfF9QyUfAyBwRCyFkYyyeTj8D34M4yoBN/YNwRKhkIGLOU9cyf0V7gp+I
yYaD4eKM5PUM82zqvpFQ+XLVHeWvx5G/mkbziHEN+9TD8bNEhZKbJQkg98Gz
dxOTkSCCiv2NyUrBxTWSWgpQ2iRC8THvMiNAmpa10sRcNVNQRLejUJnssUOK
6jyuAFi33YwCv9jcOFGlBYE0l08jCsdKqj8h/Sq2jbY+z3lczGbvPExUK1S5
L9GNtBbyMxS9ZMZV6UwmdDl7wZECAgTwuSyRMoCkwBGnwQ5EDDCli3H3ZiRE
naLqBSqksnUgvCWMyLnj3jO2rDJm2QipNIX63DSxM9dNJa9B8eJ+C9WhIKxm
yyMZBXUrQBugjcRBo+2z1fjnn2fFuLf8Ta7/mZG4k9QOM1KECuNFTrLzcaij
ctKBmFf35VgPmQOZuiMSrZyZc1WAtAChm5iJrUZAcuAyG1GGKWDBK87EkUsN
mrlngZjQjEyZdxZ+kkBiZKg+tujUEmq+ufHxTQVyQEgwH7uO3HxrHOXwuGbb
rqzbkw2oy8/WIO7ZFc/uXj0nfrRetE9Q31eY8xsLgGTIbRTBC4UM3Y6AyRIK
bn2Vds8Ww7mjXbdCyM+fzHWT0jbC/mH7c5yoGbdxYLc+GTKDGadfMY8gIsqi
RIYyKyaxzepoAp5dTPSXsqhgofrJ2qbc3IwIkJBGVRSc5ozebGydoIk5z2Pw
f857DA1BpK9ZWWTDjcPqRSKjhq57j/y4wQA4jQre6Vd4XQpMzcoplE5WD0IS
wzLsG+r5XSuIoyvLcV9ryNaac8PvnM6sSCs72bB2QLoEHkfzQxNDJBywX1Vl
shEYGySbTEZt2Gq3iOMADagcflCMRizF+GkOgQNLlTtkrLuBLCT7GtTEFUCT
jo7lBJMM9Y79ZOWOIYpQEdzO28JM1cGsmNjhNBMN3lUMezShw268qd/7GFTn
JELl3UnUDEPRWEbKFx8/bvHZp08oe6kbRn2MA31mU6r1AJrAGPp+4EQtRbkE
UmJguvNsvV3u7Lm4AlbOtTRWEKwfHE3OBnEnAhhOwlF8tF4DdpAHcDX2BF6F
i4dwGYYVwRPCrIeUQVb/F6ssBqtrL2NUnDeEJDLTOADr1hRYOEAVomHjJKV0
jxRw5Xa0RuLI625A6YmTcQM7Jo4KKlFX1DKc9MzwPPxAkh9wMOAImE5RUWRH
RPCtjFyNCMZycv81tdNgG2x3FMTdpMlgzzjttJI0tOeQ8LNQnlEtsbDhejQa
rzIGigxERG+vhZFzlXBEkp0/KmeyCM2W6GxQg78TeUQMlGXK/QeOBz6HJHN5
M1GS5bmSVTnnVERmR6L0hossLRg40HUJQak0R33UyEXeE3aDvSGWEMHxSvJm
4q9FYwQiSVUlYmH+Sc2qYvANnCrjJU3Eyye8zTqIoPwYPy3kdbFOKi7su3zP
5TyyKnO1GGUzBoBlc8NiQuHmd06dmHznVOFvJivJlu+RHITp1xVZ7d1QB8SZ
ozGDlHMxvvDhcFwQrVVdHlF4l2yNk5ZABrtB/QcbrlB8/E5M0Wz2FqgPSS5u
bEge5galE3bh5Fmyf1iugksnnBBV+d1oJX2SFuaVEc/BssDlLA/Di0BYKGbN
iI/TtxS4wFECc07dp+JI/g41O+24ELcNZeParRj60tkP9HXPxSXeUQMEBgQS
mubqc9Pdi4aYYiidQz+2SN3k3HC9uBKx8pPEJAre14VEEySJfXNUp8PhGNG2
CNIllfmxc7/cLOfkKVJ71KdP+Ld0Osnf1qv06dNyecGmlqJbkyoypAih8qlg
whdocGnTTHPzwQ2Twv6SE2ezZyLvg+wBWWaS6VqqtDKmxBJcPUNJJNanW++l
RqApAliYwceOCvVd936L3hAKodcSfwr0cPBzW1cVotpf+oSzNZJVQ/KBmzHb
AfQjpeLV7W+4HO9odxCCsr21FkvuYrFUVCIkxrGGD/k94htFwZbJ1NyN2Bg2
wRy11dL2ElG4KYEllMHZzzeZ+RMIXu4Yvt53Dc8D4V91HyAFTKSEXaksBJ35
twvxzlaCEzHS1lRJT8WgtnfMWvce8KMr/u57Qk8d7RAqIQOJJpbJOcXPQgJD
hPQr9/Cgqsip+qOUVDPh33SgHZkCehLO8lJOUvws5WpKf7buVmeqnX+Al8iH
Tbd7ZYnEbsXeK4RYujanwisW4Ju3aAlpiG3HYMKc8hvfE0EEsgeJZqaBEHYM
8fOTZvQEvWkbiN7Xz59a4r2MudcJqSk4Yh+BYmRa5Tw2e0TFku+4sDgKDBz8
ptcsiUloRqSAPbQuBMfQkcQpDFJJJBsTp78E/dotgbdYSmEY21VHcaxYKQ7u
yTrpXgXxQlLcbhnT1wMHL9grDChOnXsQmg6liwUAu2J7yDotjvPE6SmXTJhe
8QqaVeW8ZlqX7jHh7OM8JaSB6YiMLIpAdgRe9t3zl8+K52+eBC6X54pBTkNG
YaTG4oxtzKfK4Fsgh0qwVsruv979onOV6oilJS3PXkR3I8GKQ+mY9wmT4Efr
ts8dHwFq4gsHP4pIVp4dMvhSpbjg0KG4CmZLnALjbilojqdIEIs17YND+1FM
hoPuAVnFFNmYXKU6j4o2CiBwgQko5u1H8Gla25aMj8AWDpDE+ouEq580FY4u
wKSs9/fde1+lZh+zPQTBuGrU1+JHNKd7/vGj/vnpE0HGJ6LvGWygHbn3DrZK
nm+dBeiTBBVpTumjn5Luv57XHXWp17qV08S/6qcxTNwKGHb0gxhozYqRPWk5
94NYDMW8O4ippGv+0HUjz66oRceT34nlZKXICDI+s32ToWDuU+8XfKeuDPle
BivoWkS9cPjSVydOWN0iW0Uby1CNIRdwRsx6hm2CNDcQpPCSXK/RvQItRyBA
gkGbMhe7ZyyITJlPWKhou+3URnAahUmwsgrHBxSq1i2ntbFJmrpp/YdBn1it
NdaYD64euMS857bSsWHMUk+gAWQtbUJmdpjpMKA6ONiivm0KV5xMSDay/hOW
gKSNAgM4l+dq9XKbZztSZn1bk7jKRXWy1hcW2Ay3TIX2XLZENm6ieResRyeF
kQCDywRJdkk5nlE4z3IJiHRyfIaN0S2p6iB/5hsJStcU6Wf5FvRuSgPZiZXg
2ZYiJS33j0jvk8QSKdgpyCRQmPwWe6gdJyynIiGcB7EYLzYcWTcJxb1AM6Wf
xEsGegYeeK8Ds7VeGYLVnDzbAx9S/6A215wms6fNoBQFExhHcoEWzL09Fgys
UY+VPkHWIcnjMN+0QSPRKVNpkpx7hiX4KdFyKHEzhptbtC/t67r/AZ68mWZs
ZGeD9OJbTTgLr7MA6YROTkfco6tK4Qt3eA2pX11DL3pcDr0kKF2LcBEmCtka
y5Yp57IaBumApT8ypdekwCkd9HnWsaaJFpuVK0eSHIqhNwawLC+FN4KSTysq
5+YFs0Z88T227frthWSfY7ioVCrbZWP6SW298g2HmkNWiQg8nHDsOaks7e/b
u7vibvHgylA1anyfNZ3Tb3nqQ9JJJGN41PvN2KhX6LtRkLQLHMFlgcp0XGeR
AmYl4EfMRxqh1s77L5axWGS/1W8lxKFUkdssbRVIreTYmEuV3LNExtnMMEKp
hcDXZE/+B6cGDnxYgVsxifuYGQ02tGC/csdlcR48J0rT+apPn5g1Hz+mw2OE
FgixkPHa1IP1y/Hunwr0hTQScKXWEvPBrWENSRyb7ggLJOV8VtxdilBQ0c0A
ZkrsuwlH6h2SCGoZTEROkGle5E7t62TuOJ9KSE97zAQ+FeAHP9RyA8nCSJYR
HffS098JvuW8tOq/2JesFppNR4uVhnrGFGgOJ0ilLQZ8xPGNdH/dMkDU4qc2
Zv0/ur2U6vD+K6cPsl6vihvbXlCYVmn83JLYSX3wXAXIfyA8zk/U43g+MUNx
MJocpyd9Ek4ajo9nb8mGM6fFsnQtOYvUWjlHHjbfYLUJY+zhIYihBTPgQndP
2u5WTaplNXbqzj717YbgpcFfmMTUuyOJiXTYR9jcTkuegskH2IdBt3RP4fWQ
fNZOEgNHafGMERWFJk3D8Rn9tpJmF/FHgnW4p0/gnlgh+i9y5kgZch8wg3O3
sxNXXCEZfLlt63+O6MwiSmOeZ2UnJPQU0RfZK0pH2yqFN3ZUmlAtnTboxglO
hzwtmXEURzvptKtvTfCT3SyyOykf8Rj1dtQwxGlsO5ZL7lmMnUhsbtuRYE+L
DoB3rPfqZGTUBJMbnKyTrl2unJA/kiZsNPcM0sjQik+HYAgKSCh1ntGmTJHT
JZpl8tZCE7uLc8MizcUs9dJXLBGLRMiS/2dkz6f/zGahm3cSiMiUjV8jEsRO
W9yp9WLLETfdYKcIdikrl+d61l1vzU4j7BVqDZYJjxkflrvYvYDagLTOa2OZ
ZsdJFwjoIexDG6NriDGpB+DQg4iMc+dbbukDAZuOj7eR7ysH6YCUNNiR1+EJ
K0OjpA86ZIkd7ra+adFS1vGpJzu6loL7qTLTAOQcooRz7JsoEutqcEfeNXO4
c8RWQa3cKY0QBzPH821pymxEbuOmbSmbUQ6GZUVnafvX2lak8jye3cLBiOFi
UmqapgFWPpcU2AulLKRAfU1Yw+047mDGHlMaJB7zM21WMrOTLgjkH797/vTB
o59/4EienMwrhh2641akvrZDie9rzrc57Y7gZjnSqZgZIAj3uPj4nWUHrDXZ
alluhRQ9oIQU1NQJmYNafrEUnlWqYtVf8jLWjP0HjC2fsLmVYDY1SMnnDho5
bZ3Nk8/iV/QAwDz/Sc83Tc58raOhiWM/nv2DK7d8e0EzrdtqCqYNh9Reltvk
tlvq18OEV+wgRFTq9o+xLVP6QAfTAPZozlgMdN7tqpKIGsLjySuSt499XeT1
VVXVndt8/GnxhT5a6UFSPpDM9f4kNwWr/tJizU2s2Meck1MaLGi0bP+cRY1L
PYOVzDkcnqsQI+2u+VAB5hbPT0nNJ/2e2/z342A9u+33g3UCc7oIv5Jjr8mX
pfa4dECOOP0H5LXfjFpMVQPTcXqc5vGh7LvDtQId/G3rraVXy0nb/7bebFGe
GU2vWef+Nk2z8RavpD55y730p3okFhQGe+SCKUI0qJ/0D1D4BX7Etlyx4pNa
WUznMH81e4VuRYFBqgiTLQ9ZupBAAV58JkBeCqLaN4V5d50VYE6mtVXJCQE4
3iBfplIiEdtqRl9QkjWGPkaHAR/bbI7Xp5ZASlCTuZKsSmbDKgE+WwcRinU8
t6DnZMq5VG557NOODSs1cxawiwZQFXxqazRAOEnDTvpeuYHiMDcXYpTozkbN
lzPUXLnRD89kOdIPCE/NFwb8y2nj5zMI4G/aKhNPvEi3sgA9OSeWn7hOB2Pi
IYjTw9Jc+GgLjrjhjdDSItew+JRR1UPeMTwuNl1XZXPlEIW8GuSDvZwQy8iT
+CU+7OdHj/4qZVa5HAZ/42tgn5maqXpHoUBv2RDBfZKUsdLB3rJVUFfCiMCD
heTrzvZXiJ7OUoeLFd+0Qb9LNxbYWbKUVB2jhT8pkiZQldih6iegiF2+ZNAJ
bbSn38uM8+z8rvSiSt4y3m8xNogkpbpqQiudQnEKSyYJg8tOk012CQNS1FL0
upWV+j17PBMK2ZZBjYDcDpE4Erv6LaJXQ54vh0cIdl9Q/JQmDcjG0oLuczJ5
5+ztOptrupBsDfAqsvgDn6mMdwAQVd1KqlF8mQBxXs+yi4/2H9AyGlLpBxcA
WCJrCg4kDL/DiaPiLfoUEORCYW8sSgTqutU6308YRC82EgT21K6gaKNBq3xZ
y4lRqY5m56sZqTA0kj+j9VvX/e4gIUfGgWVx/lqPLMTsAP9aB3jHeEYRz54/
eclE8M0p16RXdrEKsjiwmKysHIlW3N4Rr6lg5JLiqWI47nkXZccQokbq0hHP
rArMwq49HpW1zgsLCusZ6uRM0Je1QZrbobZ1lieMk2YFSkY7YqNqH1MVmpTm
M7VxaGJw03jmsQoBjlVxyKBtgcWqqxs+3wIa17Xw19nlAypE/Cmi8yFfj5fA
LbOYdYguRBfJWOG/9UtJPb3Zo1Q5tkz+LDutm+UZY648c4mA4BK5a1YS0RBC
37xYH7crUcsnYZlkWsuAFkfGYMQlaIRsvZ5cp/gpNbuLMZLz2lYomvSCyPHF
XptcFVXK+2x5VhxIxzJNYIifpprdxA7cSKyckuGhTlhgN21ITXlEsKMRlh3t
ilc5cL9L6GLyKHTNmIodk1Gz46KSdonNymlYo5gPx/fWPWxVU53aslt8FUIs
XE8OYuRFK6XthBrlMta3amV1CKdv9CA6oTDZYb7m4xhLs0KCtbBwjsmmje1X
yJc2bp+KtNm06rAPFuZIn1aG79Dt3VhDn3EjO0yp12Wk8y04zcMfWZILrVrQ
OjyUPEuWJsqYldVmcUsYWZInU8WXaLQCXq/3EWMFi781Xr7O4KDgVuDCD4v4
t5QoL63ZQjL2lyxWcp0N94pyyn2RiimpcIQYApLPRzIXdl72Ug7FzmeuIqib
HpNW1JCfpXIjZSPmmqeRC2KsVd0sYmJMyJs1wEy7jeRUhpZF8ZKiHL4IY12c
Lgj7RIYKGQU7nz/nsmLHTcK/vMNBflbObBBeRvp28Ol874KM+mLV9T2qYMSL
nrM+tukvf7l7zn5BLkqoJm3lUxcc4Z000iI7rk0ft2///lLh4sO/PPoLIOKb
m3/cvXioD3/86YdHeHgzGY+s/VM5icbe5Jf2viYWcTZYPvvppx9+wGe4XQvO
PV70FUsg/NZfHz5kF383vV9HjpJea4t0dE+d+RioEPwIzco3KKQox8Vn5FeI
YbTN5xbnzouDX8XncxyWvrDOMg6x8tamdJVUNnZ8aIPo4TMJQ7S3m2WYD6px
24ycq+Ejinp684Oc0CKpIhXE9VMUx6lFtV649BPRrE12se8MrmEH+ymOku/B
0ROX7tSrPZ691Zs4HJAMLFjmDK5j4CB85SudNEvPuLPkBtBaHI62zu+d9iLm
1WaN7PUQHwlJWNearjDbJDV7yx4gVmVFgRoBxUvfbojZjMfw7G/RMFweWdjI
akrYF/Jm6kmi+eRaCc22xg3RyjXfZiLtoi6g6dEawLk2hfT3hdw5oJ8rDSkT
lA4XAvLhltJg5vSkvA3sL54EMtDzscLTg6H5ltmFFwgJ+PYVRXWGelQYT88B
Z6eAOQGkEBJ4XnMBpdwBVQt2X6Mei56cLPrFAY+c4M+PsJ64NRY9uVvp+xiL
kmPY8W0hWaOCC8ZKbV0vzm9HbSEI5uc43U7Tnrmwr2WfXXPGtdF8h3f1B7Zu
ektfDlTPz2AUbycm2cTtiVYTzy4Ayzu7H2of/Fh17XEH+cyGMnhlOr3kjEC8
PPBzaUS9gDc43dRS2x0WnI3b4zy9XaLxFduMG/FuXt98eXgbN7CAcBjNL7/z
rM/y+U0Z7/7jd2ezF54kh397ysFQ021mcg0fUt68rLfmIZ9JrJJrFyy9Nczm
PTQa1UxrIbKRbKzEUtfxHBZnCrkJgB7vJH5h4WHGVU1MG20AqDhgJKbs0f7E
2X1u8T64odxqu3fv2elJP845YfW+rP8kvd16lNd2FF7qhUhbjm8JgkaPh8Cu
QRPQOYR6PTJ1qX8/lJ00opMQSQ5istqIysg6IxdRjC1Hnlw/CtYsbZ+ILrHA
ya14Hvf/kEGUG/KMdaddMWiPJXSw2PG9CmQFAAiGBS5ZklMnhBnQBko/aZnq
fQ3etKnCR7A29jihAs+VkbqVU8ERpRoSEq03dAiXZefcQUeyfdzchuE4vPhs
UjKjBZlPzusAb+FKrQPJw8VUNvhwtbiwJFNZ0kfaCM7ZT3zlGpMLiYq4Ep/O
A0oKjH3tkLXYS4YwnXDJK8ORdk6yI5sytws+tCi2J0e/ZfwBLoxBEyvwztxo
YWyIt2Uwo76+LqWJ6yl2uwlpBpkZrXfKawc5QqQV88Ri3h9hy0THXMPdfkHy
5oYR4ZZSDG/BucwQuxyHrL2CfNvYbOx4iWYipIbOBdJBB7Ux82NCkn0c8oSv
dRqotJMrJVSO9AzL5DkHCBfzKF+c45XEhGQK5BKgDpffvM9zb3ptASemwuQ4
hcd1kdpt98UMbE6FVlEkKaptXyyk3A7LbLJeXs6tpEhKvST5hyGLOrUJPbv9
AFdfVD4/S4O2V+77z9wakBbXP3d79GMvJ02E82hOUPRs0pns2BpjvcnAgFy1
Es8joax0KMmW34fYAB9tgN7u2fCllvIyP+ZOU9yTKf1v0UIq/1+YtnBDOxs4
rr5QUGtFYCQ8BRzIjT2CZawSktpXS83tcG+K0IH6sGstK5s93pAN5D5U3CzS
es2Es/USOY57b6fY9Fiy1shGsuoNN9jihm5ROAkreRBU5lG2Y/7BiESWDlu+
8IRkAzdK8EUj7iBd+pZgOue49GJyGRJfhoBcaivSIBdOAHtl9x7pU9z5LJmk
M9qUs0kuW7qKjqwYek2IyPZMqY/HE1MVoShedweG+I+LZ1Y9jKogJ/3YxGtj
uLFMBgTU13inOeo1GkjbxZxOqmZq8TVWtJBDyHNOrSWLtIYpeUrOq5WAxta3
ux4ex/JXuvWBf5D1Hnx0UnzAgffp8YwXx06MI5xaL8DlUf79r1cTqeTb4ujx
j1dXRAGnHzvzqI9nb3qGygfrO4IscPqeRACXPQ1b+gAO6HFRFHdMGKd2vzhc
1oov1V3NsXHbM3fYask+iVDTBU0WT+jOh+OhNGxd1Zt0s+z/AU16iMn/YQAA

-->

</rfc>
