nsec5.xml

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

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1034 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml">
<!ENTITY RFC1035 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2136 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2136.xml">
<!ENTITY RFC2181 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2181.xml">
<!ENTITY RFC2308 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2308.xml">
<!ENTITY RFC4033 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY RFC4034 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml">
<!ENTITY RFC4035 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4035.xml">
<!ENTITY RFC4648 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml">
<!ENTITY RFC5114 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5114.xml">
<!ENTITY RFC5155 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5155.xml">
<!ENTITY RFC6234 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6234.xml">
<!ENTITY RFC6605 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6605.xml">
<!ENTITY RFC7748 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7748.xml">
<!ENTITY RFC8080 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8080.xml">
<!ENTITY I-D.irtf-cfrg-vrf SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.irtf-cfrg-vrf.xml">
<!ENTITY RFC6781 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6781.xml">
<!ENTITY RFC7129 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7129.xml">
<!ENTITY RFC7719 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7719.xml">
<!ENTITY I-D.gieben-nsec4 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.gieben-nsec4.xml">
]>

<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>

<rfc ipr="trust200902" docName="draft-vcelak-nsec5-07" category="std">

  <front>
    <title abbrev="NSEC5">NSEC5, DNSSEC Authenticated Denial of Existence</title>

    <author initials="J." surname="Vcelak" fullname="Jan Vcelak">
      <organization>CZ.NIC</organization>
      <address>
        <postal>
          <street>Milesovska 1136/5</street>
          <city>Praha</city>
          <code>130 00</code>
          <country>CZ</country>
        </postal>
        <email>jan.vcelak@nic.cz</email>
      </address>
    </author>
    <author initials="S." surname="Goldberg" fullname="Sharon Goldberg">
      <organization>Boston University</organization>
      <address>
        <postal>
          <street>111 Cummington St, MCS135</street>
          <city>Boston</city>
          <region>MA</region>
          <code>02215</code>
          <country>USA</country>
        </postal>
        <email>goldbe@cs.bu.edu</email>
      </address>
    </author>
    <author initials="D." surname="Papadopoulos" fullname="Dimitrios Papadopoulos">
      <organization>HKUST</organization>
      <address>
        <postal>
          <street>Clearwater Bay</street>
          <country>Hong Kong</country>
        </postal>
        <email>dipapado@ust.hk</email>
      </address>
    </author>
    <author initials="S." surname="Huque" fullname="Shumon Huque">
      <organization>Salesforce</organization>
      <address>
        <postal>
          <street>2550 Wasser Terr</street>
          <city>Herndon</city>
          <region>VA</region>
          <code>20171</code>
          <country>USA</country>
        </postal>
        <email>shuque@gmail.com</email>
      </address>
    </author>
    <author initials="D.C." surname="Lawrence" fullname="David C Lawrence">
      <organization>Akamai Technologies</organization>
      <address>
        <postal>
          <street>150 Broadway</street>
          <city>Boston</city>
          <region>MA</region>
          <code>02142-1054</code>
          <country>USA</country>
        </postal>
        <email>tale@akamai.com</email>
      </address>
    </author>

    <date year="2019"/>

    <area>Internet</area>
    <workgroup>Network Working Group</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>The Domain Name System Security Extensions (DNSSEC) introduced two 
resource records (RR) for authenticated denial of existence: the
NSEC RR and the NSEC3 RR. This
document introduces NSEC5 as an alternative mechanism for DNSSEC
authenticated denial of existence.  NSEC5 uses verifiable random
functions (VRFs) to prevent offline enumeration of zone
contents. NSEC5 also protects the integrity of the zone contents even
if an adversary compromises one of the authoritative servers for the
zone.  Integrity is preserved because NSEC5 does not require private
zone-signing keys to be present on all authoritative servers for the
zone, in contrast to DNSSEC online signing schemes like NSEC3 White
Lies.</t>



    </abstract>


    <note title="Ed note">


<t>Text inside square brackets ([]) is additional background
information, answers to frequently asked questions, general musings,
etc.  They will be removed before publication.  This document is being
collaborated on in GitHub at
&lt;https://github.com/fcelda/nsec5-draft&gt;.  The most recent version of
the document, open issues, etc should all be available there.  The
authors gratefully accept pull requests.</t>


    </note>


  </front>

  <middle>


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

<section anchor="rationale" title="Rationale">

<t>NSEC5 provides an alternative mechanism for authenticated denial of
existence for the DNS Security Extensions (DNSSEC). NSEC5 has two key
security properties.  First, NSEC5 protects the integrity of the zone
contents even if an adversary compromises one of the authoritative
servers for the zone.  Second, NSEC5 prevents offline zone
enumeration, where an adversary makes a small number of online DNS
queries and then processes them offline in order to learn all of the
names in a zone. Zone enumeration can be used to identify routers,
servers or other "things" that could then be targeted in more complex
attacks. An enumerated zone can also be a source of probable email
addresses for spam, or as a "key for multiple WHOIS queries to reveal
registrant data that many registries may have legal obligations to
protect" <xref target="RFC5155"/>.</t>

<t>All other DNSSEC mechanisms for authenticated denial of existence
either fail to preserve integrity against a compromised server, or
fail to prevent offline zone enumeration.</t>

<t>When offline signing with NSEC is used <xref target="RFC4034"/>, an NSEC chain of
all existing domain names in the zone is constructed and signed
offline. The chain is made of resource records (RRs), where each RR
represents two consecutive domain names in canonical order present in
the zone.  The authoritative server proves the non-existence of a name
by presenting a signed NSEC RR which covers the name.  Because the
authoritative server does not need not to know the private
zone-signing key, the integrity of the zone is protected even if the
server is compromised.  However, the NSEC chain allows for easy zone
enumeration: N queries to the server suffice to learn all N names in
the zone (see e.g., <xref target="nmap-nsec-enum"/>, <xref target="nsec3map"/>, and
<xref target="ldns-walk"/>).</t>

<t>When offline signing with NSEC3 is used <xref target="RFC5155"/>, the original
names in the NSEC chain are replaced by their cryptographic
hashes. Offline signing ensures that NSEC3 preserves integrity even if
an authoritative server is compromised. However, offline zone
enumeration is still possible with NSEC3 (see e.g., <xref target="nsec3walker"/>,
<xref target="nsec3gpu"/>), and is part of standard network reconnaissance tools
(e.g., <xref target="nmap-nsec3-enum"/>, <xref target="nsec3map"/>).</t>

<t>When online signing is used, the authoritative server holds the
private zone-signing key and uses this key to synthesize NSEC or NSEC3
responses on the fly (e.g.  NSEC3 White Lies (NSEC3-WL) or
Minimally-Covering NSEC, both described in <xref target="RFC7129"/>).  Because the
synthesized response only contains information about the queried name
(but not about any other name in the zone), offline zone enumeration
is not possible.  However, because the authoritative server holds the
private zone-signing key, integrity is lost if the authoritative
server is compromised.</t>

<texttable>
      <ttcol align='left'>Scheme</ttcol>
      <ttcol align='right'>Integrity vs network attacks?</ttcol>
      <ttcol align='right'>Integrity vs compromised auth. server?</ttcol>
      <ttcol align='right'>Prevents offline zone enumeration?</ttcol>
      <ttcol align='right'>Online crypto?</ttcol>
      <c>Unsigned</c>
      <c>NO</c>
      <c>NO</c>
      <c>YES</c>
      <c>NO</c>
      <c>NSEC</c>
      <c>YES</c>
      <c>YES</c>
      <c>NO</c>
      <c>NO</c>
      <c>NSEC3</c>
      <c>YES</c>
      <c>YES</c>
      <c>NO</c>
      <c>NO</c>
      <c>NSEC3-WL</c>
      <c>YES</c>
      <c>NO</c>
      <c>YES</c>
      <c>YES</c>
      <c>NSEC5</c>
      <c>YES</c>
      <c>YES</c>
      <c>YES</c>
      <c>YES</c>
</texttable>

<t>NSEC5 prevents offline zone enumeration and also protects integrity
even if a zone's authoritative server is compromised.  To do this,
NSEC5 replaces the unkeyed cryptographic hash function used in NSEC3
with a verifiable random function (VRF) <xref target="I-D.irtf-cfrg-vrf"/> <xref target="MRV99"/>.  A VRF is the
public-key version of a keyed cryptographic hash.  Only the holder of
the private VRF key can compute the hash, but anyone with public VRF
key can verify the correctness of the hash.</t>

<t>The public VRF key is distributed in an NSEC5KEY RR, similar to a
DNSKEY RR, and is used to verify NSEC5 hash values.  The private VRF
key is present on all authoritative servers for the zone, and is used
to compute hash values. For every query that elicits a negative
response, the authoritative server hashes the query on the fly using
the private VRF key, and also returns the corresponding precomputed
NSEC5 record(s). In contrast to the online signing approach
<xref target="RFC7129"/>, the private key that is present on all authoritative
servers for NSEC5 cannot be used to modify the zone contents.</t>

<t>Like online signing approaches, NSEC5 requires the authoritative
server to perform online public key cryptographic operations for every
query eliciting a denying response.  This is necessary; <xref target="nsec5"/>
proved that online cryptography is required to prevent offline zone
enumeration while still protecting the integrity of zone contents
against network attacks.</t>

<t>NSEC5 is not intended to replace NSEC or NSEC3. It is an alternative
mechanism for authenticated denial of existence.  This document
specifies NSEC5 based on the VRFs in <xref target="I-D.irtf-cfrg-vrf"/> over the
FIPS 186-3 P-256 elliptic curve and over the
the Ed25519 elliptic curve. A formal cryptographic proof of security
for NSEC5 is in <xref target="nsec5ecc"/>.</t>

</section>
<section anchor="requirements" title="Requirements">

<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119"/>.</t>

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

<t>The reader is assumed to be familiar with the basic DNS and DNSSEC
concepts described in <xref target="RFC1034"/>, <xref target="RFC1035"/>, <xref target="RFC4033"/>,
<xref target="RFC4034"/>, and <xref target="RFC4035"/>; subsequent RFCs that update them in
<xref target="RFC2136"/>, <xref target="RFC2181"/>, <xref target="RFC2308"/>, <xref target="RFC5155"/>, and <xref target="RFC7129"/>;
and DNS terms in <xref target="RFC7719"/>.</t>

<t>The reader should also be familiar with verifiable random functions (VRFs)
as defined in <xref target="I-D.irtf-cfrg-vrf"/>.</t>

<t>The following terminology is used through this document:</t>

<t><list style="hanging">
  <t hangText='Base32hex:'>
  The "Base 32 Encoding with Extended Hex Alphabet" as specified
in <xref target="RFC4648"/>. The padding characters ("=") are not
used in the NSEC5 specification.</t>
  <t hangText='Base64:'>
  The "Base 64 Encoding" as specified in <xref target="RFC4648"/>.</t>
  <t hangText='QNAME:'>
  The domain name being queried (query name).</t>
  <t hangText='Private NSEC5 key:'>
  The private key for the verifiable random function (VRF).</t>
  <t hangText='Public NSEC5 key:'>
  The public key for the VRF.</t>
  <t hangText='NSEC5 proof:'>
  A VRF proof. The holder of
the private NSEC5 key (e.g., authoritative server) can
compute the NSEC5 proof for an input domain name.
Anyone who knows the public VRF key can verify
that the NSEC5 proof corresponds to the input domain name.</t>
  <t hangText='NSEC5 hash:'>
  A cryptographic digest of an NSEC5 proof. If the NSEC5
proof is known, anyone can compute its corresponding NSEC5 hash.</t>
  <t hangText='NSEC5 algorithm:'>
  A triple of VRF algorithms that 
  compute an NSEC5 proof (VRF_prove),
  verify an NSEC5 proof (VRF_verify), 
  and process an NSEC5 proof to obtain its NSEC5 hash (VRF_proof_to_hash).</t>
</list></t>

</section>
</section>
<section anchor="backward-compatibility" title="Backward Compatibility">

<t>The specification describes a protocol change that is not backward
compatible with <xref target="RFC4035"/> and <xref target="RFC5155"/>. An NSEC5-unaware resolver
will fail to validate responses introduced by this document.</t>

<t>To prevent NSEC5-unaware resolvers from attempting to validate the
responses, new DNSSEC algorithms identifiers are introduced in
<xref target="iana_considerations"/> which alias existing algorithm numbers. The
zones signed according to this specification MUST use only these
algorithm identifiers, thus NSEC5-unaware resolvers will treat the
zone as insecure.</t>

</section>
<section anchor="how-nsec5-works" title="How NSEC5 Works">

<t>With NSEC5, the original domain name is hashed using a VRF <xref target="I-D.irtf-cfrg-vrf"/>
using the following steps:</t>

<t><list style="numbers">
  <t>The domain name is processed using a VRF keyed with the private
  NSEC5 key to obtain the NSEC5 proof.  Anyone who knows the public
  NSEC5 key, normally acquired via an NSEC5KEY RR, can verify that a
  given NSEC5 proof corresponds to a given domain name.</t>
  <t>The NSEC5 proof is then processed using a publicly-computable VRF
  VRF_proof_to_hash function to obtain the NSEC5 hash.  The NSEC5 hash can
  be computed by anyone who knows the input NSEC5 proof.</t>
</list></t>

<t>The NSEC5 hash determines the position of a domain name in an NSEC5
chain.</t>

<t>To sign a zone, the private NSEC5 key is used to compute the NSEC5
hashes for each name in the zone. These NSEC5 hashes are sorted in
canonical order <xref target="RFC4034"/>, and each consecutive pair forms an NSEC5
RR.  Each NSEC5 RR is signed offline using the private zone-signing
key.  The resulting signed chain of NSEC5 RRs is provided to all
authoritative servers for the zone, along with the private NSEC5 key.</t>

<t>To prove non-existence of a particular domain name in response to a
query, the server uses the private NSEC5 key to compute the NSEC5
proof and NSEC5 hash corresponding to the queried name.  The server
then identifies the NSEC5 RR that covers the NSEC5 hash, and responds
with this NSEC5 RR and its corresponding RRSIG signature RRset, as
well as a synthesized NSEC5PROOF RR that contains the NSEC5 proof
corresponding to the queried name.</t>

<t>To validate the response, the client verifies the following items:</t>

<t><list style="symbols">
  <t>The client uses the public NSEC5 key, normally acquired from the
NSEC5KEY RR, to verify that the NSEC5 proof in the NSEC5PROOF RR
corresponds to the queried name.</t>
  <t>The client uses the VRF_proof_to_hash function to compute the NSEC5
hash from the NSEC5 proof in the NSEC5PROOF RR.  The client verifies
that the NSEC5 hash is covered by the NSEC5 RR.</t>
  <t>The client verifies that the NSEC5 RR is validly signed by the RRSIG
RRset.</t>
</list></t>

</section>
<section anchor="nsec5-algorithms" title="NSEC5 Algorithms">

<t>The algorithms used for NSEC5 authenticated denial are independent of
the algorithms used for DNSSEC signing. An NSEC5 algorithm defines how
the NSEC5 proof and the NSEC5 hash are computed and validated.</t>

<t>The NSEC5 proof corresponding to a name is computed using ECVRF_prove(), 
as specified in <xref target="I-D.irtf-cfrg-vrf"/>.
The input to ECVRF_prove() is a private NSEC5 key and the
RR owner name in <xref target="RFC4034"/> canonical wire format.
The output of ECVRF_prove() is an octet string.</t>

<t>An NSEC5 hash corresponding to a name is computed from 
its NSEC5 proof using ECVRF_proof_to_hash(), as specified in <xref target="I-D.irtf-cfrg-vrf"/>.
The input to ECVRF_proof_to_hash() is 
an NSEC5 proof as an octet string. 
The output NSEC5 hash is either an octet string, or INVALID.</t>

<t>An NSEC5 proof for a name is verified using ECVRF_verify(),  as specified in
<xref target="I-D.irtf-cfrg-vrf"/>.
The input is the NSEC5 public key, 
followed by an NSEC5 proof as an octet string,
followed by an RR owner name in <xref target="RFC4034"/> canonical wire format.
The output is either VALID or INVALID.</t>

<t>This document defines the EC-P256-SHA256 NSEC5 algorithm as follows:</t>

<t><list style="symbols">
  <t>The VRF is the ECVRF algorithm using the ECVRF-P256-SHA256 
ciphersuite specified in <xref target="I-D.irtf-cfrg-vrf"/>.</t>
  <t>The public key format to be used in the NSEC5KEY RR is defined in
Section 4 of <xref target="RFC6605"/> and thus is the same as the format used to
store ECDSA public keys in DNSKEY RRs. <vspace />
[NOTE: This specification does 
not compress the elliptic curve point used for the public key,
but we do compress curve points in every other place we use them. The NSEC5KEY record can be shrunk by 31 additional octets by encoding the 
public key with point compression.]</t>
</list></t>

<t>This document defines the EC-ED25519-SHA512 NSEC5 algorithm as follows:</t>

<t><list style="symbols">
  <t>The VRF is the EC-VRF algorithm using the ECVRF-ED25519-SHA512
ciphersuite specified in <xref target="I-D.irtf-cfrg-vrf"/>.</t>
  <t>The public key format to be used in the NSEC5KEY RR is defined in
Section 3 of <xref target="RFC8080"/> and thus is the same as the format used to
store Ed25519 public keys in DNSKEY RRs.</t>
</list></t>

<t>[NOTE: Could alternatively have the EC-ED25519-SHA512 NSEC5 ciphersuite
use the 
EC-VRF-ED25519-SHA512-ELLIGATOR2 ciphersuite specified in <xref target="I-D.irtf-cfrg-vrf"/>.]</t>

</section>
<section anchor="the-nsec5key-resource-record" title="The NSEC5KEY Resource Record">

<t>The NSEC5KEY RR stores a public NSEC5 key. The key allows clients to
validate an NSEC5 proof sent by a server.</t>

<section anchor="nsec5key-rdata-wire-format" title="NSEC5KEY RDATA Wire Format">

<t>The RDATA for the NSEC5KEY RR is as shown below:</t>

<figure><artwork><![CDATA[
                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Algorithm   |                  Public Key                   /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t>Algorithm is a single octet identifying the NSEC5 algorithm.</t>

<t>Public Key is a variable-sized field holding public key material for
NSEC5 proof verification.</t>

</section>
<section anchor="nsec5key-rdata-presentation-format" title="NSEC5KEY RDATA Presentation Format">

<t>The presentation format of the NSEC5KEY RDATA is as follows:</t>

<t>The Algorithm field is represented as an unsigned decimal integer.</t>

<t>The Public Key field is represented in Base64 encoding. Whitespace is
allowed within the Base64 text.</t>

</section>
</section>
<section anchor="the-nsec5-resource-record" title="The NSEC5 Resource Record">

<t>The NSEC5 RR provides authenticated denial of existence for an RRset
or domain name. One NSEC5 RR represents one piece of an NSEC5 chain,
proving existence of the owner name and non-existence of other domain
names in the part of the hashed domain space that is covered until the next
owner name hashed in the RDATA.</t>

<section anchor="nsec5-rdata-wire-format" title="NSEC5 RDATA Wire Format">

<t>The RDATA for the NSEC5 RR is as shown below:</t>

<figure><artwork><![CDATA[
                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Key Tag            |     Flags     |  Next Length  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Next Hashed Owner Name                    /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                         Type Bit Maps                         /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t>The Key Tag field contains the key tag value of the NSEC5KEY RR that
validates the NSEC5 RR, in network byte order. The value is computed
from the NSEC5KEY RDATA using the same algorithm used to
compute key tag values for DNSKEY RRs. This algorithm is defined in
<xref target="RFC4034"/>.</t>

<t>The Flags field is a single octet. The meaning of individual bits of
the field is defined in <xref target="nsec5_flags"/>.</t>

<t>The Next Length field is an unsigned single octet specifying the
length of the Next Hashed Owner Name field in octets.</t>

<t>The Next Hashed Owner Name field is a sequence of binary octets. It
contains an NSEC5 hash of the next domain name in the NSEC5 chain.</t>

<t>Type Bit Maps is a variable-sized field encoding RR types present at
the original owner name matching the NSEC5 RR. The format of the field
is equivalent to the format used in the NSEC3 RR, described in
<xref target="RFC5155"/>.</t>

</section>
<section anchor="nsec5_flags" title="NSEC5 Flags Field">

<t>The following one-bit NSEC5 flags are defined:</t>

<figure><artwork><![CDATA[
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|           |W|O|
+-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t><list style='empty'>
  <t>O - Opt-Out flag</t>
</list></t>

<t><list style='empty'>
  <t>W - Wildcard flag</t>
</list></t>

<t>All the other flags are reserved for future use and MUST be zero.</t>

<t>The Opt-Out flag has the same semantics as in NSEC3. The definition
and considerations in <xref target="RFC5155"/> are valid, except that NSEC3 is
replaced by NSEC5.</t>

<t>The Wildcard flag indicates that a wildcard synthesis is possible at
the original domain name level (i.e., there is a wildcard node
immediately descending from the immediate ancestor of the original
domain name).  The purpose of the Wildcard flag is to reduce the
maximum number of RRs required for an authenticated denial of
existence proof from (at most) three to (at most) two, 
as originally described in <xref target="I-D.gieben-nsec4"/>
Section 7.2.1.</t>

</section>
<section anchor="nsec5-rdata-presentation-format" title="NSEC5 RDATA Presentation Format">

<t>The presentation format of the NSEC5 RDATA is as follows:</t>

<t>The Key Tag field is represented as an unsigned decimal integer.</t>

<t>The Flags field is represented as an unsigned decimal integer.</t>

<t>The Next Length field is not represented.</t>

<t>The Next Hashed Owner Name field is represented as a sequence of
case-insensitive Base32hex digits without any whitespace and without
padding.</t>

<t>The Type Bit Maps representation is equivalent to the representation
used in NSEC3 RR, described in <xref target="RFC5155"/>.</t>

</section>
</section>
<section anchor="the-nsec5proof-resource-record" title="The NSEC5PROOF Resource Record">

<t>The NSEC5PROOF record is not to be included in the zone file.  The
NSEC5PROOF record contains the NSEC5 proof, proving the position of
the owner name in an NSEC5 chain.</t>

<section anchor="nsec5proof_rdata" title="NSEC5PROOF RDATA Wire Format">

<t>The RDATA for the NSEC5PROOF RR is shown below:</t>

<figure><artwork><![CDATA[
                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Key Tag            |        Owner Name Hash        /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t>Key Tag field contains the key tag value of the NSEC5KEY RR that
validates the NSEC5PROOF RR, in network byte order.</t>

<t>Owner Name Hash is a variable-sized sequence of binary octets encoding
the NSEC5 proof of the owner name of the RR.</t>

</section>
<section anchor="nsec5proof-rdata-presentation-format" title="NSEC5PROOF RDATA Presentation Format">

<t>The presentation format of the NSEC5PROOF RDATA is as follows:</t>

<t>The Key Tag field is represented as an unsigned decimal integer.</t>

<t>The Owner Name Hash is represented in Base64 encoding. Whitespace is
allowed within the Base64 text.</t>

</section>
</section>
<section anchor="nsec5_proofs" title="Types of Authenticated Denial of Existence with NSEC5">

<t>This section summarizes all possible types of authenticated denial of
existence.  For each type the following lists are included:</t>

<t><list style="numbers">
  <t>Facts to prove: the minimum amount of information that an
  authoritative server must provide to a client to assure the client
  that the response content is valid.</t>
  <t>Authoritative server proofs: the names for which the NSEC5PROOF RRs
  are synthesized and added into the response along with the NSEC5 RRs
  matching or covering each such name. These records together prove
  the listed facts.</t>
  <t>Validator checks: the individual checks that a validating server is
  required to perform on a response. The response content is
  considered valid only if all of the checks pass.</t>
</list></t>

<t>If NSEC5 is said to match a domain name, the owner name of the NSEC5
RR has to be equivalent to an NSEC5 hash of that domain name. If an
NSEC5 RR is said to cover a domain name, the NSEC5 hash of the domain
name must sort in canonical order between that NSEC5 RR's Owner Name
and Next Hashed Owner Name.</t>

<section anchor="name-error-responses" title="Name Error Responses">

<t>Facts to prove:</t>

<t><list style='empty'>
  <t>Non-existence of the domain name that explictly matches the QNAME.</t>
</list></t>

<t><list style='empty'>
  <t>Non-existence of the wildcard that matches the QNAME.</t>
</list></t>

<t>Authoritative server proofs:</t>

<t><list style='empty'>
  <t>NSEC5PROOF for closest encloser and matching NSEC5 RR.</t>
</list></t>

<t><list style='empty'>
  <t>NSEC5PROOF for next closer name and covering NSEC5 RR.</t>
</list></t>

<t>Validator checks:</t>

<!-- Dimitris 01/2018 commented out the next two. They are covered by the last two validator checks, right?-->

<!-- The QNAME does not fall into a delegation.-->

<!-- The QNAME does not fall into a DNAME redirection.-->

<t><list style='empty'>
  <t>Closest encloser is in the zone.</t>
</list></t>

<t><list style='empty'>
  <t>The NSEC5 RR matching the closest encloser has its Wildcard flag cleared.</t>
</list></t>

<t><list style='empty'>
  <t>The NSEC5 RR matching the closest encloser does not have NS without SOA in the Type Bit Map.</t>
</list></t>

<t><list style='empty'>
  <t>The NSEC5 RR matching the closest encloser does not have DNAME in
  the Type Bit Map.</t>
</list></t>

<!--> Next closer name is derived correctly.-->

<t><list style='empty'>
  <t>Next closer name is not in the zone.</t>
</list></t>

</section>
<section anchor="no-data-responses" title="No Data Responses">

<t>The processing of a No Data response for DS QTYPE differs if the
Opt-Out is in effect. For DS QTYPE queries, the validator has two
possible checking paths.  The correct path can be simply decided by
inspecting if the NSEC5 RR in the response matches the QNAME.</t>

<t>Note that the Opt-Out is valid only for DS QTYPE queries.</t>

<section anchor="no-data-response-opt-out-not-in-effect" title="No Data Response, Opt-Out Not In Effect">

<t>Facts to prove:</t>

<t><list style='empty'>
  <t>Existence of an RRset explicitly matching the QNAME.</t>
</list></t>

<t><list style='empty'>
  <t>Non-existence of QTYPE RRset matching the QNAME.</t>
</list></t>

<t><list style='empty'>
  <t>Non-existence of CNAME RRset matching the QNAME.</t>
</list></t>

<t>Authoritative server proofs:</t>

<t><list style='empty'>
  <t>NSEC5PROOF for the QNAME and matching NSEC5 RR.</t>
</list></t>

<t>Validator checks:</t>

<t><list style='empty'>
  <t>QNAME is in the zone.</t>
</list></t>

<t><list style='empty'>
  <t>NSEC5 RR matching the QNAME does not have QTYPE in Type Bit Map.</t>
</list></t>

<t><list style='empty'>
  <t>NSEC5 RR matching the QNAME does not have CNAME in Type Bit Map.</t>
</list></t>

</section>
<section anchor="no-data-response-opt-out-in-effect" title="No Data Response, Opt-Out In Effect">

<t>Facts to prove:</t>

<t><list style='empty'>
  <t>The delegation is not covered by the NSEC5 chain.</t>
</list></t>

<t>Authoritative server proofs:</t>

<t><list style='empty'>
  <t>NSEC5PROOF for closest provable encloser and matching NSEC5 RR.</t>
</list></t>

<t>Validator checks:</t>

<t><list style='empty'>
  <t>Closest provable encloser is in zone.</t>
</list></t>

<t><list style='empty'>
  <t>Closest provable encloser covers (not matches) the QNAME.</t>
</list></t>

<t><list style='empty'>
  <t>NSEC5 RR matching the closest provable encloser has Opt-Out flag set.</t>
</list></t>

</section>
</section>
<section anchor="wildcard-responses" title="Wildcard Responses">

<t>Facts to prove:</t>

<t><list style='empty'>
  <t>A signed positive response to the QNAME demonstrating the existence of the wildcard (label count in RRSIG is less than in QNAME), and also providing closest encloser name.</t>
</list></t>

<t><list style='empty'>
  <t>Non-existence of the domain name matching the QNAME.</t>
</list></t>

<t>Authoritative server proofs:</t>

<t><list style='empty'>
  <t>A signed positive response for the wildcard expansion of the QNAME.</t>
</list></t>

<t><list style='empty'>
  <t>NSEC5PROOF for next closer name and covering NSEC5 RR.</t>
</list></t>

<t>Validator checks:</t>

<!--> Next closer name is derived correctly.-->

<t><list style='empty'>
  <t>Next closer name is not in the zone.</t>
</list></t>

</section>
<section anchor="wildcard-no-data-responses" title="Wildcard No Data Responses">

<t>Facts to prove:</t>

<t><list style='empty'>
  <t>The existence of the wildcard at the closest encloser to the QNAME.</t>
</list></t>

<t><list style='empty'>
  <t>Non-existence of both the QTYPE and of the CNAME type that matches QNAME via wildcard expansion.</t>
</list></t>

<t>Authoritative server proofs:</t>

<t><list style='empty'>
  <t>NSEC5PROOF for source of synthesis (i.e., wildcard at closest
encloser) and matching NSEC5 RR.</t>
</list></t>

<t><list style='empty'>
  <t>NSEC5PROOF for next closer name and covering NSEC5 RR.</t>
</list></t>

<t>Validator checks:</t>

<t><list style='empty'>
  <t>Closest encloser to the QNAME exists.</t>
</list></t>

<t><list style='empty'>
  <t>NSEC5 RR matching the wildcard label prepended to the closest encloser, and which does not have the bits corresponding to the QTYPE and CNAME types set it the type bitmap.</t>
</list></t>

</section>
</section>
<section anchor="authoritative-server-considerations" title="Authoritative Server Considerations">

<section anchor="zone_signing" title="Zone Signing">

<t>Zones using NSEC5 MUST satisfy the same properties as described in
Section 7.1 of <xref target="RFC5155"/>, with NSEC3 replaced by NSEC5. In addition,
the following conditions MUST be satisfied as well:</t>

<t><list style="symbols">
  <t>If the original owner name has a wildcard label immediately
descending from the original owner name, the corresponding NSEC5 RR
MUST have the Wildcard flag set in the Flags field. Otherwise, the
flag MUST be cleared.</t>
  <t>The zone apex MUST include an NSEC5KEY RRset containing a NSEC5
public key allowing verification of the current NSEC5 chain.</t>
</list></t>

<t>The following steps describe one possible method to properly add
required NSEC5 related records into a zone. This is not the only such
existing method.</t>

<t><list style="numbers">
  <t>Select an algorithm for NSEC5 and generate the public and private NSEC5 keys.</t>
  <t>Add an NSEC5KEY RR into the zone apex containing the public NSEC5 key.</t>
  <t>For each unique original domain name in the zone and each empty
  non-terminal, add an NSEC5 RR. If Opt-Out is used, owner names of
  unsigned delegations MAY be excluded.  <vspace blankLines='1'/>
A. The owner name of the NSEC5 RR is the NSEC5 hash of the
   original owner name encoded in Base32hex without padding,
   prepended as a single label to the zone name.  <vspace blankLines='1'/>
B. Set the Key Tag field to be the key tag corresponding
   to the public NSEC5 key.  <vspace blankLines='1'/>
C. Clear the Flags field. If Opt-Out is being used, set the Opt-Out
   flag. If there is a wildcard label directly descending from the
   original domain name, set the Wildcard flag. Note that the
   wildcard can be an empty non-terminal (i.e., the wildcard synthesis
   does not take effect and therefore the flag is not to be set).  <vspace blankLines='1'/>
D. Set the Next Length field to a value determined by the used
   NSEC5 algorithm. Leave the Next Hashed Owner Name field blank.  <vspace blankLines='1'/>
E. Set the Type Bit Maps field based on the RRsets present at the
   original owner name.</t>
  <t>Sort the set of NSEC5 RRs into canonical order.</t>
  <t>For each NSEC5 RR, set the Next Hashed Owner Name field by using
  the owner name of the next NSEC5 RR in the canonical order. If the
  updated NSEC5 is the last NSEC5 RR in the chain, the owner name of the
  first NSEC5 RR in the chain is used instead.</t>
</list></t>

<t>The NSEC5KEY and NSEC5 RRs MUST have the same class as the zone SOA
RR.  Also the NSEC5 RRs SHOULD have the same TTL value as the SOA
minimum TTL field.</t>

<t>Notice that a use of Opt-Out is not indicated in the zone. This does
not affect the ability of a server to prove insecure delegations. The
Opt-Out MAY be part of the zone-signing tool configuration.</t>

<section anchor="precompute" title="Precomputing Closest Provable Encloser Proofs">

<t>Per <xref target="nsec5_proofs"/>, the worst-case scenario when answering a negative 
query with NSEC5 requires the authoritative server to respond with two 
NSEC5PROOF RRs and
two NSEC5 RRs. One pair of NSEC5PROOF and NSEC5
RRs corresponds to the closest provable encloser, and the other pair
corresponds to the next closer name.  The NSEC5PROOF corresponding to
the next closer name MUST be computed on the fly by the authoritative
server when responding to the query. However, the NSEC5PROOF
corresponding to the closest provable encloser MAY be precomputed and
stored as part of zone signing.</t>

<t>Precomputing NSEC5PROOF RRs can halve the number of online
cryptographic computations required when responding to a negative
query. NSEC5PROOF RRs MAY be precomputed as part of zone signing as
follows: For each NSEC5 RR, compute an NSEC5PROOF RR corresponding to
the original owner name of the NSEC5 RR. The content of the
precomputed NSEC5PROOF record MUST be the same as if the record was
computed on the fly when serving the zone.  NSEC5PROOF records are not
part of the zone and SHOULD be stored separately from the zone file.</t>

</section>
</section>
<section anchor="zone-serving" title="Zone Serving">

<t>This specification modifies DNSSEC-enabled DNS responses generated by
authoritative servers. In particular, it replaces use of NSEC or NSEC3
RRs in such responses with NSEC5 RRs and adds NSEC5PROOF RRs.</t>

<t>According to the type of a response, an authoritative server MUST
include NSEC5 RRs in the response, as defined in <xref target="nsec5_proofs"/>. For
each NSEC5 RR in the response, a corresponding RRSIG RRset and an
NSEC5PROOF MUST be added as well. The NSEC5PROOF RR has its owner name
set to the domain name required according to the description in 
<xref target="nsec5_proofs"/>. The
class and TTL of the NSEC5PROOF RR MUST be the same as the class and
TTL value of the corresponding NSEC5 RR. The RDATA payload of the
NSEC5PROOF is set according to the description in
<xref target="nsec5proof_rdata"/>.</t>

<t>Notice that the NSEC5PROOF owner name can be a wildcard (e.g., source
of synthesis proof in wildcard No Data responses). The name also
always matches the domain name required for the proof while the NSEC5
RR may only cover (not match) the name in the proof (e.g., closest
encloser in Name Error responses).</t>

<t>If NSEC5 is used, an answering server MUST use exactly one NSEC5 chain
for one signed zone.</t>

<t>NSEC5 MUST NOT be used in parallel with NSEC, NSEC3, or any other
authenticated denial of existence mechanism that allows for
enumeration of zone contents, as this would defeat a principal
security goal of NSEC5.</t>

<t>Similarly to NSEC3, the owner names of NSEC5 RRs are not represented
in the NSEC5 chain and therefore NSEC5 records deny their own
existence. The desired behavior caused by this paradox is the same as
described in Section 7.2.8 of <xref target="RFC5155"/>.</t>

</section>
<section anchor="nsec5key-rollover-mechanism" title="NSEC5KEY Rollover Mechanism">

<t>Replacement of the NSEC5 key implies generating a new NSEC5 chain. The
NSEC5KEY rollover mechanism is similar to "Pre-Publish Zone Signing
Key Rollover" as specified in <xref target="RFC6781"/>. The NSEC5KEY rollover MUST
be performed as a sequence of the following steps:</t>

<t><list style="numbers">
  <t>A new public NSEC5 key is added into the NSEC5KEY RRset in the zone
  apex.</t>
  <t>The old NSEC5 chain is replaced by a new NSEC5 chain constructed
  using the new key. This replacement MUST happen as a single atomic
  operation; the server MUST NOT be responding with RRs from both the
  new and old chain at the same time.</t>
  <t>The old public key is removed from the NSEC5KEY RRset in the zone
  apex.</t>
</list></t>

<t>The minimum delay between steps 1 and 2 MUST be the time it takes for
the data to propagate to the authoritative servers, plus the TTL value
of the old NSEC5KEY RRset.</t>

<t>The minimum delay between steps 2 and 3 MUST be the time it takes for
the data to propagate to the authoritative servers, plus the maximum
zone TTL value of any of the data in the previous version of the zone.</t>

</section>
<section anchor="secondary-servers" title="Secondary Servers">

<t>This document does not define mechanism to distribute private NSEC5 keys.
See <xref target="keyleak"/> for security considerations for private NSEC5 keys.</t>

</section>
<section anchor="zones-using-unknown-nsec5-algorithms" title="Zones Using Unknown NSEC5 Algorithms">

<t>Zones that are signed with an unknown NSEC5 algorithm or with an
unavailable private NSEC5 key cannot be effectively served. Such zones
SHOULD be rejected when loading and servers SHOULD respond with
RCODE=2 (Server failure) when handling queries that would fall under
such zones.</t>

</section>
<section anchor="dynamic-updates" title="Dynamic Updates">

<t>A zone signed using NSEC5 MAY accept dynamic updates <xref target="RFC2136"/>.  The
changes to the zone MUST be performed in a way that ensures that the
zone satisfies the properties specified in <xref target="zone_signing"/> at any
time.  The process described in <xref target="RFC5155"/> Section 7.5 describes how
to handle the issues surrounding the handling of empty non-terminals
as well as Opt-Out.</t>

<t>It is RECOMMENDED that the server rejects all updates containing
changes to the NSEC5 chain and its related RRSIG RRs, and performs
itself any required alternations of the NSEC5 chain induced by the
update.  Alternatively, the server MUST verify that all the properties
are satisfied prior to performing the update atomically.</t>

</section>
</section>
<section anchor="resolver-considerations" title="Resolver Considerations">

<t>The same considerations as described in Section 9 of <xref target="RFC5155"/> for
NSEC3 apply to NSEC5. In addition, as NSEC5 RRs can be validated only
with appropriate NSEC5PROOF RRs, the NSEC5PROOF RRs MUST be all
together cached and included in responses with NSEC5 RRs.</t>

</section>
<section anchor="validator-considerations" title="Validator Considerations">

<section anchor="validating-responses" title="Validating Responses">

<t>The validator MUST ignore NSEC5 RRs with Flags field values other than
the ones defined in <xref target="nsec5_flags"/>.</t>

<t>The validator MAY treat responses as bogus if the response contains
NSEC5 RRs that refer to a different NSEC5KEY.</t>

<t>According to a type of a response, the validator MUST verify all
conditions defined in <xref target="nsec5_proofs"/>. Prior to making decision based
on the content of NSEC5 RRs in a response, the NSEC5 RRs MUST be
validated.</t>

<t>To validate a denial of existence, public NSEC5 keys for the zone are
required in addition to DNSSEC public keys. Similarly to DNSKEY RRs,
the NSEC5KEY RRs are present at the zone apex.</t>

<t>The NSEC5 RR is validated as follows:</t>

<t><list style="numbers">
  <t>Select a correct public NSEC5 key to validate the NSEC5 proof. The
  Key Tag value of the NSEC5PROOF RR must match with the key tag value
  computed from the NSEC5KEY RDATA.</t>
  <t>Validate the NSEC5 proof present in the NSEC5PROOF Owner Name Hash
  field using the public NSEC5 key. If there are multiple NSEC5KEY RRs
  matching the key tag, at least one of the keys must validate the
  NSEC5 proof.</t>
  <t>Compute the NSEC5 hash value from the NSEC5 proof and check if the
  response contains NSEC5 RR matching or covering the computed NSEC5
  hash.  The TTL values of the NSEC5 and NSEC5PROOF RRs must be the
  same.</t>
  <t>Validate the signature on the NSEC5 RR.</t>
</list></t>

<t>If the NSEC5 RR fails to validate, it MUST be ignored. If some of the
conditions required for an NSEC5 proof are not satisfied, the response
MUST be treated as bogus.</t>

<t>Notice that determining the closest encloser and next closer name in
NSEC5 is easier than in NSEC3. NSEC5 and NSEC5PROOF RRs are always
present in pairs in responses and the original owner name of the NSEC5
RR matches the owner name of the NSEC5PROOF RR.</t>

</section>
<section anchor="validating-referrals-to-unsigned-subzones" title="Validating Referrals to Unsigned Subzones">

<t>The same considerations as defined in Section 8.9 of <xref target="RFC5155"/> for
NSEC3 apply to NSEC5.</t>

</section>
<section anchor="responses-with-unknown-nsec5-algorithms" title="Responses With Unknown NSEC5 Algorithms">

<t>A validator MUST ignore NSEC5KEY RRs with unknown NSEC5
algorithms. The practical result of this is that zones signed with
unknown algorithms will be considered bogus.</t>

</section>
</section>
<section anchor="special-considerations" title="Special Considerations">

<section anchor="transition-mechanism" title="Transition Mechanism">

<t>[TODO: The following information will be covered.]</t>

<t><list style="symbols">
  <t>Transition to NSEC5 from NSEC/NSEC3</t>
  <t>Transition from NSEC5 to NSEC/NSEC3</t>
  <t>Transition to new NSEC5 algorithms</t>
</list></t>

</section>
<section anchor="private-nsec5-keys" title="Private NSEC5 keys">

<t>This document does not define a format to store private NSEC5
keys. Use of a standardized and adopted format is RECOMMENDED.</t>

<t>The private NSEC5 key MAY be shared between multiple zones, however a
separate key is RECOMMENDED for each zone.</t>

</section>
<section anchor="domain-name-length-restrictions" title="Domain Name Length Restrictions">

<t>NSEC5 creates additional restrictions on domain name lengths. In
particular, zones with names that, when converted into hashed owner
names, exceed the 255 octet length limit imposed by <xref target="RFC1035"/> cannot
use this specification.</t>

<t>The actual maximum length of a domain name depends on the length of
the zone name and the NSEC5 algorithm used.</t>

<t>All NSEC5 algorithms defined in this document use 256-bit NSEC5 hash
values.  Such a value can be encoded in 52 characters in Base32hex
without padding.  When constructing the NSEC5 RR owner name, the
encoded hash is prepended to the name of the zone as a single label
which includes the length field of a single octet.  The maximum length
of the zone name in wire format using the 256-bit hash is therefore
202 octets (255 - 53).</t>

</section>
</section>
<section anchor="implementation-status" title="Implementation Status">

<t>NSEC5 has been implemented for the Knot DNS authoritative server
(version 1.6.4) and the Unbound recursive server (version 1.5.9).  The
implementations did not introduce additional library dependencies; all
cryptographic primitives are already present in OpenSSL v1.0.2j, which
is used by both implementations.  The implementations support the full
spectrum of negative responses, (i.e., NXDOMAIN, NODATA, Wildcard,
Wildcard NODATA, and unsigned delegation) using the EC-P256-SHA256
algorithm. The code is deliberately modular, so that the
EC-ED25519-SHA256 algorithm could be implemented by using the Ed25519
elliptic curve <xref target="RFC8080"/> as a drop-in replacement for the P256
elliptic curve.  The authoritative server implements the optimization
from <xref target="precompute"/> to precompute the NSEC5PROOF RRs matching each
NSEC5 record.</t>

</section>
<section anchor="performance-considerations" title="Performance Considerations">

<t>The performance of NSEC5 has been evaluated in <xref target="nsec5ecc"/>.</t>

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

<section anchor="zea" title="Zone Enumeration Attacks">

<t>NSEC5 is robust to zone enumeration via offline dictionary attacks by
any attacker that does not know the private NSEC5 key. Without the
private NSEC5 key, that attacker cannot compute the NSEC5 proof that
corresponds to a given domain name.  The only way it can learn the
NSEC5 proof value for a domain name is by querying the authoritative
server for that name. Without the NSEC5 proof value, the attacker
cannot learn the NSEC5 hash value. Thus, even an attacker that
collects the entire chain of NSEC5 RR for a zone cannot use offline
attacks to "reverse" that NSEC5 hash values in these NSEC5 RR and thus
learn which names are present in the zone.  A formal cryptographic
proof of this property is in <xref target="nsec5"/> and <xref target="nsec5ecc"/>.</t>

</section>
<section anchor="keyleak" title="Compromise of the Private NSEC5 Key">

<t>NSEC5 requires authoritative servers to hold the private NSEC5 key,
but not the private zone-signing keys or the private key-signing keys
for the zone.</t>

<t>The private NSEC5 key cannot be used to modify zone contents, because
zone contents are signed using the private zone-signing key.  As such,
a compromise of the private NSEC5 key does not compromise the
integrity of the zone.  An adversary that learns the private NSEC5 key
can, however, perform offline zone-enumeration attacks.  For this
reason, the private NSEC5 key need only be as secure as the DNSSEC
records whose privacy (against zone enumeration) is being protected by
NSEC5.  A formal cryptographic proof of this property is in <xref target="nsec5"/>
and <xref target="nsec5ecc"/>.</t>

<t>To preserve this property of NSEC5, the private NSEC5 key MUST be
different from the private zone-signing keys or key-signing keys for
the zone.</t>

</section>
<section anchor="keylen" title="Key Length Considerations">

<t>The NSEC5 key must be long enough to withstand attacks for as long as
the privacy of the zone contents is important. Even if the NSEC5 key
is rolled frequently, its length cannot be too short, because zone
privacy may be important for a period of time longer than the lifetime
of the key.  For example, an attacker might collect the entire chain
of NSEC5 RR for the zone over one short period, and then, later (even
after the NSEC5 key expires) perform an offline dictionary attack that
attempts to reverse the NSEC5 hash values present in the NSEC5 RRs.
This is in contrast to zone-signing and key-signing keys used in
DNSSEC; these keys, which ensure the authenticity and integrity of the
zone contents, need to remain secure only during their lifetime.</t>

</section>
<section anchor="hashcol" title="NSEC5 Hash Collisions">

<t>If the NSEC5 hash of a QNAME collides with the NSEC5 hash of the owner
name of an NSEC5 RR, it will be impossible to prove the non-existence
of the colliding QNAME. However, the NSEC5 VRFs ensure that obtaining
such a collision is as difficult as obtaining a collision in the
SHA-256 hash function, requiring approximately 2^128 effort. Note that
DNSSEC already relies on the assumption that a cryptographic hash
function is collision-resistant, since these hash functions are used
for generating and validating signatures and DS RRs. See also the
discussion on key lengths in <xref target="nsec5"/>.</t>

</section>
</section>
<section anchor="iana_considerations" title="IANA Considerations">

<t>This document updates the IANA registry "Domain Name System (DNS)
Parameters" in subregistry "Resource Record (RR) TYPEs", by defining
the following new RR types:</t>

<t><list style='empty'>
  <t>NSEC5KEY   value TBD.</t>
</list></t>

<t><list style='empty'>
  <t>NSEC5      value TBD.</t>
</list></t>

<t><list style='empty'>
  <t>NSEC5PROOF value TBD.</t>
</list></t>

<t>This document creates a new IANA registry for NSEC5 algorithms.  This
registry is named "DNSSEC NSEC5 Algorithms". The initial content of
the registry is:</t>

<t><list style='empty'>
  <t>0     is Reserved.</t>
</list></t>

<t><list style='empty'>
  <t>1     is EC-P256-SHA256.</t>
</list></t>

<t><list style='empty'>
  <t>2     is EC-ED25519-SHA256.</t>
</list></t>

<t><list style='empty'>
  <t>3-255 is Available for assignment.</t>
</list></t>

<t>This document updates the IANA registry "DNS Security Algorithm
Numbers" by defining following aliases:</t>

<t><list style='empty'>
  <t>TBD is NSEC5-ECDSAP256SHA256 alias for ECDSAP256SHA256 (13).</t>
</list></t>

<t><list style='empty'>
  <t>TBD is NSEC5-ED25519, alias for ED25519 (15).</t>
</list></t>

</section>
<section anchor="contributors" title="Contributors">

<t>This document would not be possible without help of
Moni Naor (Weizmann Institute),
Sachin Vasant (Cisco Systems),
Leonid Reyzin (Boston University), and
Asaf Ziv (Weizmann Institute)
who contributed to the design of NSEC5.
Ondrej Sury (CZ.NIC Labs), and
Duane Wessels (Verisign Labs)
provided advice on the implementation of NSEC5, and assisted with
evaluating its performance.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>

&RFC1034;
&RFC1035;
&RFC2119;
&RFC2136;
&RFC2181;
&RFC2308;
&RFC4033;
&RFC4034;
&RFC4035;
&RFC4648;
&RFC5114;
&RFC5155;
&RFC6234;
&RFC6605;
&RFC7748;
&RFC8080;
&I-D.irtf-cfrg-vrf;
<reference anchor="FIPS-186-3" >
  <front>
    <title>Digital Signature Standard (DSS)</title>
    <author >
      <organization>National Institute for Standards and Technology</organization>
    </author>
    <date year="2009" month="June"/>
  </front>
  <seriesInfo name="FIPS" value="PUB 186-3"/>
</reference>


    </references>

    <references title='Informative References'>

&RFC6781;
&RFC7129;
&RFC7719;
&I-D.gieben-nsec4;
<reference anchor="nsec5" target="https://eprint.iacr.org/2014/582.pdf">
  <front>
    <title>NSEC5: Provably Preventing DNSSEC Zone Enumeration</title>
    <author initials="S." surname="Goldberg">
      <organization></organization>
    </author>
    <author initials="M." surname="Naor">
      <organization></organization>
    </author>
    <author initials="D." surname="Papadopoulos">
      <organization></organization>
    </author>
    <author initials="L." surname="Reyzin">
      <organization></organization>
    </author>
    <author initials="S." surname="Vasant">
      <organization></organization>
    </author>
    <author initials="A." surname="Ziv">
      <organization></organization>
    </author>
    <date year="2014" month="July"/>
  </front>
  <seriesInfo name="in" value="NDSS'15"/>
</reference>
<reference anchor="nsec5ecc" target="https://eprint.iacr.org/2017/099.pdf">
  <front>
    <title>Can NSEC5 be Practical for DNSSEC Deployments?</title>
    <author initials="D." surname="Papadopoulos">
      <organization></organization>
    </author>
    <author initials="D." surname="Wessels">
      <organization></organization>
    </author>
    <author initials="S." surname="Huque">
      <organization></organization>
    </author>
    <author initials="J." surname="Vcelak">
      <organization></organization>
    </author>
    <author initials="M." surname="Naor">
      <organization></organization>
    </author>
    <author initials="L." surname="Reyzin">
      <organization></organization>
    </author>
    <author initials="S." surname="Goldberg">
      <organization></organization>
    </author>
    <date year="2017" month="February"/>
  </front>
  <seriesInfo name="in" value="ePrint Cryptology Archive 2017/099"/>
</reference>
<reference anchor="nsec3gpu" >
  <front>
    <title>GPU-Based NSEC3 Hash Breaking</title>
    <author initials="M." surname="Wander">
      <organization></organization>
    </author>
    <author initials="L." surname="Schwittmann">
      <organization></organization>
    </author>
    <author initials="C." surname="Boelmann">
      <organization></organization>
    </author>
    <author initials="T." surname="Weis">
      <organization></organization>
    </author>
    <date year="2014"/>
  </front>
  <seriesInfo name="in" value="IEEE Symp. Network Computing and Applications (NCA)"/>
</reference>
<reference anchor="nsec3walker" target="http://dnscurve.org/nsec3walker.html">
  <front>
    <title>Nsec3 walker</title>
    <author initials="D.J." surname="Bernstein">
      <organization></organization>
    </author>
    <date year="2011"/>
  </front>
</reference>
<reference anchor="nmap-nsec-enum" target="https://nmap.org/nsedoc/scripts/dns-nsec-enum.html">
  <front>
    <title>nmap: dns-nsec-enum</title>
    <author initials="J.R." surname="Bond">
      <organization></organization>
    </author>
    <date year="2011"/>
  </front>
</reference>
<reference anchor="nmap-nsec3-enum" target="https://nmap.org/nsedoc/scripts/dns-nsec3-enum.html">
  <front>
    <title>nmap: dns-nsec3-enum</title>
    <author initials="A." surname="Nikolic">
      <organization></organization>
    </author>
    <author initials="J.R." surname="Bond">
      <organization></organization>
    </author>
    <date year="2011"/>
  </front>
</reference>
<reference anchor="nsec3map" target="https://github.com/anonion0/nsec3map.">
  <front>
    <title>nsec3map with John the Ripper plugin</title>
    <author >
      <organization>anonion0</organization>
    </author>
    <date year="2015"/>
  </front>
</reference>
<reference anchor="ldns-walk" target="http://git.nlnetlabs.nl/ldns/tree/examples/ldns-walk.c">
  <front>
    <title>ldns</title>
    <author >
      <organization>NLNetLabs</organization>
    </author>
    <date year="2015"/>
  </front>
</reference>
<reference anchor="MRV99" >
  <front>
    <title>Verifiable Random Functions</title>
    <author initials="S." surname="Michali">
      <organization></organization>
    </author>
    <author initials="M." surname="Rabin">
      <organization></organization>
    </author>
    <author initials="S." surname="Vadhan">
      <organization></organization>
    </author>
    <date year="1999"/>
  </front>
  <seriesInfo name="in" value="FOCS"/>
</reference>


    </references>


<section anchor="examples" title="Examples">

<t>We use a small DNS zone 
to illustrate how negative responses are handled with NSEC5.  For brevity,
the class is not shown (defaults to IN) and the SOA record is shortened,
resulting in the following zone file:</t>

<figure><artwork><![CDATA[
example.org.        SOA ( ... )  
example.org.        NS  a.example.org

a.example.org.      A 192.0.2.1  

c.example.org.      A 192.0.2.2  
c.example.org.      TXT "c record"  

d.example.org.      NS ns1.d.example.org

ns1.d.example.org.  A 192.0.2.4

g.example.org.      A 192.0.2.1  
g.example.org.      TXT "g record"

*.a.example.org.    TXT "wildcard record"
]]></artwork></figure>

<t>Notice the delegation to an unsigned zone d.example.org served 
by ns1.d.example.org.  (Note: if the d.example.org zone was signed, 
then the example.org zone have a DS record for d.example.org.)</t>

<t>Next we present example responses. All cryptographic values are
shortened as indicated by "&#8230;" and ADDITIONAL sections have been
removed.</t>

<section anchor="name-error-example" title="Name Error Example">

<t>Consider a query for a type A record for a.b.c.example.org.</t>

<t>The server must prove the following facts:</t>

<t><list style="symbols">
  <t>Existence of closest encloser c.example.org.</t>
  <t>Non-existence of wildcard at closest encloser *.c.example.org.</t>
  <t>Non-existence of next closer b.c.example.org.</t>
</list></t>

<!-- tale should figure out the right way to keep this on one page -->
<t>To do this, the server returns:</t>

<figure><artwork><![CDATA[
;; ->>HEADER<<- opcode: QUERY; status: NXDOMAIN; id: 5937 
 
;; QUESTION SECTION:  
;; a.b.c.example.org.           IN      A

;; AUTHORITY SECTION:  
example.org.         3600 IN SOA a.example.org. hostmaster.example.org. (  
            2010111214 21600 3600 604800 86400 )

example.org.         3600 IN RRSIG  SOA 16 2 3600 (  
            20170412024301 20170313024301 5137 example.org. rT231b1rH... )
]]></artwork></figure>

<t>This is an NSEC5PROOF RR for c.example.com. It's RDATA is the NSEC5 proof 
corresponding to c.example.com.  (NSEC5 proofs are randomized values,
because NSEC5 proof values are computed uses the EC-VRF 
from <xref target="I-D.irtf-cfrg-vrf" />.)
Per <xref target="precompute"/>, this NSEC5PROOF RR may be precomputed.</t>

<figure><artwork><![CDATA[
c.example.org.      86400 IN NSEC5PROOF 48566 Amgn22zUiZ9JVyaT...
]]></artwork></figure>

<t>This is a signed NSEC5 RR "matching" c.example.org, which proves 
the existence of closest encloser c.example.org.
The NSEC5 RR has its owner name equal to the
NSEC5 hash of c.example.org, which is O4K89V.  (NSEC5 hash values are 
deterministic given the public NSEC5 key.)
The NSEC5 RR also has its Wildcard flag cleared (see the "0" after the key ID 
48566). This proves the non-existence of the wildcard 
at the closest encloser *.c.example.com.
NSEC5 RRs are  precomputed.</t>

<figure><artwork><![CDATA[
o4k89v.example.org. 86400 IN NSEC5   48566 0 0O49PI A TXT RRSIG  
o4k89v.example.org. 86400 IN RRSIG   NSEC5 16 3 86400 (  
            20170412024301 20170313024301 5137 example.org. zDNTSMQNlz... )
]]></artwork></figure>

<t>This is an NSEC5PROOF RR for b.c.example.org. It's RDATA is the NSEC5 proof 
corresponding to b.c.example.com.  This NSEC5PROOF RR must be computed on the fly.</t>

<figure><artwork><![CDATA[
b.c.example.org.    86400 IN NSEC5PROOF 48566 AuvvJqbUcEs8sCpY...
]]></artwork></figure>

<t>This is a signed  NSEC5 RR "covering" b.c.example.org, which proves the
non-existence of the next closer name b.c.example.org
The NSEC5 hash of b.c.example.org, which is AO5OF, sorts in canonical 
order between the "covering" NSEC5 RR's Owner Name (which is 0O49PI)
and Next Hashed Owner Name (which is BAPROH).</t>

<figure><artwork><![CDATA[
0o49pi.example.org. 86400 IN NSEC5      48566 0 BAPROH (
            NS SOA RRSIG DNSKEY NSEC5KEY )

0o49pi.example.org. 86400 IN RRSIG   NSEC5 16 3 86400 (
            20170412024301 20170313024301 5137 example.org. 4HT1uj1YlMzO)

[TODO: Add discussion of CNAME and DNAME to the example?]
]]></artwork></figure>

</section>
<section anchor="no-data-example" title="No Data Example">

<t>Consider a query for a type MX record for c.example.org.</t>

<t>The server must prove the following facts:</t>

<t><list style="symbols">
  <t>Existence of c.example.org. for any type other than MX or CNAME</t>
</list></t>

<t>To do this, the server returns:</t>

<figure><artwork><![CDATA[
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 38781

;; QUESTION SECTION:
;; c.example.org.    IN MX

;; AUTHORITY SECTION:
example.org.    3600 IN SOA     a.example.org. hostmaster.example.org. (
            2010111214 21600 3600 604800 86400 )

example.org.    3600 IN RRSIG   SOA 16 2 3600 20170412024301 20170313024301 5137 example.org. /rT231b1rH/p
]]></artwork></figure>

<t>This is an NSEC5PROOF RR for c.example.com. Its RDATA corresponds to the NSEC5
proof for c.example.com. which is a randomized value.  Per <xref target="precompute"/>, this
NSEC5PROOF RR may be precomputed.</t>

<figure><artwork><![CDATA[
c.example.org. 86400 IN NSEC5PROOF 48566 Amgn22zUiZ9JVyaT
]]></artwork></figure>

<t>This is a signed NSEC5 RR "matching" c.example.org. with CNAME and 
MX Type Bits cleared and its TXT Type Bit set. This NSEC5 RR has its owner
name equal to the NSEC5 hash of c.example.org. This proves the existence of
c.example.org. for a type other than MX and CNAME. 
NSEC5 RR are precomputed.</t>

<figure><artwork><![CDATA[
o4k89v.example.org. 86400 IN NSEC5   48566 0 0O49PI A TXT RRSIG

o4k89v.example.org. 86400 IN RRSIG   NSEC5 16 3 86400 (
            20170412024301 20170313024301 5137 example.org. zDNTSMQNlz/J)
]]></artwork></figure>

</section>
<section anchor="delegation-to-an-unsigned-zone-in-an-opt-out-span-example" title="Delegation to an Unsigned Zone in an Opt-Out span Example">

<t>Consider a query for a type A record for foo.d.example.org.</t>

<t>Here, d.example.org is a delegation to an unsigned zone, which lies within an Opt-Out span.</t>

<t>The server must prove the following facts:</t>

<t><list style="symbols">
  <t>Non-existence of signature on next closer name d.example.org.</t>
  <t>Opt-out bit is set in NSEC5 record covering next closer name
 d.example.org.</t>
  <t>Existence of closest provable encloser example.org</t>
</list></t>

<t>To do this, the server returns:</t>

<figure><artwork><![CDATA[
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 45866

;; QUESTION SECTION:
;; foo.d.example.org.         IN A

;; AUTHORITY SECTION:
d.example.org.       3600  IN NS      ns1.d.example.org.
]]></artwork></figure>

<t>This is an NSEC5PROOF RR for d.example.org.  Its RDATA is the NSEC5 proof 
corresponding to d.example.org. This NSEC5PROOF RR is computed on the fly.</t>

<figure><artwork><![CDATA[
d.example.org.      86400   IN      NSEC5PROOF      48566 A9FpmeH79q7g6VNW
]]></artwork></figure>

<t>This is a signed NSEC5 RR "covering" d.example.org with its Opt-out bit set 
(see the "1" after the key ID 48566). The NSEC5 hash of d.example.org 
(which is BLE8LR) sorts in canonical order between the
"covering" NSEC5 RR's Owner Name (BAPROH) and Next Hashed Owner Name (JQBMG4).
This proves that no signed RR exists for d.example.org, but that the zone
might contain a unsigned RR for a name whose NSEC5 hash sorts in canonical
order between BAPROH and JQBMG4.</t>

<figure><artwork><![CDATA[
baproh.example.org. 86400 IN NSEC5   48566 1 JQBMG4 A TXT RRSIG

baproh.example.org. 86400 IN RRSIG   NSEC5 16 3 86400 (
            20170412024301 20170313024301 5137 example.org. fjTcoRKgdML1)
]]></artwork></figure>

<t>This is an NSEC5PROOF RR for example.com. It's RDATA is the NSEC5 proof 
corresponding to example.com.  Per <xref target="precompute"/>, this NSEC5PROOF RR may be precomputed.</t>

<figure><artwork><![CDATA[
example.org.        86400 IN NSEC5PROOF      48566 AjwsPCJZ8zH/D0Tr
]]></artwork></figure>

<t>This is a signed NSEC5 RR "matching" example.org which proves the existence
of a signed RRs for example.org. This NSEC5 RR has its owner
name equal to the NSEC5 hash of example.org which is 0O49PI.<vspace />
NSEC5 RR are   precomputed.</t>

<figure><artwork><![CDATA[
0o49pi.example.org. 86400 IN NSEC5   48566 0 BAPROH (
            NS SOA RRSIG DNSKEY NSEC5KEY)

0o49pi.example.org. 86400 IN RRSIG   NSEC5 16 3 86400 (
            20170412034216 20170313034216 5137 example.org. 4HT1uj1YlMzO)
]]></artwork></figure>

</section>
<section anchor="wildcard-example" title="Wildcard Example">

<t>Consider a query for a type TXT record for foo.a.example.org.</t>

<t>The server must prove the following facts:</t>

<t><list style="symbols">
  <t>Existence of the TXT record for the wildcard *.a.example.org</t>
  <t>Non-existence of the next closer name foo.a.example.org.</t>
</list></t>

<t>To do this, the server returns:</t>

<figure><artwork><![CDATA[
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 53731

;; QUESTION SECTION:
;; foo.a.example.org.        IN TXT
]]></artwork></figure>

<t>This is a signed TXT record for the wildcard at a.example.org 
(number of labels is set to 3 in the RRSIG record).</t>

<figure><artwork><![CDATA[
;; ANSWER SECTION:
foo.a.example.org.      3600 IN TXT     "wildcard record"

foo.a.example.org.      3600 IN RRSIG   TXT 16 3 3600 (
            20170412024301 20170313024301 5137 example.org. aeaLgZ8sk+98)

;; AUTHORITY SECTION:
example.org.            3600 IN NS      a.example.org.

example.org.            3600 IN RRSIG   NS 16 2 3600 (
            20170412024301 20170313024301 5137 example.org. 8zuN0h2x5WyF)
]]></artwork></figure>

<t>This is an NSEC5PROOF RR for foo.a.example.org.  This
 NSEC5PROOF RR must be computed on-the-fly.</t>

<figure><artwork><![CDATA[
foo.a.example.org.     86400 IN NSEC5PROOF      48566 AjqF5FGGVso40Lda
]]></artwork></figure>

<t>This is a signed NSEC5 RR "covering" foo.a.example.org.  The NSEC5 hash of
foo.a.example.org is FORDMO and sorts in canonical order between the 
NSEC5 RR's Owner Name (which is BAPROH) and Next Hashed Owner Name 
(which is JQBMG4). This proves the non-existence of the next closer
name foo.a.example.com. NSEC5 RRs are precomputed.</t>

<figure><artwork><![CDATA[
    baproh.example.org. 86400 IN NSEC5   48566 1 JQBMG4 A TXT RRSIG
    baproh.example.org. 86400 IN RRSIG   NSEC5 16 3 86400 (
        20170412024301 20170313024301 5137 example.org. fjTcoRKgdML1
]]></artwork></figure>

</section>
<section anchor="wildcard-no-data-example" title="Wildcard No Data Example">

<t>Consider a query for a type MX record for foo.a.example.org.</t>

<t>The server must prove the following facts:</t>

<t><list style="symbols">
  <t>Existence of wildcard at closest encloser
*.a.example.org. for any type other than MX or CNAME.</t>
  <t>Non-existence of the next closer name foo.a.example.org.</t>
</list></t>

<t>To do this, the server returns:</t>

<figure><artwork><![CDATA[
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 17332

;; QUESTION SECTION:
;; foo.a.example.org.           IN      MX

;; AUTHORITY SECTION:
example.org.       3600 IN SOA     a.example.org. hostmaster.example.org. (
            2010111214 21600 3600 604800 86400 )

example.org.       3600 IN RRSIG   SOA 16 2 3600 (
            20170412024301 20170313024301 5137 example.org. /rT231b1rH/p )
]]></artwork></figure>

<t>This is an NSEC5PROOF RR for *.a.example.com, with RDATA equal to the NSEC5 
proof for *.a.example.com. Per <xref target="precompute"/>, this NSEC5PROOF RR may be precomputed.</t>

<figure><artwork><![CDATA[
*.a.example.org.  86400 IN NSEC5PROOF      48566 Aq38RWWPhbs/vtih
]]></artwork></figure>

<t>This is a signed NSEC5 RR "matching" *.a.example.org with 
its CNAME and MX Type Bits cleared and its TXT Type Bit set.
This NSEC5 RR has its owner name equal to the NSEC5 hash of *.a.example.org. 
NSEC5 RRs are   precomputed.</t>

<figure><artwork><![CDATA[
mpu6c4.example.org. 86400 IN NSEC5   48566 0 O4K89V TXT RRSIG

mpu6c4.example.org. 86400 IN RRSIG   NSEC5 16 3 86400 (
            20170412024301 20170313024301 5137 example.org. m3I75ttcWwVC )
]]></artwork></figure>

<t>This is an NSEC5PROOF RR for foo.a.example.com. This NSEC5PROOF RR must be 
computed on-the-fly.</t>

<figure><artwork><![CDATA[
foo.a.example.org.  86400 IN NSEC5PROOF      48566 AjqF5FGGVso40Lda
]]></artwork></figure>

<t>This is a signed NSEC5 RR "covering" foo.a.example.org. The NSEC5 hash of
foo.a.example.org is FORDMO, and sorts in canonical order between this
covering NSEC5 RR's Owner Name (which is BAPROH) and Next Hashed Owner Name
(which is JQBMG4).   This proves the existence of the wildcard at closest encloser
*.a.example.org. for any type other than MX or CNAME. 
NSEC5 RRs are   precomputed.</t>

<figure><artwork><![CDATA[
baproh.example.org. 86400 IN NSEC5   48566 1 JQBMG4 A TXT RRSIG

baproh.example.org. 86400 IN RRSIG   NSEC5 16 3 86400 (
            20170412024301 20170313024301 5137 example.org. fjTcoRKgdML1 )
]]></artwork></figure>

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

<t>Note to RFC Editor: if this document does not obsolete an existing
RFC, please remove this appendix before publication as an RFC.</t>

<t><list style='empty'>
  <t>pre 00 - initial version of the document submitted to mailing list only</t>
</list></t>

<t><list style='empty'>
  <t>00 - fix NSEC5KEY rollover mechanism, clarify NSEC5PROOF RDATA,
clarify inputs and outputs for NSEC5 proof and NSEC5 hash
computation.</t>
</list></t>

<t><list style='empty'>
  <t>01 - Add Performance Considerations section.</t>
</list></t>

<t><list style='empty'>
  <t>02 - Add elliptic curve based VRF. Add measurement of response sizes
based on empirical data.</t>
</list></t>

<t><list style='empty'>
  <t>03 - Mention precomputed NSEC5PROOF Values in Performance
Considerations section.</t>
</list></t>

<t><list style='empty'>
  <t>04 - Edit Rationale, How NSEC5 Works, and Security Consideration
sections for clarity.  Edit Zone Signing section, adding
precomputation of NSEC5PROOFs.  Remove RSA-based NSEC5
specification.  Rewrite Performance Considerations and
Implementation Status sections.</t>
</list></t>

<t><list style='empty'>
  <t>05 - Remove appendix specifying VRFs and add reference to draft-goldbe-vrf.
 Add <xref target="examples"/>.</t>
</list></t>

<t><list style='empty'>
  <t>06 - Editorial changes.  Minor updates to <xref target="name-error-responses"/>.</t>
</list></t>

<t><list style='empty'>
  <t>07 - Updated reference to <xref target="I-D.irtf-cfrg-vrf"/>, updated VRF ciphersuites.</t>
</list></t>

</section>


  </back>

<!-- ##markdown-source:
H4sIANh8NlsAA+V9a1sbR9bg9/oVteRDIK8kIwQYk5nMYMAxCQYPYHuSmdk8
LamBjqVupbsFxo73t++51bVbAtvJ7j77Ms/EIHXX5dS536rb7ao6qyfprj45
P9zf6uiDk3P4Re/N6+s0r7NRUqdjfZDmWTLRxaU+fJdVdZqPUpUMh2V6I++p
cTHKkykMMy6Ty7p7M0onydtuXqWjre76YzWGYXb1xnp/R6lsVu7qupxX9cb6
+pP1DZWUabKrj/I6LfO0VrdXMGha3xblW/0G/pPlV/r7spjP1Ntb91j3ACdS
sL5dXdVjpUbFGJ7c1fOqm1SjLFOzbFdp3dV1MaJ/q7tpmV5W/HtR1vaPUTGd
JaOafi8vR+m4qu8mqflqCmDg57J8kuWpUgnApihpcPi/hs+rXf1DT7+mTdNH
DIsfktz/sChhefs/906O9unvCpaQwvJfZJO0Km6qt4nu9wfbj7bo21FW3+3q
l2VynfDfxRiG7A/W9fq6fDDP6/IOh6S/02mSTXb1r0neY/D/Pc9GvdH7cJ3n
Pf19MRkP0/LKW+n5dVIWefgNLfdpUdXwxas8u0nLCpYUrLzf7+v9+XQKgMen
zuuOfrF/3h/4O+AR6IMyvcqKHDa85+3o6/WNjf7W1+GWXp3v+Xu6onX9fVT1
hvNeOp6HWzro6ZfJLBkXs2I+KSpvWwfZNKvLrKiaD9Dunv/46vwi2NH+JE3K
W8DWUj9N7sJFPS8AE3+E//hLG2czGvrvgM+967cNYD+f/zZPA0jPpwAq9zEt
5DwBFLgsylEarGZja2tdv0mqCpZzkZalB9bnQAXjCK6vA7gCtT3uL4drdY3L
+PsV/tUDXG/Adb+nj5PbkgjeA2tyk431fvgV7WPvbQJjwVpH13kxKa6ytAoR
BvbztCyS8a0B7oNwZH2jv7nR7a9vbS7dTg1Q/HtCS6DdqLwop0kNqIvECqTd
Xx9s7mr7+5b5faPff+J+H2y733f69vfB+o75fXN9MPB+3/R+t2Nubm/a57f6
/U33+5Z9ZnvDvbu9vW4/f/zYvbuzvrNOvx91D3pZWV92R5flVfemvMRNPTt6
ed7t72x3B7sECWHmB9lVBtDQ59lVntTzMgXaTPJxUo716sH5+Ro96/iYPb8T
gFaRw4tHeQVDzetUA1balysN/7rT5SM0vH39SXd9m087LeHgs/yyMIPjMoGZ
vXqqaa0gBODL8Gy2HztYP+5vPHGwkLPB/QNCDdOc5AoDjiSMbD0prxDHrut6
Vu0+epTOyiyve1kyKnuwuUdAD5uPtnY2erPxpQ+rr0mCIastbpLh5A5+SW9Q
9gG1izT8uchTfZjPp2lJAPq6Ab9uO3eVj1/0ALJF6X/UxrTkq+OePkvv3md5
NPLrpEry2v9wr6d/zm6CU+hvorxtP4UM6OoEjv/r/pYBXToaPRh6jx+tP3kS
Q28fZBwBUA9TlFYj1BkmhDUCvIN0NinuSIz+bRHclkADvnqTAgecVBE4HAvt
tongxaBfBN/g5Cw8H3dBRVkMz/Qlwknvl3ezmmhC75Wja0BrbSAmoB5czeYB
jX7/8lX3aVKBeoXwG+jnSXUNzDFNUONZBCjYzhugwTTe0Pno+jar62mSB7sC
/v20SCfxxxcI06yKEGfJLo8ODw/1+d101rOq2T5oTXMiEuQJe7PZBJVFII5K
r57s762Zbd8mk7dp2UQywLFxXo3m5U1KCOY93LuupxMfVCf4neYvl6AQYsBT
kIugocrh2s31cTnTZEaso5sCKbejPT5jlgM67aNqVGazusKlulcb6/saXwNd
wH9oIY+AReozPJd8vGSNgy9Y5OBBqxwsXybwlpPsbQGn+vDF46g4R+uqQSJd
z4comB8leZEDpqw/Mm/0/HWaDzVg9LX+objONRgj+iybzUAPmk3mV3K64apJ
gJmRw8Uhu5vgvhGFWlERFtfLJ2BXTJJhBb89wscfodbyKH2XTGegnj2yI/RG
/nLx40XLOTkGcjmGIZvreXH2+smTgCG8BtK7zEAEwV6BpoqpfjbPR0RSS+TN
i2x0nUyyiEmcJcMW+TG+Tny66D8h7rSI6J+d7p8r1e12NWygRtau1AUcxEEB
ChZwfdAFgScAsU31eQqEDKoc2IdgHVbMBZj/r8FYdVmM52BYaWAdWpVg7cxB
1QVdb1SgUrF6drZGEiMJrM6xtTpTY3XuIiYo5Jf67IwYD2IG888zwMuLa+Bq
QBJzFDdu4kpEVIIKjE4maEKS7qGnoMskeVZNPYml7l0GEAEPOK9g7Bt3biWd
m7o056ZXX589q9bABtUz1ipgnEs0I3Xq1Akc+z2oGGDDgnULcrJn1jup8MWi
Tkd1RVuFLaVXBGl4Bz/A97R5T+MUKrukXY7RYkvKO7Jvy2Ka4VrxaXmT0QnU
RAIEoAA+T2BAGOO4sM0jO19W4RbosTHI+lECe5dljgsYOS9qONDf5hkom6A7
3ADsaJBuBTooiom36V2FgBimPBDCAg9j8oCVdGDjtMsyqWocRHSLgkxybaao
RtfpFNYyyd4arHhzncFCjgG9e4zLsM70l8PxL/gv4HP6DvGkysYwym/zBBY/
BEx/mwIwV//9r/+s4b6T8TgTvXgI312VYH+MnQpb5B0AeHWLi4alXSIUYHeg
SSbVWwAW/FURNnT0VZrDmU/0dA7UdlV1VFqPAMpAVXfA7QAUQ6SKacEwhvEB
VvOhkaz0JKzHIXgFT6G2MComwLiKkhAWoArQ+j6rn8+HOqnVv//SwoIvQVMa
J4/YQ0NOm39/xyvRU7DGkDZxBrL6CUMV4oyZuaOLWQrTVBXsraNhF2BLguo2
pvOETSQ3YJERScBrZcoji+ek0le40Mv5BEE0GqWzGnYJ7xHgqtqc1DQbjydw
Rl8hFhIhIxDg76+AvfF5wLeMgoDgYJOm99D3AsJWlrAN0iF+LWVqhkKvgaUg
UwPkVpV5HhYDkqpGnAPTJysrgJdd5j20rAJa1p9DyyqiIC20DPsBse2WQvyo
sgyJZve4Ukff4tGF80+TtwhkXU3xoOFhUJhxEUKIAB0FZ4jSxHDnHDc9Qg2e
dj218wGOAveH14Fm0OvCvIA3pNDRUOEjiayeTDCfZ45gXYBoc1SgYQQ4fDjY
yzsNxAnHD6RloABAKBAJ9Up9jUS3AhMkNToRJrJAGIbVARgKppwi2SGgJ+k7
ldQ1kDwc5F5up4fHmO0SslXE0gAkLNRgA7DhIeE++SUUsI+S948HUs2SaQcX
hcJIrwDi0MfT+aTOYEb95vnp0bk2QISd4TklE4WOEZTCQJQgvRPeBCj2d1q+
wcenyR2gJOD9JL1C1AbWcSVKeV0owb4V/eHD2bN9dER8/Ai0todgJwgJV7VE
Uz1MKqs0o9cvYbci6gj4HoYnV6AyAFtJPAweC6tHaCjv3UBMvo/OHdb7Bs/M
fG9YP+mKpBgAUySkoE2id+bjR+TP/CVsLCNuhrhGG8CXx6zRWKSzghXGApoB
4ALvgSERpXHCdKxk/h5xTB41Q/iPCQPaVJxqzVBUmoyuQV2BIxVByDwEZwIW
QnwrXtGIFFu0rJlmjAQFJc+j8IsFYp3YI9MfyL+86/gdrDWhWdTwzgxKNp3s
Uxtd6/Ya9ExYIpEUjQMvwZRPRROoLXuPprbKQZ7CcPgLnPLbvLilURZpCp0l
2g5pIoTJMKDhkji/zEiHZpEM1vi8uE0Jz4yyKAcGOFDcMo6nSXXX4ICgv/uE
iG/LFNX88jID8AWs68Qelz0TvVqlcN69q14H8DE0QBEt4TMxdhhJx+rDB2tm
fPy4di+2D0J0Z5rmjcJJgKEEnCNAa3/7JeLnbJKgZg7HD19npR6RJwMk9AxO
XIF8u0YxdhotAOThvCSMAi7ECzFUX3nHJqejkFG2IUd8VPakFgklfANoFqA9
K6oqQybrwSKEtnMoAEiUfHA1mwNcCdaESEmJvAbGFPdoLu4NJNw8T0DDSXI6
6GJSqdXGSQ5aj9KdW6ifyll1Furf+rqYjIm+lFCGjimDVj5naQrj4SeAhdVd
Di9V2Xs5YUBpAgkaWzPkK6gu0LSXoHTRPrSvIWvUkPUqfdJ9c7yGLPlFlmco
5u+6+0j2OD9+39FDkBYgB9DtMGSRSciHXlvce8gU3MrG2iwG4XJH+jxKBe1p
0mBqgvymhTLljZk7rQ7hU2Qe/D2KPRZZ+K3Pstc6C0WHypgRGczxOcPQrfhz
D6bj4T3MNEEtOlusnsW4r9Tv6MUD+wXM7989w+umskgpysjf4u99mYpz9WTV
+ODLNj3PBws+dMp4yrQPH8BaXuUiAX7XJ6fa/venw3PzOzxEuKa1+8L7Onho
8KCHAPOir70X5KGt5kj+Qx92ARqT6q9fgznB//v6ozMS7gEF0VZodNszVVYf
p9e+rh7G0fRFASKQaLUjyxCey2J0ngPqAJQDtotmxbU2XgTm71kuFE38Lml6
Hdzz6HRYA5psRIw+foRPyfEEip/WexoexBUTWpOd2UV+4ow+mGfR8uD9U6Ri
3AQSB9kBypPpNDgOh2ryiLzFTF/4NlAckzGeAO2I58eXlHmJtsgzgBYFHLnO
QY82ugAtgj1S7l2aEE1k0ohhDoacCVL8ePgTKDMdYMhTME/J9EgUaL3mc5EK
xqiQBVhT71rfJJM5mXUX4UaVzPspng3Nng1vTlUXFlLBdM9QRYF374gr3rHY
TWHPWY1WRJ5eMWsxDHaZhCGJbjnsnS8XyCvRdoYdRxllWs/LvHKngjNi6gXu
XRY/tpiO2u9qBTLhKPTfkIISCsdkBlQDmrHyhEnHVxJZ1uHO7wF0YADzSgCd
kPV7BuO0GBvkCnxogFLH6D5asDp0d5jNkbOrWszh0ZxJS5RtZjRBVELwgKLQ
YSCG2qU5a8Xnw8fMSjkYX3f4mzln4xFCyZaikQ02+reiioAiqEjvHzPQCp/H
07yEsbKN8SLjK9C+wAoAfiMKGLNIXE5DVw8gqozxF4mxnuHLIpdxhHzMKxEe
GSozgEV09qGPRz3IxxM4bwMvmqpm6QhYqfUSDykoJ2SB/lvWcNq4aUHHDNwT
A9wc29Yvuxtb23Bqk2wGq9AU4SLysQ/juIfjja2t/pPouR7wZNKFJhF+ALDR
ywKKqjiZlMPtTBZoArpk1KOTjE+WE5iITyLe3ZI9uvLi1fnFSof/BVlLv58d
/uPV0dnhAf5+/nzv+Nj+wk8o+OP01bF8j7+5N/dPX7w4PDngl1/s/bTCLGPl
9OXF0enJ3vEKK2m+ex7tD/YH48mXgHxkY1ctqiUmaJhtXaTlNJP8A9pVmSZj
lrxJVcHQYxn1MgEmnwGXJ/mCQIeTBViibw/XJt5+QFN0QbZN2xfvgfljy/6B
GSBsVQROBud1gEe/BTNxWLEzWMOnYi3NZxh9YV8YmIqyv8G2HRuzTtwfg/Ud
+4cx7+xEzCW/VbIdDWCcVk4hfyxQ86Bk3bRVC4wW6xQmkqHoeC6z3ECphSpk
wssCzWtiD+7EnHS9Lov51TUbMQYldpXCiPhg4zp9t6t2Sciu4Cd6sKEPc07x
46WSTxaZxfP0nd6bzK6TYVqvIPYYcsYApYEEJuOgykNSG935MAwwDYxpoZxY
XfnryhrhI/AheM0oXMZg3jKDjowPChe1vRmucXvTrjFcSLwMpf5xsvfi0Lzt
+XrYnW9Nn1WWAPgNmpQvRQ7ykoCYzQi+gDTKxX36IY7H0qg5nJNSZjR4o+f5
2otLfJb1R/qTQev0QB0IbjuDFgu6TTNZQyGtdKAqehMyc8fQBnzrwwxjx3ui
SF6za4llcqQVOo2SVpfUjRmcOmP9PS2zKacOMhBCTj3OrtKKfAo2M0YgdHTp
ZoQl8JxowsOKKYR0Z5zKBgSo3YU6lpvbLiSZXCEor6e8GlB70Y0MQ+PG7ZfC
fCR/jocPF0ho8QtpDGsdek7U37bH+CswtjkyDexHvPzx0wDHYliTe7SufE3a
zFZcbuDfiI9f6aegF9yiGwazSwA5hsCcamHzAQlaZo3qL2oiBVh9SNL5VWp1
RNL4ZEQ1khGNx8hj1I6fik8cnf201O48T27ZT1YVE9i0oiidcVaDep4RM3de
Fi/YTS41j7shX3Q6Vvv4oP6B6YgaUjqdsW7lTYPKg52qA/rUrXHZe+cskZAM
B8OhvRWRuMmSPPkFfc3woOicAAL278JEwLisX9yOKpGeisicnLWVcRAnI9Tx
ZaW03/CgSMGYG58PuoJS5cb1Fou6/rxaCBcCfA1SrLZRYWSyGfnMy5TQ53lx
KyiGieOg9LwxvsGt0Cca8FxYMhlFY7Z/AKGQclpFm+In6kC8gVo5q0B09XsN
ds6uaop+haOzVW0VE+MG1x6rdJQT8aneUn7njwEoQsokxVlFzb/JkoY5HBjb
AGDMOL/K0N+xhD0m8kjIHDcYCP577GDIWyDBK57cdZkjkbBCY1qY40boBmkD
iHgiLoIPRJAMU8PpiBaTNpgxf/eBy8zGG2ycsv4ilt6sqLLaekeCw3Z+BkUe
diZ4pBNxGnUWSEXP5dCQfuKClygF0Gjs8SSAV/6SUyZ8LHJgoo+jRw2tlQb2
40+zJCvJEnEMXWGCjT7EJ3mqszPyxjMbMCajI5A2Pym6SeS4AJUw5In0wyOY
0JwdvRLywcA+wQYQuTXG1PCoTAqjJrbC2zBikHRt4TCMCWSjOfqHouO1/mvy
G5Fy1vHDQuKWbzvi1qNl+sAD8JE3EPiih/jOcAEgz6mItCwbrTzagPORSLcN
2rlp+NwNPSsBVla5d8kv1VBAzs7Oj76nI+O8cjimtIbBYIgU/TCUHOC5/Gm4
l2enp8+89YjfP+Jr6v6d08H54lCHHq/RJJOsFQcMx6gzEKrIqL/hoC0/684s
0obbmCcJZxQ/OmSgzlfYqlj6LMvAgjTdhr4Z7bZ9pVbrbjLIJo5pcSbLyu9d
l2BXBMmmykyjkrcbnrEBRIs+8eK9IwmGYSZCRwqAFlYgYxGuwcyEYyTg+Z09
q+wws/aUH2KjzjXS6gxipWicztCAJG8XeWTaRhHtSriX0ws9zYitYVAhilsV
w9dPUBSIJaUnlfB7g83jQPLEElcIIrFqhR2DGe7hvlXeV1Erb5qfrYb6hRWB
MHgwBs6hkgZRCDXRGeHXDT4XfJ/j8YJx48XpPNHjJTXcYtYgBwF5UcW8jgSz
OP4KsNhrrCfC81DKHkg762yBFxGCcsYIDx5BUUgLQfk5kIxHYWCG2lTS3I5u
bt1QmWTYRG9QHtHRyeu946MDHxiewWwBIAQYIgwzLdxmvE917z6zgIFblwEg
n4cDsTnY3HUnfvwLUcYBi8ASQihMnzSkS/7Y/e7Lja3t7vnzPXTfxlSeVILZ
Tn642BkD03vaKUH0TTCyGmUzWF01x6j7QzBLpgudMtOkFi9nw1fFMomCYNZR
pyj7j4TEJio5BFKsOBPjlywv2UyFYE+M7KSZRDlVWMiHyXGH+wfne96KyOVo
w2gYHkO/wL//dXJ6cbjL3vbIesekIKwYKGoOl6LnACeM3OazIstrx47rAA7o
pMAo4i3aXG4Y701aF8fNOFuAgwq3BDXywHrWCi6eA1Ymt7C6Luf5W0TLQd9P
Aib0rfDz1PgkcWVotrhD4qAmrd8sDV2H//7PPVh4eECBAUSXrf7GJyNidzkm
hqN/Ki7qPxoZBxYZsczxM5FRIimL0REeVYKL++L9ttGjiSRMLoO+ByVlkkQU
gzp6oXt4fHz0/d7F6dmG/kTY/geACxpOgI5nJo3wjPDSUxAErgSBSjflNOM1
pQtxkhurYZQGavXniDdTPBV5sJgWHG5x0x3sXezpN8h2n9FJ8HL4Y0Od0aGj
UAHFCKkJVgEY+7/gR0pMop9+y/82Wv430AOl1+nLATCzLb2tH+sd/eRTPlP/
1f3C/6nfYclWD6WMlMaPuNd/hENo/jz6A9ZAwFRuFRkZX0Dw6P8lEWuyog0T
iLiJiwH8yF6IBNTRkoIGXTbfAGeBXtCvTxF+R/ZTrJHPuNLTjwuInmEDJU0M
esmRexYEPibN/C+E2IvLCK1oCMYsxwfxbQcGXjOFtmVIDisCus9NUtMY6BGj
rBS1JlTHMTxgtA4CxMuBH8v4e5w+V81QrmSVSkSVQe4vfFDeqNN3bMM4JX8x
eSP5uJKG+yLaJjRCdpIqArdFT5/m3qBeyjE6w2ZZKl4PwwrIC9OhxAHK8/Rd
I+RBdaoZ8uqG+4TlLC8gzDw1qZb4u/hbZZ0MPeO1NwblHLY8oadzAJ3yJpa3
ZVxCCQ/TPoFR/bfgUvYH0foiufI/4u+fTZKryvx9ghVRx2l+BeqL/v2PXoP9
oWme80Ge0tFSPeGfxCkfta4Bfy7uZkCiWa1fJLNq4VN/HLdGTDQHwTwmcIeR
qxC+osSvJvdjD5qV4KG3j4rkTI7N8K5O2dvLqgAP6BnCKvQIOebqVEZWvjxd
khUv42MK1loZf4m1AUjLTXzh5KmAnk0nvJeR0LLdUJDxHqZpQrlY5LkaZ8Ad
51iSl1FGJzlf7OtBjgIlxvxyiRPY6Xw0d5N6EiKQo6y/GTGqJvyeOZ52VJZR
xdqt/HkXPkz7powR5qbDLMeqKxlBH9XKYksSeD5kKcgpY6e1QxEblAhwfrHY
t9YN4h2847LuAAdrP5zmMWfgt6PrUN/gytw0kuk0B+ZkY5oS4BCOK15QX9P3
djAgJPfTdFRYyWRFACPTM9rFh6/8849zUzA4ARgk79Ez5KMTBLLCIOLRTX4Q
8Lnf3/x+2sI7hQd8p091V5/O6u4pmK84J372Bj57k03GI4x/84dYmUVwJqHq
FmfrcJHmLufkiEfDBCUyxVvBFHufloXgnD8TVywa4q7SaYKaRcWhVJNmhy8R
AMjipeyiMGBs3TIMeloUMaUOaAxU0OkVhoBa5JeZEKRlZcF+iahHwtYwCokx
X/7aRBQ4JGQqP2Is9BF/Amb/RK9mvbRHoYEyZUS3Q+bFOFXZdJqOM5gSzEDE
q5Q9h5Y12u81VoGgtWX1IFNd4026ZvKC5yWs0bLvaJNS1IcReWIm0+RdNp1P
vWJKDH3ZtEzR7e4vXRWnHy59FUsDi6pewzSrlMJV3ke3BTuIzRZk717qW9xq
5+NHZSz2x72NXr+pbX22Ur9Eow/F5Ofo85FM+eT3W4UEF7rbkR7I1+O5fTav
RmAidDGTIcfY8g3bDJQFh+lEKN/QnjCFL7fO4kDKlK+U5LXJekIeb2e3RVRN
phs+o4KigwbjjUpIPatG4kgLTRv+XhxtAk6TBTqazMeO5VOKx2U2MdXjzdcX
RRI72tgvZHi4iL2KTBgvZG+lo8Fs2UhsTBh5QhP9UmIt7seFBoYNfGb/zU0M
+PGoglod/eGq9Z+hVpsDXKRbKxVvq02dWqjSWRWrETpsmtvyCYVW23D0s1mw
P8ifw4dbYPTHu1VIQYV93du61FWMblnlkIDO2iGSqgi7aj6dwkm+RyeMX3Ja
m7nulcrYAMIk7uBbUUbCBB4zWXrM/DiP7FlCTSIkSYW63ugplmOCnpBMsf0h
G0GubpI1JvStt1b9TOdVbTxKHBiVuDz+XmEtr5c/4Qf7bcqLVHPYaD3neu0t
qDYHYPKq2QWETJEzDBuUhakFlK3kJY1QsdGYRYGVTrKOKLnHJgvBMNb0gNlG
pmSVQF/NJXHKJEuZuvy6uEo5MoSAlrRlPBXUvPAQYJsDbJ1EnAHHvU5Hb2Vv
nhHKHxu9VRgJJTeZskDsZuiX2tjCIHjelfNctIOckkVYAU8lZYDzKbEe0XbN
MKuYwYnCuo9MKhVidJJx1ROCKMxb6yxgNCbpiy0GktCh0tBigSZhrjSmPANO
BulishA6n7aFNI1az5nIeIyJbW1NEYbAn9M0d7YHTvp15bEfMmXaVTXhqjjJ
YVnCSZ+ZRFulInJEa+0kdny6lTIUuUTvHbbFw1ZABHiRLJT931s4ijVRpMVH
88VlVEfDOgJDyhtNwBoBuMEk+FtJ9GWJxcvYabxJ/gR5yfp8R341uLypGhSi
1F/+R7drWvBWer2PPSR3TEtlTBmUQm+aBCRrj/sgcYZMkFQ0oarBW5v6ZWfp
aLBhruu/dbvfyXwXBkyu8cQlUggxEiygm6TcEaX34HcO6CtYTlayXOBXv9P7
MVyzoHsIATRw6Qe+kcapIJ2hrh/aiyNsMEFmxicNZndC0c2Tc2tBnJ/umUX6
NsKXjc8gotBuy8AI5O+Y7HxcIjddmaEfQ8p7J3cGtG0Pc42gD14k2EIfYDsc
j1pZ56FcY/EWJvYxy1vJW3mu/3Hx00s49uzyElMkpY+I8Zfwcabw3ajmGlz7
hrQFYZblsFLaQSmrKRCaUugsqa9N3bDslj6zuQbZdEaG+IiyXYd3CnTXmdRX
ZoHBfGagYDfTxiNOijp1Ytzbkic9Llu2RGBtwrVjh4CBsZr3kMDSyhsPg3xa
iUsJL8wsMzSotYQb8sL49Ye+s0+ouOSdT2Se9tWFXLOF9X0nr7QwhHb6itgP
ERXvHt5v0OnDx9gXwozHWH7Ey4+XvYOGjxrKbM0DNTb1ZwqsGbdkTu+XXK1n
sL9wGD4XeyaLH5Tc6VXcoVDZWoyBSxlmc0jkEYFHVpJbv3KMf7nqsWfSZNmx
cZMGeekeJqRT6l2V2BrtxarG6iQZphPurI6g4TRvbGPCmVlUeMfjrnnNANii
oGrKWEBIBvMDNKXPotIlQDBUazcHnCfJTUeLlsP7DH1ngbrzZ0k5ixkt4m4B
hS4+axEJjRPzkaf95KjxDz1DrImK2nlw5jNi4XpaK2Mi1hw1TwPTyT6RMbge
ey4iID5+f3uyNWW2tvYnaLxLOU4rTPlIqiVMw+6BqXFWco762AwTHxlTIhvW
Id/Hp4fN6g2zHHt87tzQ6wGYx7hBBwnvT1lYRGb+OR/TfhASIjylLo3n0jLj
w1eIwL9I8vxHpX6mukGOLzMAKFhVwQCVtOKgqJTrnxl3A/DCEH2bOmiq4r1G
YM14E8o0k8LZUaEXBttiZhzXMtEzXlPGDi6sbKFsy6Mw9qPDnBQ/usQH6IWX
QDNuCzC1DCWVLC1lv1Q0Qiu0ZxzaCnSCzDu80EdPn6KL4zaTKhkYhJ42e3UW
Bid3cmnlLH3HT4hnKioaxKnExcq1fKbaxMsRSwyA/Zww66uYwwZNHawLTV83
KistAnDGktGspymgpHQtQXTBMp3xWFkfC49bphNyzRl/j5h0pm5OWqcUjPWk
E6OrSNkKWJ6lR065c9B5RjV3H7G5Zq7UBKiJ2/tK+Y0AgmujozKJSrxn43EE
Vufwcqfggdkb16V6kofKehnnefbbfFGlqxdYsWV/WGh8R7nYeZcrHZNJB2Hp
HDwYwAfc94wIbmPnkLbion/PD2z0Q6CpvZ/IefSOPZywXvT777Gza4HfSbxF
rQ4hCZu0USH5j51HmUNoxvKVAFlH3nfcNfHSTZhw/TMQRQZfeYpIwLgSOsXZ
PeZHGgL6lRll1JYDxG/3e3z7UJN8Q9Bziwg+gCoNzDuZB6nbtBtoxL15g+zL
aI96x/ANXHRmxoDx9HRgbcoAdkoxceG/hGsBpnkh+pZwv4xkZVudvE3FIDfF
VSW3ySaOLvF1F1KE1a4JeA/c2TXDusQUODhky32tKUOduXghcf4sjGI48dIA
8HCS5G9lIYduIWGQVh71uw8Rn/XTbpbjP8ywCaOje5SEaVpH9bTIXCKvKbyz
5bEPl0xW+dBauDHTNEwv8CKTPhU7LuIlCK4iA6HmOIZ7Cwcg919jDEpUbZ8V
JRy23W5/yZZbY1OqNAkK75ALu3pchFkob0k/GcGCKlOVQDzi/HSPy6P30CoK
4hJaOiWFQ1xcHAu+yTA4gonw4JdM+uTGyUxybMJ9FAJuwObCWCJQUVk4lZmA
jUCNM5lq8OuE22qwZ8zrVUYF0aahgs/Cue2DmVX4uZ/PG/TCxF6pKLQus6t5
6fLAv8II5cjeGmNU5ZfGQD40OvNLUv9BfXQN5UB5fEl160G0TtrD3RZw1F3M
odDIy5IyK7DRci5N+Vk9MS3ytHRV82KAixu5ecARZi6BJ7zGIoxiUfNe/Nwe
PGdeUyG9IUJ+2uKXwvdaioAX+g46tqJUyplgcNUyQGzE+B0SeA2xWaDaXnMa
oime9HoFCnNsbXxH0G8v5b7rNdsx85ray78X+1EMGrqug3QGVBJDMt0gKFGo
KeHFLkoeFkaHiJLqOpkIpcbt7VXY6UeaVrCSY/XOlr17DRoFBNG0bVtpXz8W
2pvofBvTjlv72ASU1gNvU6EiLUwanEskUtirv9BmVo7BGsvsEuNZN0/cwi7a
cIpghzhkdF3pa96Yo7LNumIuRBQiLBcVAMaGKoXnOM3Pml4uvcgzXXlukwYQ
1CxSw0i0SbkovAucBvCR+665/j/GBOAC6LZmFWSKuh4THbS5bUtYYfC4YdfD
mUU3B7HdTB4HE/6DSnsV4Ra60sIOPWLdE/N33RMWdejGw1TGBPQ1iSAC0dFx
X7iQUZOCodKwd0hjiNZWE2xq0u5yn+caLOM8AbHSe408tDMbVnM4rki1KRqO
SEvDSQwxNkFn7O/OtWruDwWk6AV4RSJI8JYUm7NW2mA2J68qpxkYQ7nVE8A7
5aSdWXI3KRLji/OBlLFX5579mO34KW0fI90j2orHMIx27zmTuckbO+tU4Kyz
fSduY4+mRew13ho730CdUsnkNrmrgiBX66nZCmGag1uV2mUr8rXdmc7jiNrO
qc8ufd9EllZnvJHYnajN7VecKOCtPEy6YBst8RURj6qI1tN3CZlhRR6ETKi7
p2H76dh4gj2n2cnphV9wi+xtMkknjitwm9oBXzVi2qXff7WVd2MO65z2jgTV
cmOV7fHaYUSGTd9ShS3wgpQ0VrxGcpTNkom7Hueq4DlNIvg5N2OeUJMcWXSo
1lehGSO8388hU81Ch8hANLoeiw9spItfonJ2m/v5WhdMHoRRwxS09gxdvAkB
2nR0Q2iPi3dRkbIKEmT9hOmdyFcZ10WiQCe0MLBX6owlwtRJXecw0Bgrzpyw
MRrurb/9nsuZpcp2M4c7X2reZPtgr4Be1KUCyOo68ONSXqVZ4oLGlnh5q+mv
2ZySZAjqN5zz1JIBrUOHrNdRbY/21WhDklVxgljkm/QsIUwwm6XvXHOyYjIO
EIXTEa3DuAFK/w4Y6g5q1BN8Toqt3Rh0ZGI1zvCWLN+9lNTFlHq02YbP34qp
7viCkLbH9ImoEfNJeTFRGPTZwQIoCjMx/bOEVRNK1hm5BAZu155zlhbMN421
VIIthiEOZQxVMBGBpZq0K/bW9mlBG4Gkw4VQaIFuj0JeQkycrjFi/21yRW7T
YqENBhxmNpkzvVkRqUyWrDlQu/YHLHSDFjr4MxcqpR3crDAQ7MSRJRSKo1ux
kwK/mVd+C36rBxPT4Eu8MIOYozBVo52E8ZWxOubz88Jri9/qkz5PU6Bn+H2S
Jm8/fuSQm2HbUQUQftfq1xZdutKviE5e5dTfVJ7xWzfxUyxlSivq+HoDTCn2
33Me96I0j6h57q6Za3Yici3f2WHIzR64cKqnz1GZpkaWylkLZfor3ypEhgjq
VJncb2sazcmzvjdAne2fHhz+dUOvSlwMu4POy3SNRwHgjyeuqa9smKUkZZnN
6Trfyq6HQXhwB4IPSPUVOcQAWnvODrRNfEQfAOtRrtEby1vsRqu011xaiii4
RWoVeLgNBTj+jIwErDRz0YB/2U9tmm+aEJnpeGdjdpF4CIKAHzWlKd8p4k3m
GgXuHLuovsQTpVte31dquFUwfJl6+TpCsJNKuqHRcGl7AqjnNBzQlRLbQbu8
DNTjyLvm9TV3arDwakYWzgw38HahmhjQsWKCFokJTllDh/07cgwVNqlKJ8wr
nGliWpcgDQaKgciy3Gs+mypeGDkmvZYnnYbMCbp/StWhO1JF9GlDokBrhX+7
gQG0dDZnGYd1ZRQ7PpMWro148YX1p4acJe4Ab47/SaRF2dYTA7ydwamPUbAX
x3O6o1grtusaGQRypwpe8QB7s2zEGtGxq8o5htHwmUyUTSMf4RURnMDulzMt
stoJQC6ToCWi/tqlkkcpji7rkMO0V7lTc3F9NJNfASd12uw6xJQe9gEhE763
XNqbDLgNt+F1mwIID4uruefm8TLYsQhHuWURioFOzm7VRHIvbSQYJHjsskha
HRZ1EwSmXzUciBfSX+qWeGlQeUrXrlP+JQleCsMo8U157q/ABRKvJ4oaDFNb
UjSOWlcmbbZXp6Hnhp1NUUy6AHfmcNy7EdfrggRCzresXG1+x1UbySckgMMo
kwtAB40JvX6NifgpXbWQFyR3Sa6x6h41tParnthmcWVkzXIt60ihQgCuZrC1
IEGVl+sk36rgStOQDVvb0Ww47+5YjOeP6pko3IQU5jW/bfRjsuFYBLW97dM/
BL+CxdtOBw8EFDJsKu9ufCXkICAE3cF1AE7S/fcb/fTd1ULtbUEp5QmTmkxC
tG5SdEsGk191w1Tju4ilEanIfKsMR0LMxkYcn6VNDs32KhvmDM7NNaQt8oAU
2SXjf0L6WeWjIblgDTtnPspR96pwIUWPo8S12QHsxDdhpWUn4IjKWhvIQpl+
iHVG7jYThV6Yf0/Ndxrpg7m7UQcQJhM+71X2L4QyrpsdbcrDewwwVaEAsxGo
e2IHyqCGKIgLHrNtZ5vSDsRCmfBJ2cvozudDVtqXaw+W4xvdYaf3cO1BLs8x
G6Ye8outmL1lgtiwV2JRgUXjeuBXci0JXkZCMXHujM1QyqQTHqBE0HWfDA8z
oNe51lwi7lWLGfQC2xEVc5igRc24KJNcqqQ9J9S//3VxenC6K807bBtlr+zQ
zUfZ373/UBKZG8wAlRkN/vqIYxrhY/bbLfNG62PwnXPNJN4hUHA5tkXvs4wT
r3chtxIMjEjFMvRVJaqHuSLUq1AsZjVzgWkSmws9U4cSm6US66uuE/YwskvC
CgQ65Q4aNykVyCkTujJOG98ksT3hnX/ggD3jJJskxQVQGYz+kRy2GAvEfoKr
7UvvMV3kUTcNHIlCV8oPXTFOEnaznxYxtcOGL6Ag7KA2Pjpp2kVsgBuDca+Q
lNnJxtaW9NqR5joTLBxDT2chnlfvEiax7aUZYxypE9ADOWFlpmmv4Xr2hF37
uQ+0vR7VPubu8LVpwJ6YCpoi9bhTS4yWPh8KLgIhzz+2hHWNZxA6yl4uSM4J
k5AkFouX2ra14V9e5Oe6qSjXDcZ6I2fBDsy4MU+cd6rMNKbxcCMH2efg5hKO
MHtOcUKy2D+VD1ZWk5icgvZO3N8pOCrlT2JiM17XX0/bMrA0i7Zef7WxvmFK
7VcRxbp6a8BXzRzh/e5TWxd/Dv/OMekkCz7vVvT5R+/WHzgM7LhvHvMCTz8i
c6HbxVr8gmrV+PT6ve3e5prFqFf5EL0VGJqYwwMu9Oq9sNV7Is1lVLg+vOly
bG7P42tefJqeZMMSfYWm2fkIjPlv2UCKrpdDastuUqMI4G1hd74GfAoDnJ+D
0tbvrfc2fu1w1rkyqVRAn+SWjlYnBxuvuZrPZiZJ7XIOq6FKtxKOHs7cZup4
N91IkuDJPw9OX+wdncBvp6jAd2waYke5Egn5iu5JbuajrgU9cf3WzMrL67sg
/XUs5RsAxlTSB6YAY2J9lOcl/rCwcSx2eXYMYkSevmEaYIxJm+NVcANbFfU+
DtriIo2Ny2LWJV3MxRkM6uE2VHyX4OL74O1aRDeDt6bZe278QrL4wwcv+eqj
3A3ZuFzAU9KNEYDiKLj9k4jtJTuK6CrtNjfQzPveGtmW1lJkhCa/Lb7nEFU8
dlAvqkc49OKWe3z1JNYmpMlH7wLKshjO+WrSxqXAWL1irjcZs4BEmpJbLLnR
vfmTNW5P14hvuvdNwjfCrGvvVmn7dUeccWZYcWcvuh2NGpg84IYeRgqKgqN/
F5gmyhe+xL42AUPTypVNxCKq06ckZLmJ1uBwaxoYIydsgmf2tqsb08iNtbJb
Jbu162pYrkiic1QhbijRLwQ/AGIyIecsvorx7jJt3i8jO3svt67hfJx+Q0et
zPlibBTv7CqrdEV7rQW8C3rFRVB5ctU0sla8BRaJrCP5vpYgYXPB5Z/K6wjD
KRTolr0L7/20t5jFt4Du29uojdQONWX0tXz4ysR8lKVdyYlsv28H9TkMurUi
dkeZy9r9r+Pr0rH/WPAAfBZ8r3zX10J1euHFvlF6glzwroKP/bjT8ouLmGD1
XkVZWB2VeLd8G7g2F2e5gPcwEllwV65//ujSQwAn5o5nwp4FdwohkVhLoeM6
iniX93aDy83l2l1uSUN3sYKYr4p80bVUeSr+cXJzV1oSgyVlSa5PNRkVt9fY
8o4GGd3pVXPnb8xN11wJg1wgzKly4ri/9/7bpSSgWkiAr9wjxI1eNqxg0faN
D9d5qK23bClSx4hs48jOSkOiE+sslFqGFPOPvtOVGm6LG4za36Q5X55akO1F
lqmVR8TVKn4uqdxt3qMA2xwNIAynqI4lOSjih3LLfe1PrkhATibkSuULbTGI
hDEsUewdGdZFga3OytrSHCcQmDVMKRDvphQuDEeSFZzChjF4XL3xXpH9kF2m
+IVy7k/TWuldgspMJxACU+wKokUKNISAioWABQqlq1BwE3cgi7JZ10AoGLAD
zRyljkou67QMAYXFrcg21yw14m0ni3QHllVy16O0hSQ50yrxqlhoeFEkU8mW
hbesB+iJm2igpuSPKSbmb0WK4Vei4Uvw1wp5Sh5DzsUhrpCPqYjpEgOhbXGf
b+YfxFHGc+Mnzkp7uthIxjaWpE5h+3CEFJBBykBYwJl+jFy6pjQskTJbPHZq
nB41ifJ7Cjk3RND9nBq91darRd4Hafll6iPIBvYLow1K8rS4Ka6gbslz59vE
LUSxD9vQxIsrtvlHZsPSig2ZD3pbavzDPh0+yJobWB5083hwJ1hHJDm9g/FN
sLDZkNn4n/2NHUyNAET36reUvVCUTcAypUwz8Y7QBdszr+FYxKbJjWHvI6Nu
07LKbon5n0jwHTT9ufdplYarZYFM9VZIln56m7spK5MrA8ndz/7og3MuuMD8
lUQqcIBtV6N5xVk0ORGneLECkcG+gL2TvSYjbrsoNfYpmsA/AodGKdMrzLG5
0yu+J+78DnBlqlcBuGvqZVLCZ+i7WeG07qF7KeqbqVfPztY0VmtXKx1Uurkr
r/QLdC5Z9IqaJs2ubh69z1q0+IunB17hOf20fMEGnf9FuF3rNqQZww17pbCe
a5tS45R9CCuWEswwWRE8ix3qK2x7U+vhZOJFXhWHUew4tM112gh6RaUjMm2l
bz4N7Xv6bsP7LrTZ6etBF71E8PWezSxieYoYZy7xfTAGnJw769RuUZ3wXbor
/nl6Z0l38MoxwhngYghIXbp1CfdjfQxZwuI+/ma1T06u+H3ebsd/kT+CF7bW
iPkiFXCGWNFMLeOkJZHzljMal+N1OpnhOb0o8gywHkZffZNm78Goz/URqIJZ
DXbrWkedJ+gp0K+TCqX/6j6QaSEEUsHXxym8jy1Q7t7DU6tPi6oG8n2VZ+QN
q++4/Yjaq5JL/XN20zqJwkteR2YnzneJeb1XzgbsqdN8XKa/6vM5HNfq/s+9
k6N9fZwMK5nkYJ6APHuDl9ZOKr36GtQBGoAeUfZqUtDZMXAnPDJ0dnlaJilp
VcXNBSmAI44NCqpgmafzgsBhdLtdur2ajuWQtRxkS6LwIC96I22/dYX3VJLr
kSQw5kWBCJtT8xe8lv22xatGvJazp8ZeWoqoVUPMRKzvOFWAqxOk2pD72K4C
5iYglkhtOTpx7kzsL+a6+5IeBWx83FHuwlfRXxzK21KcXS6RlS32ihI92PyD
467qXq+n17Re+BRAQCc97xseMPhIHt7T/Scb6Mzs9WVAvhx96aMbS566+OeF
XhnJ5lfgQXpy3PIkrDKv+r1xc6GNj3v+7Jv80NWDdtP2FC3xyiyRR/um14QO
PWdLNOzjNkIdNIDiVpDW1UqHGexBki61AobXtsFV1D52jdURvkqj3SYm8NnR
fOEtqfTxY1Rim6A2IAiILC6cbA02gVHzW+eCka8dYfQ0RnNCxUY0cEzAsSjN
PfNN6S3sbQWwc4UIYe/g4Oji6PRk79j0kq14dejPVJJ33eg4KUSulFFFYDNc
rco2EqVB7fmbS3rDXoiKEhiPur7GfWeptSm1NAl6tTWyDOKxv2n2BGrpu+Pe
/6axupYR/DSG5naoQ2OdTMgmo6RZLCtObfdIagDJuaoFaHnpjK180vqw/PYq
1dht6aLASwLxqyD5sUxBi8wr4Tvffqu73333/HDv4PDsL3/p6mKGMYBd/Y9X
h2c/fas5FrRrwxDf6my8q7eeDB4DxZkB4NlzPHoNzBT/3dX2q+ZpafdzdCKE
bJey9+ri+enZ0cVP8VCtIwy219dxEOSTEUFfgwydgkmYluHnqzKe/7Ox3l/v
9/sb/U290cchadzt9c0d+GdnexP+u7aYSdtVcEorLaa/jZ3H8fMF8z1e3+xv
rG9sDtb7/OegP5A/t/oA22Ci8mJj0B/2y+ckCZS1fBsFr9RHzu53VEzx+pSv
K9fnOnZDN+uPo9eBT7nH5SIOIPZiShkBzCE6yjg9Gh7uKrz7197mLHc2ctzl
L+/KFNhgUl6l9V9XGvcErjz6DlgYl8L7AZqOdnd3uxQ59rR4xbrSgaINB/lo
4eS8MTZ3tra39d70Kt/YeP8q+/nJD6/vkgsAvAd24z61/pQVEwpaCecx/gRi
RxWx8bBH2X3M58JzebQUdWJz4sR0blGhxd+6EFj96eaPO09eu5P1nS14WMqm
YVUYVuNoSt2W3rcWLo+M0KX9XPVqlTJXXlkHmWFdSWinHh1oRbBfk8oigVnD
9dBo7aYW9XbzGTEis5eQixttQZJi8+3Ok5sQU0IkgYcYQ9b1+unmk5dHIJtQ
cRDav38UeVBGAz4xkO/+CEbx/uDk4vzFP04m7x/CKRqM+VN5xbAXc4uLFooU
H25L7btAvU1ALCHN+c3ND78NX40Oq51qf/ZTO2l6tGnyM1fiiSLqRBJqxbRG
ymE0jkcGhvgWzIQ29unW6bMOtfOuwn7eKm7onfprN/sJWnvrVTsuY+Pakmbf
3sNP9wCiz02XoPVi88ksuwfrPcTnt/VqA13R9AfhxyguqdfWKbP2gMkWE8cX
k8bm84v+/Nf+T5MX709lKZLohw3JfL+ZaadLTjZuFVj4uvff/hM0YX6QAvvi
n74G+0dqryEkL6XwmYsHalP0gPNjqQXuRv2xauHp4dnZ6RlrhYOdxzt9tVAp
NF80qR2O/sU/l+iArbqXr/zhz0MVwD9Q/Ys0v0j1+1QUfWT1vEezT1XyDN9u
aYzDiZ1yU1bzXcsUkoZmB3tcpHapz1O7Hq5xfY661WOXjiNfBXhv+o1VVgsx
pWgot203soovXMyqBfqWauhbeom+1dRhfKmi2qi2jWZtt9KedhdKSCrFH6u6
PGCQP5E5O73l0Q9rnNIbu1psNjylN/EdVqY5VzWDPz7dkXBZFJFbRqnnaZl2
IncM4eBy348R8BQ3kgt7ogV+Mp9v+AyCeo+GUhI5mHAEnB5dBpgmKl1RMhP1
s7eJSfFKPJ5qG7DVcdLsUhV4+P40abO5tbO9fb+0aZ6yRVNA6mWeh4WuTGbv
TFj8QdPDdw8Dj4d1HPxBmve4hdmEk2TVEo27bVNMy84n4w1HP8KmnzybTdPn
j5/89vhq+/XJm6Vs2mmvIUERl0bO6iMoYqdyBmK/xUB09mHMfMPxlafpHh/u
HJ+ttenbDXVb3a9ui+Ksl2nZP/zj6YvvN9ckQcGKAEwJLAyMADrcGLuJDB09
nNc2zZbzSExqB5WhYUvE3I3D3I1YAKcjeZBp7joyMkSVx+3wso1JlsC6rx8k
TfryZlOaLB3kT5Qml79ejIqzH6/GL47799nAX+QrC23fL/VQtbGoNn3Jp8Zf
b6uX+z/8vPP++aOD9YvygUpTQIuRCayDHI/EIWwVwCtiO5+uLjXXYI1Y2H2o
7bS5ah5ktH6RxfpnGayDzQ20EQwW85/3GqzBjQgP0nWQGiNtJ2mIqM82PPGh
aIbAKxdF2FoVmlbnSus6/ywdYmvwePAAi7W5Jk+FACi00N0y2GASUSSwXNtN
KieqjL4GtDMwsWNGNh7U+G5QcTk5f3N4Fq550YKNwYqrw5+WeOdDXjdoj8MQ
0nOo44s5d5Imx1c/71Rv/+vJztqn+gPMj1mk0c1iZHrIu46u/VDOF+9v5/38
ZP16493Wm7tn90mmtjOgvKL7/atdwJau0/YWnOa9suW3Z1vPvv/+dVVsrh+P
kwdqeu3Ljri/ajyF4z47PTt4ccqthx6grjkhscgn+gBtzVMVjd72sPCDx7dU
C98ilSCMNzRlGP58qab1oHEeKKa+RNFqv7LnM5yjf7CcWhaqVy2JIA/woLZH
9P/vC7P+48Fg40uEmXbW36e7Y/X/Ex7ZFh4exeO/mIn7btp7Y2zfhDxBLuxh
G6NFO/bctN/E3ORL7YtmztN9EuC3wc7Zmzcvr4fVo5s6u36gdRHNwzvGvl6e
Y/bT/LJqiaHRjINHhkZj23EYuAVU8Mf2aPOBxgUH1GPjd+kQf6LxOx0cPd6q
69Gb29f792Jni8xaEsFVn6Zi/B/TLz5Jveg8VL/IsF17dAXa5ysabXqGXhok
aJgMDen1WbLrIej//433BwngK71PXQn1cXFlbogt9NmzfX04zuqilBzM1qYp
xbAqJilfLWCux1LwKrY7TRO6Un1amBo7anw7zt4BDlHzZc6XkTJEIkB4kzLU
AeIa9tq1Gf9R51O7kGo+nGa1JHNPk4w6OuJN7dzBD4sBcJhLmNTG2ZtNj7GZ
d0Jd4ny6poYBMIL5LssBBbi0pJjX9LurbnA9shyh4bvuNgjaGBxIl+Lpi2vf
TW4oP78hz0dtAPg+oNdnz/i6sCnAel7avtC2L1eVvU8rGMZeH5ROZ1lJ1IwN
ZnmKAUzxAiu44PsFdzi8tgXN3rrxZsMlK9+EYRGB9FnCfSfSDhY/CXzeFOVb
6WzZXqoPQ9gkWb79NcGHgCnQoMGdgvIg3U+GCPid20eYbk+7wfqTM0bLs/O9
LsOGY8DfRT1j8MFbmDZddl5YE/Ddgs4hZgsMEuw0IjNbWuAJqWSe6sDkxgZu
hkicDqMZZXJZd6+KyXiYYsZfT9Gxf/gghM0tGWGGbQF6UVKdDHcbhW28yHKA
oa1KKbDUCZhuN8UU465NcjbDPIZhXsmlS8FCPnxoZB+ilmUuaMKUxVE2A75a
zQFqsO3/DSSJ+t1M2AAA

-->

</rfc>