<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version  -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>


<rfc docName="draft-amsuess-t2trg-rdlink-01" category="exp">

  <front>
    <title>rdlink: Robust distributed links to constrained devices</title>

    <author initials="C." surname="Amsüss" fullname="Christian Amsüss">
      <organization></organization>
      <address>
        <postal>
          <street>Hollandstr. 12/4</street>
          <code>1020</code>
          <country>Austria</country>
        </postal>
        <phone>+43-664-9790639</phone>
        <email>christian@amsuess.com</email>
      </address>
    </author>

    <date year="2019" month="September" day="23"/>

    
    <workgroup>T2TRG</workgroup>
    <keyword>CoAP, , Resource Directory</keyword>

    <abstract>


<t>Thing to thing communication in Constrained RESTful Environments (CoRE) relies on URIs to link to servers.
Next to hierarchical configuration and short-lived IP addresses,
this document introduces a naming scheme for devices based on cryptographic identifiers.
A special purpose domain is reserved for expressing those identifiers,
and mechanisms for constrained devices to announce their names
and to look them up are described.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>Communication between constrained devices using the CoAP protocol largely happens in either of two scenarios at the moment:
local networks with static IP addresses,
and communication mediated by dedicated servers.</t>

<t>Direct communication between constrained devices across the Internet
is currently an exceptional setup,
and usually involves static configuration or bespoke mechanisms.</t>

<t>Direct communication with a CoAP severs is often guided by web links
which point to the URI that both names the server (and a resource on it),
and indicates how that server can be reached.
Such links often indicate registered name
which is typically looked up in the DNS hierarchy
and thus relies on the operator to own and administer a domain,
If they don’t, they indicate an IP address;
such links are of limited use for stable identifiers,
e.g. due to mobile endpoints.</t>

<t>This document introduces a special purpose domain
(rdlink.arpa)
along the mechanisms with which it is used
(employing a Distributed Hash Table (DHT)).</t>

<t>Constrained devices can announce and look up addresses
without direct interaction with the DHT
by interacting with a distributed resource directory
(<xref target="I-D.ietf-core-resource-directory"/>).</t>

<t>Resolvable names are provided for compatibility with applications that are unaware of these provisions.</t>

</section>
<section anchor="terminology" title="Terminology">

<section anchor="participants" title="Participants">

<t>This document uses several roles of devices:</t>

<t><list style="hanging">
  <t hangText='named server'>
  A CoAP server owns a name in the special purpose domain.</t>
  <t hangText='name user'>
  A CoAP client that needs to resolve a name in the special purpose domain.</t>
  <t hangText='registration helper'>
  A server that assists constrained named servers in announcing their names.</t>
  <t hangText='lookup helper'>
  A serve rthat assists constrained name users in finding the named server.</t>
  <t hangText='DHT participant'>
  Any device that is a node in the DHT overlay network.</t>
</list></t>

<t>Often, named servers act as name users towards other servers.
The roles of registration helper, lookup helper and DHT participant
are expected to be implemented together in typical use cases.</t>

<t>Note that a named server can act as a CoAP client towards a name user
that has ongoing communication with it
without being a name user on its own
by just addressing the client on its own.</t>

</section>
</section>
<section anchor="auxiliary-mechanisms" title="Auxiliary Mechanisms">

<t>This section describes mechanisms
that are expected to be specified in different documents,
which will then only be referenced.</t>

<section anchor="the-coapat-scheme" title="The coap+at scheme">

<t>It is assumed that the CoRE working group at IETF
will register a URI scheme <spanx style="verb">coap+at://</spanx> that can be used with DNS names,
and that allows expressing CoAP URIs independent of the used transport.</t>

<t>The mechanisms outlined in <xref target="I-D.silverajan-core-coap-protocol-negotiation"/>
are assumed to be one way of finding protocol URIs
(e.g. <spanx style="verb">coap+tcp://...</spanx>)
that correspond to <spanx style="verb">coap+at</spanx> URIs
when they are known to a Resource Directory.</t>

</section>
<section anchor="the-alternative-transport-link-relation-type" title="The alternative-transport Link Relation Type">

<t>It is assumed that <xref target="I-D.silverajan-core-coap-protocol-negotiation"/>
will have a parameter equivalent to the following:</t>

<t>This defines the <spanx style="verb">alternate-transport</spanx> Link Relation Type.</t>

<t>A link from a context resource to a target resource typed with the <spanx style="verb">alternative-transport</spanx> type
declares that for any relative refernce of the path-noscheme or path-empty form
(see <xref target="RFC3986"/> Section 4.2.),
the reference’s resolution with the context as a Base URI
can be substituted with
the reference’s resolution with the target as a Base URI.</t>

<t>The expression “can be substituted with” means that
for every REST operation conducted on the original resource,
the same operation on the new resource
will give equivalent responses and have equivalent side effects.</t>

<t>Applications interpreting <spanx style="verb">alternative-transport</spanx> links need to carefully consider their trust model:
They MUST either have obtained the statement from a source that is trusted to speak for the context authority,
or make additional demands on the target when connecting to it
(e.g. ask the target to identify as the context authority).</t>

<t>[ If applications are defined for both CoAP and HTTP,
and advertised the same way,
hosts can onlly advertise alternatives if cross-proxying is possble;
needs good generic phrasing. ]</t>

<t>This link relation is roughly equivalent to the <spanx style="verb">at</spanx> RD parameter
introduced in <xref target="I-D.silverajan-core-coap-protocol-negotiation"/>,
but suitable for multicast discovery.</t>

</section>
</section>
<section anchor="the-rdlinkarpa-special-purpose-domain" title="The rdlink.arpa special purpose domain">

<t>The domain rdlink.arpa is reserved to represent devices by their cryptographic identifer
(described using the “cryptident” ABNF of the next section).</t>

<t>The rdlink.arpa domain does not provide DNS records for those names,
but serves as a plain name for devices eligible to use their cryptident.</t>

<figure><artwork><![CDATA[
hostname = cryptident ".rdlink.arpa"
]]></artwork></figure>

<t>Names from this domain should probably only be used with the “coap+at” scheme,
like this (assuming a host’s cryptident is “nbswy3dpo5xxe3denbswy3dpo5xxe3de.ab”):</t>

<figure><artwork><![CDATA[
coap+at://nbswy3dpo5xxe3denbswy3dpo5xxe3de.ab.rdlink.arpa/.well-known/core
]]></artwork></figure>

<section anchor="cryptident-construction" title="cryptident construction">

<figure><artwork><![CDATA[
cryptident = [ ext-ident "." ] cryptmain "." crypttype
]]></artwork></figure>

<t>The <spanx style="verb">cryptident</spanx> component describes a name under
and describes a cryptographic identity the host can show, e.g. a public key, or
the hash of a certificate.</t>

<t>The cryptmain component is base32 encoded binary data
(as in <xref target="RFC4648"/>, but lower case and without padding).</t>

<t>The crypttype is a registered designator for the meaning of cryptmain and ext-indent,
which initially only has one value:</t>

<t>[ Names are currently given with the same encoding as cryptmain to map to numbers,
that may be a good or a bad idea. ]</t>

<t><list style="symbols">
  <t>“ab”: cryptmain is a 160bit number that represents an ed25519 public key.  <vspace blankLines='1'/>
A host proves being eligible to use this name by performing an EDHOC exchange
in which the host demonstrates the ability to use that key as a Raw Public Key.</t>
  <t>“ac”: cryptmain is the 256bit hash value of a certificate using hash algorithm TBD.
(Longer hashes would need changes in how this is put into DNS compatible names)  <vspace blankLines='1'/>
A host proves being eligible to use this name by performing an EDHOC exchange
in which it demonstrates possession of the secret key indicated in the certificate.</t>
  <t>“ad”: Like “ac”, but referring to any certificate in a chain.  <vspace blankLines='1'/>
For this crypttype, the common names in a certificate chain are concatenated
[ how exactly is TBD ]
into an ext-ident.  <vspace blankLines='1'/>
A host proves being eligible to use this name by performing an EDHOC exchange
in which it demonstrates possession of any certificate
together with a certificate chain to a certificate with the given hash
where the certificate chain gives the claimed ext-ident name.</t>
</list></t>

<t>[ Whether OSCORE’s <spanx style="verb">ID_CRED_x</spanx> can be used in encoding this,
or whether those can be substituted by a concept from HIP
is up to further research;
the rest of the document does not depend on the details of this construction. ]</t>

</section>
<section anchor="equivalent-resolvable-names" title="Equivalent resolvable names">

<t>For compatibility with devices that do not support
the role of a constrained name user or even the coap+at scheme,
resolvable names can be provided under a regular domain:</t>

<figure><artwork><![CDATA[
coap://nbswy3dpo5xxe3denbswy3dpo5xxe3de.ab.rd.link/.well-known/core
]]></artwork></figure>

<t>Note that a domain can only support a single non-coap+at scheme,
as the addresses used by a named server for coap and coap+tcp may differ.
The name servers for this domain
would use the method described in <xref target="lookup-dht"/>
to arrive at A/AAAA results.</t>

<t>Any equivalent URIs here create the issue of aliasing
(see <xref target="RFC3986"/> Section 6).
No more than two different names should be available for a device when this document has stabilized
(and even that number would need to be justified,
e.g.  because one version leads to enhanced backwards compatibility
while the other has different benefits).</t>

</section>
</section>
<section anchor="announcing-addresses" title="Announcing addresses">

<t>A named server has several ways of making itself available to clients:</t>

<section anchor="announce-dht" title="Direct announcement">

<t>Protocol-qualified transport addresses for cryptidents
are announced by placing an entry in a global Distribuetd Hash Table (DHT).</t>

<t>The details of this are not yet laid out for this document,
but <xref target="I-D.jimenez-t2trg-drd"/> already describes such a mechanism.</t>

<t>Entries in the DHT would contain:</t>

<t><list style="symbols">
  <t>Key: the cryptident</t>
  <t>Value:
  <list style="symbols">
      <t>URLs that are alternative transports to the entry’s coap+at://…rdlink.arpa URI</t>
      <t>A time stamp of the registration and its lifetime</t>
      <t>If the cryptident alone is insufficient to verify signatuers from it:
additional information on the cryptident,
eg. a certificate (chain) for “ab” and “ac”.</t>
      <t>If available in the crypttype:
A signature on on the rest of the value,
signed by the owner of the cryptident.      <vspace blankLines='1'/>
As a registration helper can not provide such a signature,
instead of a signature on the entry there can be
a signed datum that proves
that the announcer was contacted by the identified device
at a given time using the RD registration interface.</t>
    </list></t>
</list></t>

<t>DHT participants and lookup helpers should verify the signatures on entries they propagate,
but may do so only occasionally,
or only when they detect duplicate entries.</t>

<t>For the signatures in which the registration helper creates a signed datum,
it may make sense to use an unpredictable timestamping scheme
(eg. the latest headlines from a widespread newspaper,
or the head hash of a given block chain)
to prevent malicious RD servers
from staying in control of the route to a given cryptident
even after that device has picked a different RD server.</t>

</section>
<section anchor="announce-rd" title="Announcement via a registration helper">

<t>Constrained named servers can enter their announcement
by executing the RD registration operation (<xref target="I-D.ietf-core-resource-directory"/> Section 5)
on a registraiton helper.</t>

<t>The registrant (= constrained named server) does not need to send a cryptident or other endpoint identifier;
the helper will construct the cryptident from the chosen authentication method
and construct an endpoint name from it.</t>

<t>The registrant may send a base URI
(but may just as well rely on the RD (= the registration helper) to announce its network address).
An alternative transport option
(at=; <xref target="I-D.silverajan-core-coap-protocol-negotiation"/> Section 4.1)
indicating the coap+at rdlink.arpa URI constructed from the cryptident
is implicitly configured by the RD.</t>

<t>While performing the authentication step,
the RD ensures that the registrant signs a timestamp and its IP address
by embedding them in the <spanx style="verb">OSCORE C_V</spanx>.
[ Or something similar, this part is still very experimental. ]</t>

<t>The registrant may submit discovereble resources with its registration,
but it is exepcted that most clients will only reveal them later
to authenticated clients.</t>

<section anchor="finding-a-registration-helper" title="Finding a registration helper">

<t>The registrant can find a registration helper
at the anycast address TBDv4 or TBDv6.
The helpers work in “distinct registration point” mode
(cf. <xref target="I-D.amsuess-core-rd-replication"/> Section 6.2),
but do not implement the anycast variation suggested there in Section 6.2.2,
but rather give their explicit unicast addresses in a full URI during path discovery
to ensure that updates wind up with them.
[ That should be added there in an updated rd-replication document ].</t>

</section>
</section>
<section anchor="announce-multicast" title="Local announcement">

<t>To enable the use of coap+at rdlink.arpa URIs even in absence of an announcement server
(eg. on ad-hoc networks),
endpoints should join the link- and site-local All CoAP Nodes groups,
provide an alternative-transport link to their own address,
and answer to filtered multicast requests as described in <xref target="RFC6690"/>:</t>

<figure><artwork><![CDATA[
Req: GET coap://ff02::fd/.well-known/core?href=coap+arpa://nbswy3dpo5xxe3denbswy3dpo5xxe3de.ab.rdlink.arpa&rev=alternative-transport

Res: 2.05 Content
<coap+at://nbswy3dpo5xxe3denbswy3dpo5xxe3de.ab.rdlink.arpa>;rev="alternative-transport"
]]></artwork></figure>

</section>
<section anchor="not-announcing-addresses" title="Not announcing addresses">

<t>A named server is under no obligation to make its name publicly visible,
especially when it is not expecting to host services.</t>

<t>The generated name can still be of use:
It can be used in direct communication
that the device has initiated in the role of a CoAP client with a different server.
When that server accesses the named server under role reversal,
it can address it by a rdlink.arpa name.</t>

</section>
</section>
<section anchor="finding" title="Lookup of rdlink.arpa URIs">

<t>A name user has several ways of finding transports of an rdlink.arpa URI:</t>

<section anchor="lookup-dht" title="Direct lookup">

<t>Alternative transport URLs for a given coap+at rdlink.arpa URI
can be looked up in the DHT described in <xref target="announce-dht"/>;
this mechanism is only conveniently usable by unconstrained devices.</t>

</section>
<section anchor="rd-lookup-based" title="RD lookup based">

<t>Analogous to <xref target="announce-rd"/>,
clients can perform endpoint lookup to find alternative transport URLs for a given coap+at rdlink.arpa URI.</t>

<t>Clients look up actual transport addresses based on a filter on the alternative transport attribute
(eg. by requesting <spanx style="verb">coap://[2001:db8::1]/rd-lookup/ep?at=coap+at://nbswy3dpo5xxe3denbswy3dpo5xxe3de.ab.rdlink.arpa</spanx>),
and can specify the transport they are looking for
using the transport type query parameter
(tt=; <xref target="I-D.silverajan-core-coap-protocol-negotiation"/> Section 4.2).</t>

<t>Note that due to the distributed nature of this directory,
lookups that do not specify an cryptident based URI can not be performed
(as that would mean iterating through all published entries in the DHT);
such requests are probably best answered with 4.00 “Bad Request”.</t>

</section>
<section anchor="local-lookup" title="Local lookup">

<t>Alternative transports to a coap+at URI
can be discovered using multicast;
see <xref target="announce-multicast"/> for an example.</t>

</section>
</section>
<section anchor="operation-considerations" title="Operation considerations">

<t>While the DHT can be run with very little management
(probably just managing bootstrap servers),
running the helpers at the anycast addresses will need some degree of management.</t>

<t>Steps to involve multiple parties in hosting such RD servers
and policies that guide which of these servers are announced on the anycast addresses
are to be developed in parallel to this document.</t>

<t>Device vendors may operate their servers under additional addresses,
but are encouraged to join in the server pool.
Devices may be configured to query such vendor servers by default,
but need to use the public ones at least as a fallback.</t>

<t>Note that in private networks,
operators may run their own helpers
at the anycast addresses.
If communication with other DHT nodes is not possible
or administratively prohibited,
discovery across such border is blocked,
but the addresses used are still persistent,
and discovery between services on the local network is unaffected.</t>

<t>While helpers may offer the proxy extension
(<xref target="I-D.amsuess-core-resource-directory-extensions"/>),
it is not expected that the public RD servers
will offer that feature.</t>

</section>
<section anchor="iana-considerations" title="IANA considerations">

<t>[ TBD: alternative-transport ]</t>

</section>
<section anchor="security-considerations" title="Security considerations">

<t>Alternative transports:
“trusted to speak for” is usually not any resource on the device</t>

<t>[ … ]</t>

<t>…</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor="RFC3986" target='https://www.rfc-editor.org/info/rfc3986'>
<front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials='T.' surname='Berners-Lee' fullname='T. Berners-Lee'><organization /></author>
<author initials='R.' surname='Fielding' fullname='R. Fielding'><organization /></author>
<author initials='L.' surname='Masinter' fullname='L. Masinter'><organization /></author>
<date year='2005' month='January' />
<abstract><t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource.  This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet.  The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier.  This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='66'/>
<seriesInfo name='RFC' value='3986'/>
<seriesInfo name='DOI' value='10.17487/RFC3986'/>
</reference>



<reference  anchor="RFC4648" target='https://www.rfc-editor.org/info/rfc4648'>
<front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author initials='S.' surname='Josefsson' fullname='S. Josefsson'><organization /></author>
<date year='2006' month='October' />
<abstract><t>This document describes the commonly used base 64, base 32, and base 16 encoding schemes.  It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4648'/>
<seriesInfo name='DOI' value='10.17487/RFC4648'/>
</reference>




    </references>

    <references title='Informative References'>





<reference anchor="I-D.ietf-core-resource-directory">
<front>
<title>CoRE Resource Directory</title>

<author initials='Z' surname='Shelby' fullname='Zach Shelby'>
    <organization />
</author>

<author initials='M' surname='Koster' fullname='Michael Koster'>
    <organization />
</author>

<author initials='C' surname='Bormann' fullname='Carsten Bormann'>
    <organization />
</author>

<author initials='P' surname='Stok' fullname='Peter van der Stok'>
    <organization />
</author>

<author initials='C' surname='Amsuess' fullname='Christian Amsuess'>
    <organization />
</author>

<date month='July' day='8' year='2019' />

<abstract><t>In many IoT applications, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient.  These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources.  The input to an RD is composed of links and the output is composed of links constructed from the information stored in the RD.  This document specifies the web interfaces that a Resource Directory supports for web servers to discover the RD and to register, maintain, lookup and remove information on resources.  Furthermore, new target attributes useful in conjunction with an RD are defined.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-core-resource-directory-23' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-core-resource-directory-23.txt' />
</reference>



<reference anchor="I-D.silverajan-core-coap-protocol-negotiation">
<front>
<title>CoAP Protocol Negotiation</title>

<author initials='B' surname='Silverajan' fullname='Bill Silverajan'>
    <organization />
</author>

<author initials='M' surname='Ocak' fullname='Mert Ocak'>
    <organization />
</author>

<date month='July' day='2' year='2018' />

<abstract><t>CoAP has been standardised as an application-level REST-based protocol.  When multiple transport protocols exist for exchanging CoAP resource representations, this document introduces a way forward for CoAP endpoints as well as intermediaries to agree upon alternate transport and protocol configurations as well as URIs for CoAP messaging.  Several mechanisms are proposed: Extending the CoRE Resource Directory with new parameter types, introducing a new CoAP Option with which clients can interact directly with servers without needing the Resource Directory, and finally a new CoRE Link Attribute allowing exposing alternate locations on a per-resource basis.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-silverajan-core-coap-protocol-negotiation-09' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-silverajan-core-coap-protocol-negotiation-09.txt' />
</reference>



<reference anchor="I-D.jimenez-t2trg-drd">
<front>
<title>A Distributed Resource Directory (DRD)</title>

<author initials='J' surname='Jimenez' fullname='Jaime Jimenez'>
    <organization />
</author>

<author initials='M' surname='Liu' fullname='Meirong Liu'>
    <organization />
</author>

<author initials='E' surname='Harjula' fullname='Erkki Harjula'>
    <organization />
</author>

<date month='March' day='19' year='2018' />

<abstract><t>NB: This document was submitted in 2013 and then discontinued.  It is now submitted to T2TRG for discussion on the replication of the Resource Directory.  References and many operations would need updating.  Architecture and functions should remain the same.  In some M2M scenarios, it is convenient to offer non-centralized alternatives for discovery and rendezvous.  This document defines a Distributed Resource Directory (DRD) for Constrained Application Protocol (CoAP).  Distribution is achieved by means of a structured Peer-to-Peer (P2P) overlay.  The DHT-based P2P overlay provides discovery, rendezvous and caching services for CoAP End-points as well as HTTP proxy service for Web clients.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-jimenez-t2trg-drd-00' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-jimenez-t2trg-drd-00.txt' />
</reference>



<reference anchor="I-D.amsuess-core-rd-replication">
<front>
<title>Resource Directory Replication</title>

<author initials='C' surname='Amsuess' fullname='Christian Amsuess'>
    <organization />
</author>

<date month='March' day='11' year='2019' />

<abstract><t>Discovery of endpoints and resources in M2M applications over large networks is enabled by Resource Directories, but no special consideration has been given to how such directories can scale beyond what can be managed by a single device.  This document explores different ways in which Resource Directories can be scaled up from single network to enterprise and global scale. It does not attempt to standardize any of those methods, but only to demonstrate the feasibility of such extensions and to provide terminology and exploratory groundwork for later documents.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-amsuess-core-rd-replication-02' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-amsuess-core-rd-replication-02.txt' />
</reference>



<reference  anchor="RFC6690" target='https://www.rfc-editor.org/info/rfc6690'>
<front>
<title>Constrained RESTful Environments (CoRE) Link Format</title>
<author initials='Z.' surname='Shelby' fullname='Z. Shelby'><organization /></author>
<date year='2012' month='August' />
<abstract><t>This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links.  Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type.  &quot;RESTful&quot; refers to the Representational State Transfer (REST) architecture.  A well-known URI is defined as a default entry point for requesting the links hosted by a server.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6690'/>
<seriesInfo name='DOI' value='10.17487/RFC6690'/>
</reference>



<reference anchor="I-D.amsuess-core-resource-directory-extensions">
<front>
<title>CoRE Resource Directory Extensions</title>

<author initials='C' surname='Amsuess' fullname='Christian Amsuess'>
    <organization />
</author>

<date month='July' day='22' year='2019' />

<abstract><t>[ See Introduction ]</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-amsuess-core-resource-directory-extensions-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-amsuess-core-resource-directory-extensions-01.txt' />
</reference>



<reference anchor="I-D.ietf-hip-rfc4423-bis">
<front>
<title>Host Identity Protocol Architecture</title>

<author initials='R' surname='Moskowitz' fullname='Robert Moskowitz'>
    <organization />
</author>

<author initials='M' surname='Komu' fullname='Miika Komu'>
    <organization />
</author>

<date month='February' day='14' year='2019' />

<abstract><t>This memo describes the Host Identity (HI) namespace, that provides a cryptographic namespace to applications, and the associated protocol layer, the Host Identity Protocol, located between the internetworking and transport layers, that supports end-host mobility, multihoming and NAT traversal.  Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a HI namespace will add completeness to them.  The roles of the HI namespace in the protocols are defined.  This document obsoletes RFC 4423 and addresses the concerns raised by the IESG, particularly that of crypto agility.  The section on security considerations describe also measures against flooding attacks, usage of identities in access control lists, weaker types of identifiers and trust on first use.  This document incorporates lessons learned from the implementations of RFC 5201 and goes further to explain how HIP works as a secure signaling channel.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-hip-rfc4423-bis-20' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-hip-rfc4423-bis-20.txt' />
</reference>




    </references>


<section anchor="change-log" title="Change log">

<t>Since -00:</t>

<t><list style="symbols">
  <t>Add point about DNS as a substrate rather than RDs, and semi-hierarchical lookups</t>
  <t>Add point about name evolution (considering trackability)</t>
  <t>Add references to more prior art and involved parties</t>
</list></t>

</section>
<section anchor="ideas-for-the-future-of-this-document" title="Ideas for the future of this document">

<t><list style="symbols">
  <t>Add a note on how to deal with PSK cases  <list style="symbols">
      <t>Often the PSKs will stem from a previous RPK or certificate process,
in which case that base URI persists.</t>
      <t>If not, how did HIP deal with them?
We could sure look them up in the DHT,
but anyone may spam them.</t>
      <t>If it gets established in EDHOC
that the implicit Uri-Host values in an EDHOC-derived PSK pair
are the original key material’s (which’d make sense IMO),
does this affect the usability of implicit base in <xref target="announce-rd"/>?
(After all, the implicit role inversion address would be coap+hash:// then.)</t>
    </list></t>
  <t>Add notes on TLS/DTLS  <vspace blankLines='1'/>
Conceptually all of this should work on TLS/DTLS as well.</t>
  <t>Like CoAP RD is a way to access the DHT RD, so can be DNS if one wants to implement it
and it is defined for coap+at;
lookups would be just whatever coap+at does,
and a helper can be implemented to accept DNS record updates.
Clients could use it just as well,
verifying DHT participants would just need to check another proof type.  <list style="symbols">
      <t>Checking more proof types is something where using mobile code might at some point in time become interesting.</t>
    </list></t>
  <t>Same principles can be applied to proving possession of other domains’ names  <vspace blankLines='1'/>
Domains might configure their DNS servers to serve a part of the cryptident (needs to be full authorities then) space,
and announce in DNSSEC that say for $DEV.devices.example.com, the PoP for that name needs to follow some certificate chain.</t>
  <t>Describe name evolution:
server may announce <spanx style="verb">&lt;:hash1&gt; alternative-transport &lt;:hash2&gt;</spanx> for some time to authenticated clients,
and at some point in time start announcing the latter and only announce the former
(stable URIs vs. trackability)  <vspace blankLines='1'/>
could also announce several addresses for different clients – describe trade-offs</t>
</list></t>

</section>
<section anchor="existing-approaches-that-dont-solve-the-complete-problem" title="Existing approaches that don’t solve the complete problem">

<t><list style="symbols">
  <t>IPv6 stable mobile addresses  <vspace blankLines='1'/>
Didn’t take off.</t>
  <t>HIP / ORCHIDv2  <vspace blankLines='1'/>
Feasible alternative, nice CIRI-compact addresses.
Stack support unclear.
Not extensible to sub-names (dev123.HASHHASHHASH – or can it, with notarized identities?).
Hard limit on hash lengths (eg. Tor went from 80bit to 160bit, can’t do that).  <vspace blankLines='1'/>
Using them at application layer only might be an option (cf. <xref target="I-D.ietf-hip-rfc4423-bis"/> last paragraph of introduction)
See whether HIP’s DoS protection can be applied in EDHOC.  <vspace blankLines='1'/>
Keep reading.</t>
  <t>RD-DNS-SD  <vspace blankLines='1'/>
Hierarchical or limited to link-local.</t>
  <t>TOR  <vspace blankLines='1'/>
basically got it right, just that we don’t do onion routing here, and pull protocol negotiation in.  <vspace blankLines='1'/>
(might even consider 1:1 using their addresses, or at least take much from the discussion at https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt -&gt; ONIONADDRESS-REFS); given we’re likely never to write addresses by hand, checksumming might be left out, and version move to “domain”.</t>
  <t>IPFS / IPNS  <vspace blankLines='1'/>
Doesn’t integrate well into URIs. Uses a concept of multihashes that has inspired the current cryptident design.</t>
  <t>RFC6920 (ni hashes):  <vspace blankLines='1'/>
Only identifies the hashed or public-key-signed content, but does not make it usable for REST operations or short (relative) names of different resources provided by that content / host.  <vspace blankLines='1'/>
Its named information hash registry could serve as a template, but is probably too specific as it rules out RPK identifiers.</t>
  <t>DIDs:  <vspace blankLines='1'/>
Not used directly in addressing, but they may be usable as a replacement for cryptmain.crypttype.</t>
</list></t>

<section anchor="links-for-further-research" title="Links for further research">

<t><list style="symbols">
  <t>GNS (eg. as presented on IETF104: https://youtu.be/xXWzgn-dxrk) can be valuable input, esp. on verifying results w/o reading them. They have both crypographic global identifiers and “trust-local”(?) ones, the latter are probably not relevant here.</t>
  <t>DINRG should possibly be involved.</t>
</list></t>

</section>
</section>


  </back>

<!-- ##markdown-source:
H4sIAKCmiF0AA7VcbXPbxrX+jl+BK9+5FluSkmXHN6abuIokx5qktkdSmjvT
ZqIlsCQRgQCKBSSzHv2z++3+sXuec84uAIrKpO00M20iEtg9e16f87KcTCZR
kzW5ncV7dZpnxc0svijnrWviNHNNnc3bxqYxvnBxU8ZJWdCnJivow9TeZol1
e1FaJoVZ0xJpbRbNxKxda52bNEdNvZzIqpPDZ5FrTJH+bPKyoEeburVRYppZ
bD9V0d1yFl8dXV18G93czeKT8vjjOB7HF9aVbZ3Y+DSrbdKU9SYybbMq61k0
ibPC0ZPT+Hjt/u9/nYviWGg4WdVEeGaK3jdEsrW01bsyz4kG+nMaPzs6eEFf
JWVKLz19dnh0+JT/bIum3szi4xanN/RRtWKC937/4vnk5csXk1f//erw5fNX
e/SVXZssn8WJ3/KPevRpUq6joqzXpslu7SzKikX3RzSZTGIzBxuTJoquVlmx
BGsb/g96c90WGXEmKws6JDGj4/jF2eXVos3js+I2q8tibYvGxfsn5cXZKK5t
nlkX00s/XJyzrMB3/NvZ+tbWbhq9t58afLDKbG3qZEW75JDoIlu2tWxI3Ikd
cbiZ5ERsGp9/jE2a1nQm68YRkehiknaLnYm4pi7TllQgNmA+yHfJyq5tTMf1
6hHPjaOFaO2k3lRNuaxNRTvHWUprZIuMKTuOXWWTjMip2roqnaVdiLfEAEcH
4wOkvCgpC4hhlq3wXG+ZcQTq1zZZmSJza8cv7FBYsMAUBUmaVKtZ2axm1XH8
OvhWljf4fB23VWxqosW6hCzBplMR3jpL09xG0ZP4XFnAvPv8JOv9eR9FJwNZ
zm1zZ22xk6JWT2RZ9+OqLpsyKfM4N/XS5pt4ZarKFg76YDN6rI7LRdzckWwT
W5g6K0kEDb+/LiGbWZSXEG5Be5Y1me4dvUVmQJQkWzLFoYdKt7ZpZmD18w0R
mOJj+iNoUSTWuPXSr53OJHXpHJNHDLM1URWRYJO2rolWOh4Zq/2U2AorEdXO
Nm0llLWuNTk9kRW3ZX5La+kZhlpLcp5bV5U3tif+xyhlVhhhtLM4E7SsXDRE
/bIlfeKD39m5eL3ojrR1FVclCVfM1MLC6N/E8XlJa7Hy8OfCo3gflBsorrgv
GHIzkgNlhTDUxavyThbRtxIDLtJbhmyIVO2ypW3F8Qpx/lV6ZEn+xtZEKfZW
CukQzaaCTRO/oMP0NSkwqQxIO31/Gex+I5q+al3Pa+ChsqIHyM/inOWdeAOT
kmHzdnQkscpxdL7A86QeZfG0Gct/B/LoHJ2KvY5cdw4YEylunq0zqFTrxFOQ
TOf5linb6XIap60FKetyntH3tkhZCpDs1eOeaLcnifYlEE1NXZlRhCgkBtfz
F6wZyswG/CQC02jfrqu83MBADUWiLii+M24VXzHp+6fvrkajKUz+ofpDsMHf
gKXsYOBbvBVG2LlsEXNZYTNYiUk6dWUJvruK5pvuO6JHVbkfqYPSpSFm7n/+
/OZ8cjrNbLOYJGVtJ/6hSXjo/h7UI+Dmt3wiUWoIjJzRLVuFuNN1RWZE8sia
je5fVbnalhOFxlttYe5U3ES802UcHprCc17ZmvSqzMvlhhxn0/1FfvPJk/ij
qcnMs8qQuLelTVJxYrkk5brMob8Lz22KryDd+6soolDubZ3NjPRa45X1trFb
Y6ayErbrL5OQwcAT4KCFtSmHk5oZZ3/rumLA6rxWNq/8DkqjcJHCnKP43veo
/aNxNFC90ujhIxltAR0jFXuweFz/6uJ8Wl55AXtWG+lvC7f67iquOgHx6sVG
JSDEZ8xjwlbB/9A7Jb2em42PSrTSBzi28daxSLmJvj45TUm6RJwuOfSFSHRF
6wb57+DpOB5wgW1vm3boKIEKsgLLwZ88cEb2bqFp/MnS8qY4hnhXdlsJgRqw
+X3Z6InN4BRi9HIQM1QcPYvpDhjxAisDP7wsH6JANrOsCV5ibsUZhQUkwjjo
NlzEL4Dv6ly8CHX37kEinszwuP1EpmzqTfyn4AfV3pwVB+TRj+u5yijY+Rbv
WOXJhSPQkQtaLCxCfLBdcuziX++yPAddFLsLClcc9/jZhFEWeQAINylN9XtE
SEaVUXQuiuVcC04zDYKZLs5iaBQOu6xLuNYmPj+7ehvxPj5eEssQuRWjXuvq
s4ODa1lLIzC8vvAcQZMNaqwRE4fO8/LO9YEoS5dBN5mMJZyWMqfZ8clipJYF
wZO64cg1iDkkz5ytj/j1+TPctMtyuLZfTCHOGmROPCKcFHZZUqrBCPOetTew
gwVAuUp8RzZG23sLDmgSNFI4Q2SVwzdJRaefTqfXI5EobVgDSAkQ9hy6ljfv
IC4O9dj2pgBCAJTekad1IjQ5AB+nPpPAhvh7pCYXNhf9vtpUu4X7jzOE5b0y
7IrJzEl2kLv9W5vdmtx2CG5RQozEnZmPLpbYpTDu2hPdI/l6B810ymPJshZ1
uaYdyZs2yLFCEGb2NADx/Q/p1bSL69c7WXTNj0WpTSgHsBpYEYENedqaqbhV
owGsUG2j2LyaFKVqOD3NHxCAoWCNFDTad9YSW//j4u3J81dfvry/jy/VzF9M
j6YjpHg9U3zqJLK1QyTij8m+7RvyhNCPSK3HtZTaZg2DEbzxm1ZUFg0WVFvx
hkaP7z2yxR4ZlFHwEXGWSPqy4WxZIS3eJqqRmkkuymi3zpYZ8g0vGTm9g1ft
XtOHC3sXnhMtW0IAPc0SwwE2ga9gHex96whCxZb8YcL49bgPmhjS0SkZ0z2m
DoKggTi4DkNKsWiB9BHBae1a439Tw/mvKfLmM/CPHPsPxAbNGpmqct5IwOfT
Uj7Fwc7rsFdSjeK8nuxJvt3csA4OlIArMoQGxxF9szaUg1HoyTSVS+0aBRfP
RZUzexJaoLCCY2lxCm/imYy76T+KryQv2EA9du4M6PrXv8SUlAywqKTuCz4q
qOZkjZ01BPTu6uqjuHWTkro0mfMcgfzJhY6jVckQyXCQQprqH+x7NRLfIuYE
Fz7pE+cJxDcCfI5w9OtIMOKyLNN4aQtbU/JarWqDyDGN//qTuh/2IrV3Lqh6
lO1yRXs+dF3XcMgXp517i0L6o1HkzT/oNccR5Q5kVZnkYeDVus0JIhkpAyYA
bhuB7TDmLpF6LNliy9USTv/xfjmHYTNsmwGCLxZtVI93FovorPuhGNMrmuzx
0/zQXnz8zfu33h8W0BMFMiN1KH16lMS0pK2LsvG5Dgd+CmUlgJooPA6nUICZ
hTM4cVhVjjUYjPXrXpRZLzPwkw4KyNg7F1NK5MT0D5SM3/2q9128N+2RuUc4
k9MxNlEtwjHhjvBgnoLsOYluE8BUB2GEPRLH9xT6jKM8u7Gy0D4HXMGTIIUc
dI8MemCvmLu7zXNKvb/49Mk+p4+3/p6a+d5oJofpINVveKt/xIPpnc3zCYOK
A+grA4geJZKoSGlN9+q+/Cr+C8WJZuJ5txf/JF8zk/A3/8URlXXgunv5mnNa
gk2shR7qenBNWK5mJ9H/apduNqy4zEL2GCSZu3EsHo2sY05uKb6xmzFFHY4y
KxQPSEtpNfiUBZdOVEM70jvSMimkPj+KKYyWXKSi2EVRLjWNiUiKYvoI7C9e
vviSjDqGnhLI4WTESeXBZxAVXHSxHPU3BHckb+vVl+jY2bLgmpB3/Ii10Jdy
0SMUi7MEGPx6lJ8VFAe4HsWKKRmOjcmftSiEk89+H8oMXTUQgbWHDdgf86FZ
S11vV9SGTIV/Fe16znUjjltrw1ZgxO0CNBHzUkjKiM/9XbxHWjvrLcUHf/by
cJ41upiEwOCiHFcp06Mvvnj2qidQtuJjkTu8B3wYp2cPzT/TnJZ8HKELwDE+
UBGfnb77cIIKKCUFS0vrET3CwKBSFEclU28UoxotwYTVidYbuxGPdGHu4o9C
4ndMIs6bbJ8Xyxx98RInZm1ksTzQSXWz/ITJlwi4q3V89c3plAjd/54yVsYV
bkWE3bE3YowiZ2GtlEJnxmXWquXqVske1heTfLlp9G/lZbbFRURoBZYaLShQ
EAhjNvpiZurrF0MrBT9T4uf38KNgrVgbw9xaEQ2Aep+PsBKwhStAcfyWzSlz
nfGNFd2siUitv8k7vUX4fbGXssAnyFJSWo5sCXy2n0wCG6J1SUTQ9Vj4zSV2
9ZD/Xp39dT5vcYVeDCUWrWY+PC5nUf2Pg28QVwHto4UIVdZ2W1i6xJKRmhRC
TIYEs4sXOKAgyB9XQsmHy5MPF2cUCq/PT38+uTg7/fnT9aA6gD6M90hgEmPf
O31bwMKOXIWYyDkiOh0Sy9+df0QnpGUftmhrfh/+BmX615o6uVBMCCXQAFik
3uDhdWoJ2edOHs/cIGiK46OgejZIWQb13ih6u7vGGzpncDNpyVu7tkJmIkSW
ufccuwqKseRkakmDos442ibCcy7UnTkIS1hqKRlW7NNDHL8ZbkyBN3ZAjX4V
T5GVov6NPyYyI5I2iCyLyfYZNDMJBX3REpb3oCooJXQKWdJ1kxIMhyuplUlN
k/nmq6EL7ycUWouPVUBJwZi0rUMnmgBI2XOSrpr7+wjWQ04JJZEmPj44pn8g
eAL4SEQjVG57SQbXsdiQyBeaRnbJCCOKfPOMMxdfR3hYRnhJmOI9WjZsisRE
dCm7QqBIWGErQvQtKWzIOoyvIWupqV/1B3hAo4i08u/oyjDiEJ0yIWT3ApCU
w1AK5XqkdpTos8SAeYxDiL+gObdGyvi2IIqRRs1NciNl2oExANbkwpJS82nX
O9yc8rtF1riR1la72nzX6YmOhxrBx9JeBiWdbLuURHMW2TibL3osQt7PZVx0
OciStb3pe0vMps9P/J8s/ij66FO+v7UkPS7NdnW4TmFZMwModlJZ1JVYkynL
SdT3W4xISGxa5pR55KEtZpuHbTHFmNu+CRvAjWwo4pJLTlEJ7Su7iF2yLU1p
fyHHXdi/62BJWqekdyYnNU03PXzO/UbT1Vhp/zMiOJNw6nsRoikoJYgv+R2Q
0kwcVGADffpnwapx/Dsyje97Da5eCaBjqPNJOrMIuVRIiKbTfr7DFTMsehw3
2ZrLMOvKu/lBK4Obxg0qBAuLR/kt6b/2UyAeq0HYzwrXLij2abMBSo7aicD4
lj0KIk/WzNh/9mo1YUqlq3p1G4z5acvpTD+87nN8HbHkgKmZXiCiqSe009+s
tygAj1Bw7GmruVOuO/fDHgNTIQCPij6yEd4VOgoxoFUz6+Mulxm0hdi397N9
1ZhAhmxFjGxItSSsDUgMAsZ/1T7UCzs9hZSWtWvRFoFY/HVoWXjTIpdlnKhh
0nQHC61w30WWxRGFBPKw0nQFkIvT4UG5orgwiX3YrXOhBR0aY8Ehq64wFvYH
5tqdVQPi6j+dpzJLEr4YJ0evMnalxMsyoWyTFSqXkiB/2vUOyA/AaaWtVOqs
X3sq4GNr70EmtFOWHKXcFuPHUSaEcT2S0jcXMC3Jqi0opyN8L+UusJLNr5tf
ivah6Ngyx+IUfEgRcu4PaJX0jiTkKrgeVIZdZdBujJR+PN1L8EVi87xMbgSN
jhCT6eVbmOiavHKSla2DEDXoR7wLESXVRK6VNoSxgoMgX6nNBVm857I4JppF
4xNYjaiIM1WWYCjE9EJW2FM6Nsf9UHKbmUcMqBdkyAkPpx6GvdxEwkUoT/dj
FVqV9pNN2uYxNe6q8L9thiGgkC9GEVxnWC1rAvG+Cqjf0Dn3v3q0xz7qkLYH
Fc7ycE/P9ULHGQ34AZXeJItgeGUbtw0CJt/24FrcQ8ZC+UPB5W0sE6aygPR0
XMsvwdzVTaUAKb794SFhDEr63Hds9r35SsOY8nfL3VKu13iBEHcesb3RYJAO
MUob+x5WUOg/LnYHShItV/L2TfPV63+iZN1rWz0bRZqth163ovOteNvxDQ2B
wO3OdBA913BLWSONFR4x67zyxSnx9UeGgL1kmN35UFYUOCppJhEDyfm0oYPX
DKUCnwXfFXxQCPfdBBWbCaHb1I9jrH0gvZY8NT75+c/XU+SvH2pyw1AUdmXZ
muJuPRZAhQgAeEBwmGTM/TG07mtAqsbkvhXxUGfa+TrrugAWHtObnvOTCW6g
HhIWZIKK7LuS8QCuy3F1VCCsWAMHB3hCk8vR4HBrzlk6lqKcJC+xl3oSv9XO
9k7v9OAY8EHohT/yeIjIG+53KNdRPrl9AdvGf7yUxMyHS1ZyVJYxeZUVSTNc
mO1xj5tw0X6ymHr99oPR4r9ScmGhW9XPoKZHI2GhJtphHmVA562pM9W2drm0
0qRjOEKE9daaHsliRBt8FHctxReT/FnXY540cf1sgLE9+otsN2nLNS30krt2
UMT5ElRbZNtWKQfiO3CaoIWv0axZM6940LFL+9K0Ty5iMr+exkO2dOnfX3+S
CPU9z7U+lvKEthUFpSvQJxFe5jC4Yr3bNThJJUHK3FltqPfG9ngfnShjbIDo
kk5WZRJGbElmYUDRn/SXUi2VR+BluDpr7ESGc4+JvdyOfE+K4mRwxY0jj0pN
8cjwhJ/rFinynKYITtuZhUPNHwWlLJcqftfNqynVt+hqInEdFg3eUDL/8uWr
w/t7La1c2L/N4m/PrnyNZbE4PJrNFumDAsqbVW0XXwlriaH/ePfnv8gDfLXz
sJ4SN4uPpodfYBq+gavGp3/4p7tNX7/Ghns7d9xjNXtfhrz61/N3VO+4PlUQ
/p3n2VL0ljsTNxoVEZilY0DODkOQpJSkLdo79ehYHCYMXmaqtIzMVVpshgKc
xnVuJLO58Nrcb2K/PmfFJV2fYZxmq2KZ7piGjkJU6uFEadv0it9dea8/yRam
Tz2Y9Ejyx5UvyyiTTJKIX2m2hgmVd7x+zbPYJmfszuNz6onpT66k9W1Wa7bw
B5zIYABw26Q/P9EJqHsvNSlG7iq5hGnHLpMXD7C16qDwoknU5ye9ehtttRPv
cPFAalwK2Xd7Ij9G83CAm9K4LYsdVHruX8v1jFD34Kn2QoAMbZhJc6117BKJ
ofTmw2FlcbKEWvRsfHkDRUKTl0skKaSRvY1RghlHPqKDdAVGHSzVhdgdwTv9
S9zBhLVuFoaok6YFeNhR0wo3T4y6Qg9rdxNhGp2iFhc/33hvyWM56gT/cnR4
+GyWzr+czZ79dEDRSs53YKs3BGX/aY90rdcD2JR5hlIgZ0dd4wfvsCEoInZF
XQWg9yD6uEQ3IbxuRGS/+Zdx9tFoMO+qs/nsOnrz575KolW+kJyNdSJ5q4eg
RzX9FFblxohdKzXzgLi59KuLSA0P/WjyEZwpMjN4dAZzmuJ03QrdngcVwJHe
TOgiosy6yyDFHFm/RFI/SfFiengY731Dqf2FvLLXRyRyukes32kLS5W6Z+YB
V/txlhCqiTwuse/ANvc6CIhuH7ChlJs/9CfdeCRM5qB8yuKdiL9n0mqPnXOB
PGsaemZtCrOU5Hw/8IKzQ/4GBM7LsoHXqHyOT5pLaxVeET1G3g2rreJ+zqaR
q5DjWdbWStnbb04HuqQUitmmN3+EMRVSL9SyfGdZjJMF2SufwJKqEuDW5118
sUdLSeFKQhg4H9S6vY/YJpxL4tJVIGdp87ISPwwjy3Ob6x2+rnaN2psEVfJo
aUkbIaGSmobH4J4E7XF1xdjeDS2gdx61Jofd1sQirkMwtvQXDSSYVmWZT3VP
54cgemksvSV+gfklRAUK+LLXwhCXZUdf7/CdJh15KFEEI4bm1jgd2FzQ8dEw
GbgHMKbObnFSj5DHkb9fJMRBAzsMq3rzSDqGyHS+2DUXL6UXKHbBMFoxFLrO
wFmoyfkrTDWbZc4VzFU2xx2kcRQSGn9NjZkzL+tU0B3X7fAgmLKjyQfJCPgC
+ZibQbGcR4bCyv5ynIdxXscGl/QEShoeEeUheDFbb0+sO0BaIg2MGqKHTSkY
11F2ppgPSmST8Ia7vx8x0hpgzv5UvQq8Z1aSsSsNGEe27OwZh50fvz9+4HiQ
+H1zOnskj+F+NAJMiyHOBy/v9qSzaG/XSOqeXNeSy4IFg/fN4AJeB3GZrOlU
Kh70b7nTCQUGOSc8z0CSWZIPypAJTg4PuT90nKZ6C9DM0avCBAvrP7f42aY1
x+a+58WpG0vGZ9fZZHDlViPhrkUZpdpbPyC975mi2DS50bmfkX85TFY7uSnH
QSyD0gPR8IVD9p+p95ssrJSsNwx0LdphyFb35XfAPZ6GeciDPCWxEcAZtvfx
8ju5CRNxs4dv8/CS9IU6epLU2hfNUfKWSvfH71BZ6feRSKETTmGl9aKumgfX
5KalFi29lblp5BtMRN6YaUuzFBMVPQJRf3jDS/4ITwi4wBWLwRXfDhPI7uxv
iw36aVwBq8xaCxl+RzKbpaWobvnmoiCMTGdihn0eX0+Mf6izybuS6zZ5qxUW
fWMC+UJCYGdlslqaPTrLEqbUMZa0RnWMcsanLt5nDj1N+y2O8z99GMkZuGwt
fVZ2KFoD8VNjJOtAGXN2mE8A1gvb9o+5k0BmNR6eh1M20i1toftc7c5XeBjr
oAdCWBhvFtOgslAndoFX318enNL/ga8nMhYjBmzyPKijllLYQ/be8eVqHsbi
MSxOTclb8SQfrsAAc3HiGaDPxekYfSpFQDDgbKE3ZgoBaV2tLUORQaqxcbgf
koYJDsJxr+kBD2rDuRks3ZH4Ld8CU8QHcYx1PdNvQz64bsYkV01vAtlX1tBQ
9clPEoZAiLp+9R6bSBcPHuNB60/I5BfCTYKVTW6IMImjZIZgvFxugbaf4GsG
puJa/NccaLtis8xeKYSV67qYUo3X2XKFzEqwnnZHtH05p+PxZUkUqRjIsTAv
uVxCHi8B3AvjQDzaLyRzhQwFycFkmRxApmTcUz/QFMen8omSEuCQQg/w2UMg
/1sJcneoedhYjvfDjc+5lfqov4Sg3dFiBH+R2CDs0B4psNXl2YkWRgxfyIn/
8/Tsz1Ofe3s4T2wRa/tYflQvbTQ0hP3lApOw9cG4G/PxVIsFWzEFTXfFi/Bu
gcDrP8xgrs++fiRay9dHX1/LlW3sy1J8rFQfOLBT9uQ460GFTZutjV7T5MJF
/0ca+PqShWvc1+viXOO5ddPtuBirdZjc9dpTvuAznHjpale+hkFQwFdZsHBq
JwR4OGiefcok2yBNrEtc0g+5bPEUh8xvdfqwhBQlphGhawjj/OPtS3/PXe2j
V1MkJc1SLNLAl9OGLECEsoP4w8XJu/PT2yOeGaWwzfOZPRGN4wIpxsn5xfmE
h5WSAWiO48uG2BPG2IgZBN1rfPGeYR/jQZ0uIiQzkQmtfdLJZ0fPp++OL9/5
/4E3pbitjCIuB1hyG6bGQJYfgyc7eDPC6u9MncpNf4YO6Ibntlg2K1oc5ZUr
TEyGvueXPHhNJMgI9hi7POUyAVg8Ymf0gwsNMExCdFd9SHE2VgcNxMrnXD6X
HmPcb8Fw/3iVVZN6kbx4cfR8Ms8ICdMCGIWlRI6H+jk89n7KYwQuWhsGPEkw
FIBPy0u+WqkFki035eEAU/6dtRV+2CH1Pu7idELeYHJ5im/f9bEhccX/PIL+
hIt0C/i1qw8XeIEitv7Mw7LkRluNQ4/Fr0tlxKpWppjKAHkYGeA5blJ3waUV
3Fe4G9qr+sQ6obwvvLS3tispxM9mz7q5k6zu5ak8Z+8TQ1bkNTKp0GhFOtSK
t8Zt56apHGGDZUap0XxKyQmR8gvxclrWywPkiJSPTOnbA/x2zwHZaDrBR5Pb
59PmUxNPvo4/vD//8P749PTi7PJycnH29nL02t8dsE8B8ggVIBvgSEzMvCM3
3U/f5riRUKRjCYGuXXM7NyhQbhcNhtKEWx7orMtbNpU9CTR7U7Hut5dkqucf
319KxLEOzEdkW3JiwI11nsOG15qSKstFEp0FRvED5Q0dow/XwSlsVVmt99L0
gkQ/HMntDNGotycvXx0dUoTKdBpf7uR8gFGEeQSBQvw934uQHG9C0HKi4zOJ
NFhknj0MP2gvw1eP4TqHtysdVuMfDor3/e3UkU574scZgp/tesdhvpe763z5
mLcmRqKuwyp4ru2TdDCcxs5EO64bD+slcHMzHT/YgfEkPkPmuqpeU5b+hnqC
Z2E6Lf9+AD2IpGTwo0SIoeenjtkIX8npvqTSuYw/hiv2shWXaLXsopwyMoOG
4Um9ZennLPmnIMIonJYS+Y4nHtmeBQcx3xJUYdeJUR65lCLlKtx0f3b4YhaM
akPnaadze/Dpf378+7KYpJ/qm5H3UEhAdByvgnZbV3E/s4ONOh0c3x2U3mtJ
AoTrfxu5RMqXKUF+uAelo6A9FsosIKfr4sT29t+MuII0HsT7fuEV2kYKZG/R
uYezmrIY3l98Gy67SWWHueyT22n0/77F2SrJTAAA

-->

</rfc>

