<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.1 (Ruby 2.6.10) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-housley-lamps-norevavail-01" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.18.1 -->
  <front>
    <title abbrev="NoRevAvail for Short-lived Certificates">No Revocation Available for Short-lived X.509 Public Key Certificates</title>
    <seriesInfo name="Internet-Draft" value="draft-housley-lamps-norevavail-01"/>
    <author initials="R." surname="Housley" fullname="Russ Housley">
      <organization abbrev="Vigil Security">Vigil Security, LLC</organization>
      <address>
        <postal>
          <city>Herndon, VA</city>
          <country>US</country>
        </postal>
        <email>housley@vigilsec.com</email>
      </address>
    </author>
    <author initials="T." surname="Okubo" fullname="Tomofumi Okubo">
      <organization abbrev="DigiCert">DigiCert, Inc.</organization>
      <address>
        <postal>
          <city>Fairfax, VA</city>
          <country>US</country>
        </postal>
        <email>tomofumi.okubo+ietf@gmail.com</email>
      </address>
    </author>
    <author initials="J." surname="Mandel" fullname="Joseph Mandel">
      <organization abbrev="SecureG">SecureG Inc.</organization>
      <address>
        <postal>
          <city>Tacoma, WA</city>
          <country>USA</country>
        </postal>
        <email>joe.mandel@secureg.io</email>
      </address>
    </author>
    <date year="2023" month="October" day="06"/>
    <area>Security</area>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 127?>

<t>Short-lived X.509v3 public key certificates as profiled in RFC 5280 are
seeing greater use in the Internet. The Certification Authority (CA) that
issues these short-lived certificates do not publish revocation information
because the certificate lifespan that is shorter than the time needed to
detect, report, and distribute revocation information.  This specification
defines the noRevAvail certificate extension so that a relying party can
readily determine that the CA does not publish revocation information for
the certificate.</t>
    </abstract>
  </front>
  <middle>
    <?line 138?>

<section anchor="intro">
      <name>Introduction</name>
      <t>X.509v3 public key certificates <xref target="RFC5280"/> with short validity periods are
seeing greater use in the Internet.  For example, Automatic Certificate
Management Environment (ACME) <xref target="RFC8555"/> provides a straightforward way
to obtain short-lived certificates.  In many cases, no revocation
information is made available for short-lived certificates by the
Certification Authority (CA).  This is because short-lived certificates
have a validity period that is shorter than the time needed to detect, report,
and distribute revocation information.  As a result, revoking short-lived
certificates is unnecessary and pointless.  This specification defines the
noRevAvail certificate extension so that a relying party can readily
determine that the CA does not publish revocation information for the
certificate.</t>
      <section anchor="terms">
        <name>Terminology</name>
        <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
        <?line -18?>

</section>
      <section anchor="asn1">
        <name>ASN.1</name>
        <t>X.509 certificates are generated using ASN.1 <xref target="X.680"/>, using the Basic
Encoding Rules (BER) and the Distinguished Encoding Rules (DER) <xref target="X.690"/>.</t>
      </section>
      <section anchor="history">
        <name>History</name>
        <t>In 1988, CCITT defined the X.509v1 certificate <xref target="X.509-1988"/>.</t>
        <t>In 1997, ITU-T defined the X.509v3 certificate and the attribute
certificate <xref target="X.509-1997"/>.</t>
        <t>In 1999, the IETF first profiled the X.509v3 certificate for use in the
Internet <xref target="RFC2459"/>.</t>
        <t>In 2000, ITU-T defined the noRevAvail certificate extension for use with
attribute certificates <xref target="X.509-2000"/>.</t>
        <t>In 2002, the IETF first profiled the attribute certificate for use in the
Internet <xref target="RFC3281"/>, and this profile included support for the
noRevAvail certificate extension.</t>
        <t>In 2019, ITU-T published an update to ITU-T Recommendation X.509
<xref target="X.509-2019"/>.</t>
        <t>With greater use of short-lived certificates in the Internet, the recent
Technical Corrigendum to ITU-T Recommendation X.509 <xref target="X.509-2019-TC2"/> allows
the noRevAvail certificate extension to be used with public key certificates
as well as attribute certificates.</t>
      </section>
    </section>
    <section anchor="the-norevavail-certificate-extension">
      <name>The noRevAvail Certificate Extension</name>
      <t>The noRevAvail extension, defined in <xref target="X.509-2019-TC2"/>, allows an CA to indicate that
no revocation information will be made available for this certificate.</t>
      <t>This extension <bcp14>MUST NOT</bcp14> be present in CA public key certificates.</t>
      <t>Conforming CAs <bcp14>MUST</bcp14> include this extension in certificates for which no
revocation information will be published.  When present, conforming CAs
<bcp14>MUST</bcp14> mark this extension as non-critical.</t>
      <ul empty="true">
        <li>
          <artwork><![CDATA[
name           id-ce-noRevAvail
OID            { id-ce 56 }
syntax         NULL (i.e. '0500'H is the DER encoding)
criticality    MUST be FALSE
]]></artwork>
        </li>
      </ul>
      <t>A relying party that does not understand this extension might be able to
find a certificate revocation list (CRL) from the CA, but the CRL will
never include an entry for the certificate containing this extension.</t>
    </section>
    <section anchor="other-x509-certificate-extensions">
      <name>Other X.509 Certificate Extensions</name>
      <t>Certificates that include the noRevAvail extension <bcp14>MUST NOT</bcp14> include
certificate extensions that point to Certificate Revocation List (CRL)
repositories or provide locations of Online Certificate Status Protocol
(OCSP) Responders.  If the noRevAvail extension is present in a
certificate, then:</t>
      <ul spacing="normal">
        <li>
          <t>The certificate <bcp14>MUST NOT</bcp14> also include the CRL Distribution Points certificate extension; see Section 4.2.1.13 of <xref target="RFC5280"/>.</t>
        </li>
        <li>
          <t>The certificate <bcp14>MUST NOT</bcp14> also include the Freshest CRL certificate extension; see Section 4.2.1.15 of <xref target="RFC5280"/>.</t>
        </li>
        <li>
          <t>The Authority Information Access certificate extension, if present, <bcp14>MUST NOT</bcp14> include an id-ad-ocsp accessMethod; see Section 4.2.2.1 of <xref target="RFC5280"/>.</t>
        </li>
      </ul>
    </section>
    <section anchor="asn1-mod">
      <name>ASN.1 Module</name>
      <t>This section provides an ASN.1 module <xref target="X.680"/> for the noRevAvail
certificate extension, and it follows the conventions established
in <xref target="RFC5912"/> and <xref target="RFC6268"/>.</t>
      <sourcecode type="asn.1" markers="true"><![CDATA[
  NoRevAvailExtn
    { iso(1) identified-organization(3) dod(6) internet(1)
      security(5) mechanisms(5) pkix(7) id-mod(0)
      id-mod-noRevAvail(TBD) }

  DEFINITIONS IMPLICIT TAGS ::=
  BEGIN

  IMPORTS
    EXTENSION
    FROM PKIX-CommonTypes-2009  -- RFC 5912
      { iso(1) identified-organization(3) dod(6) internet(1)
        security(5) mechanisms(5) pkix(7) id-mod(0)
        id-mod-pkixCommon-02(57) } ;

  -- noRevAvail Certificate Extension

  ext-noRevAvail EXTENSION ::= {
    SYNTAX NULL
    IDENTIFIED BY id-ce-noRevAvail
    CRITICALITY { FALSE } }

  -- noRevAvail Certificate Extension OID

  id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 }

  id-ce-noRevAvail OBJECT IDENTIFIER ::= { id-ce 56 }
 
  END
]]></sourcecode>
    </section>
    <section anchor="sec-cons">
      <name>Security Considerations</name>
      <t>The Security Considerations in <xref target="RFC5280"/> are relevant.</t>
      <t>The precondition for applying this mechanism securely is that the
certificate validity period is shorter than the time needed to detect,
report and distribute revocation information.  If the certificate validity
period is not adequately short, it creates a window of opportunity for
attackers to exploit a compromised private key.  Therefore, it is crucial
to carefully assess and set an appropriate certificate validity period
before implementing the noRevAvail certificate extension.</t>
      <t>When the noRevAvail certificate extension is included in a certificate,
all revocation checking is bypassed, even if the CRL Distribution Points,
Freshest CRL, or Authority Information Access (pointing to an OCSP Responder)
certificate extensions are present.  CA policies and practices <bcp14>MUST</bcp14> ensure
that the noRevAvail is included only when appropriate, as any misuse or
misconfiguration could result in a relying party continuing to trust
a revoked certificate.</t>
      <t>Some applications may have dependencies on revocation information or assume
its availability. The absence of revocation information may require
modifications or alternative configuration settings to
ensure proper application security and functionality.</t>
      <t>Since the absence of revocation information may limit the ability to detect
compromised or malicious certificates, relying parties need confidence that
the CA is following security practices, implementing certificate issuance
policies, and properly using operational controls. Relying parties may
evaluate CA reliability, monitoring CA performance, and observe CA incident
response capabilities.</t>
    </section>
    <section anchor="iana">
      <name>IANA Considerations</name>
      <t>For the ASN.1 Module in <xref target="asn1-mod"/>, IANA is requested to assign an
object identifier (OID) for the module identifier. The OID for the module
should be allocated in the "SMI Security for PKIX Module Identifier"
registry (1.3.6.1.5.5.7.0).</t>
    </section>
    <section anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>Many thanks to Erik Anderson for his efforts to make the noRevAvail
certificate extension available for use with public key certificates as
well as attribute certificates.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC5280">
          <front>
            <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
            <author fullname="D. Cooper" initials="D." surname="Cooper"/>
            <author fullname="S. Santesson" initials="S." surname="Santesson"/>
            <author fullname="S. Farrell" initials="S." surname="Farrell"/>
            <author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <author fullname="W. Polk" initials="W." surname="Polk"/>
            <date month="May" year="2008"/>
            <abstract>
              <t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5280"/>
          <seriesInfo name="DOI" value="10.17487/RFC5280"/>
        </reference>
        <reference anchor="X.509-2019-TC2" target="https://www.itu.int/rec/T-REC-X.509-201910-I">
          <front>
            <title>Information Technology -- Open Systems Interconnection -- The Directory: Public-key and attribute certificate frameworks -- Technical Corrigendum 2</title>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date year="2023" month="October"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="X.509-2019/COR.2-2023"/>
        </reference>
        <reference anchor="X.680" target="https://www.itu.int/rec/T-REC-X.680">
          <front>
            <title>Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation</title>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date year="2021" month="February"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="X.680"/>
          <seriesInfo name="ISO/IEC" value="8824-1:2021"/>
        </reference>
        <reference anchor="X.690" target="https://www.itu.int/rec/T-REC-X.690">
          <front>
            <title>Information technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date year="2021" month="February"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="X.690"/>
          <seriesInfo name="ISO/IEC" value="8825-1-2021"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC2459">
          <front>
            <title>Internet X.509 Public Key Infrastructure Certificate and CRL Profile</title>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <author fullname="W. Ford" initials="W." surname="Ford"/>
            <author fullname="W. Polk" initials="W." surname="Polk"/>
            <author fullname="D. Solo" initials="D." surname="Solo"/>
            <date month="January" year="1999"/>
            <abstract>
              <t>This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use in the Internet. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2459"/>
          <seriesInfo name="DOI" value="10.17487/RFC2459"/>
        </reference>
        <reference anchor="RFC3281">
          <front>
            <title>An Internet Attribute Certificate Profile for Authorization</title>
            <author fullname="S. Farrell" initials="S." surname="Farrell"/>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <date month="April" year="2002"/>
            <abstract>
              <t>This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPSec, and WWW security applications. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3281"/>
          <seriesInfo name="DOI" value="10.17487/RFC3281"/>
        </reference>
        <reference anchor="RFC5912">
          <front>
            <title>New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <date month="June" year="2010"/>
            <abstract>
              <t>The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5912"/>
          <seriesInfo name="DOI" value="10.17487/RFC5912"/>
        </reference>
        <reference anchor="RFC6268">
          <front>
            <title>Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad"/>
            <author fullname="S. Turner" initials="S." surname="Turner"/>
            <date month="July" year="2011"/>
            <abstract>
              <t>The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates some auxiliary ASN.1 modules to conform to the 2008 version of ASN.1; the 1988 ASN.1 modules remain the normative version. There are no bits- on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6268"/>
          <seriesInfo name="DOI" value="10.17487/RFC6268"/>
        </reference>
        <reference anchor="RFC8555">
          <front>
            <title>Automatic Certificate Management Environment (ACME)</title>
            <author fullname="R. Barnes" initials="R." surname="Barnes"/>
            <author fullname="J. Hoffman-Andrews" initials="J." surname="Hoffman-Andrews"/>
            <author fullname="D. McCarney" initials="D." surname="McCarney"/>
            <author fullname="J. Kasten" initials="J." surname="Kasten"/>
            <date month="March" year="2019"/>
            <abstract>
              <t>Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8555"/>
          <seriesInfo name="DOI" value="10.17487/RFC8555"/>
        </reference>
        <reference anchor="X.509-1988" target="https://www.itu.int/rec/T-REC-X.509-198811-S">
          <front>
            <title>Series X: Data Communication Networks: Directory -- The Directory -- Authentication Framework</title>
            <author>
              <organization>CCITT</organization>
            </author>
            <date year="1988" month="November"/>
          </front>
          <seriesInfo name="CCITT Recommendation" value="X.509-1988"/>
        </reference>
        <reference anchor="X.509-1997" target="https://www.itu.int/rec/T-REC-X.509-199708-S">
          <front>
            <title>Information Technology -- Open Systems Interconnection -- The Directory: Authentication framework</title>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date year="1997" month="August"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="X.509-1997"/>
        </reference>
        <reference anchor="X.509-2000" target="https://www.itu.int/rec/T-REC-X.509-200003-S">
          <front>
            <title>Information Technology -- Open Systems Interconnection -- The Directory: Public-key and attribute certificate frameworks</title>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date year="2000" month="March"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="X.509-2000"/>
        </reference>
        <reference anchor="X.509-2019" target="https://www.itu.int/rec/T-REC-X.509-201910-I">
          <front>
            <title>Information Technology -- Open Systems Interconnection -- The Directory: Public-key and attribute certificate frameworks</title>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date year="2019" month="October"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="X.509-2019"/>
        </reference>
      </references>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIADpYIGUAA91a7XLbuBX9j6dAkx+RW1GR5Di2tLvZVWR5o13bSiVlN5lO
pwORkI01RagEKcf1OM/SZ+mT9VyApEhZip3stDOtkxnzA7i49+B+nAva8zxm
EhEFfxOhjmSXJ3EqmVrG9sok7Waz02yzQPuRWOB1EIt54l3q1ITyxgvFYmm8
SMdyJVZChV6zxXyRdLlJAubryMjIpKbLn5HUZ2ypuozzRPt4ciPNM9wYHSex
nJvSk5tF+UGikhDrPjvXfCxXGtKVjniPVhOzUPK5jvnkElK8UK1kwN83Dpod
/jadhcrnP8sb3pdxouYKE0mcmM2gbJefa0izUu5JKE9gJp0tlDFYc3qzhB7D
wfSEiViKLp9IP41VcsOurvE8SmQcycQ7JoBYgMld3m62971W02u+ZEykCdbo
Mo87IMepMfyNwxFW6/iiy39RF9Anl1vnp6d9vMpVrr7FCx+/uvwN1g10VOe/
9OiZTqMkxuN3E9zJBQzs8my7fliRBCP9hq8XhSJTvdDzdKH46Cqd6VyVYwwl
IOqwzG+UtMhfFOufCBXPxcfPrZ9kSzQ0LfEnJZP5Dxf0qqLIT9rI5SU/gzPK
MNfDmit/3NQie1woMRWQJOr81w0demslftOysbCyfzB29kVDacZUhP1fwKtW
kpxzfNJvvzjoZJf77aNWdnnQabWzy5ftl0fZ5dHBwQFdWq/zWp0j+wI+LuIL
iTi4TJKl6T5/fn193VBJ2lBR8jyW/vOpNx70vfWsVsubuInO3V/ZGw47YyUN
fw/cRSJ4Xy8WaaSyIDiXybWOrwxtCoQmOr7hCGc3c3opK495Dw4ooySffBID
dJpux+feSdeeQ77fH06n9oFzZlLTa7XsE2PVIui62XJ2NCIU27CQUWDX6JZg
KWHUOfwajDqHzaPtGA3zHYRVU+lfRjrUFyUkRksZ8cmNSeTCuDhFZooADE3Y
jld3E635Q2gNp++8KlqdQ695tAMtO3onWp3DAi2k3+aXo0Wzmvv/RbRcuvWu
kG4RYVwkSaxmaSK5v86lawzNY0EkO7zm/leASDNLILY6XwNiq4PcPfzfB7EF
p2p+FYitDmPRRno8aB81uxVsvWm//f+Hb0kOaYDXIfJvHKsL4JQuePvxG2BZ
wFduwPP+aNxoeyTEgv7y6AsTAiY8BHGyBeLezCSx8BPAHCXiIwhT4gaPIslr
vcl5o7WX2zBZSt8BSAP0nM+EAfuKsilfAFTLa7a/EKjcPoyYjJ4PB/0uPzpq
v/BaXZLnMOt8KWadr8OMUOEy8nWgogsep6FEcb6HzmuLziAfNqZhvPZ6MN6r
59VURNp53OaoPkZZ9z1WJsHzVJlLcNbNYccY9h+GvbMN9gOv5VnYmQfKITIf
YuweQ1/t86Xj6BSPpQg0XBi+jPVchRirIko5nHIOB+tmRkqy8gIEHEHPUyNp
CEp1QcAbNuzXHN52CxYEEEXg19vDcJEwkPoUi2EqZJiSehVdAk1e7FQ1lzxe
dyBq7QtsJn1BqpAe5WQSqrk0SxHZFbkybh3ojXundaIWkkdSBlg40SyQcCtw
7lguNXFv2ugAG50lqu3LNyjTkfCyn0HUXEXOQJhQNDtl9eTHBP0ZSTPaqSiw
RHhDCC9FDLh8ETFAHajwhpNu8QIy3VCS2+8BIKzxMETUZLENeBrOSRYqCELJ
2FPawlgHqcvit08V3d4x9pC/3N5mVenujl+r5NKhzFciVAHt+RI+rQPzaP/h
J2gI5Ue0tqGsk+9ossEv94UMTYq4kAiIBKG3UrGO7HWt1z8b7DmNqDWARnDl
lQrIrTkFg7q4TIDFtYgDfi1uWKK5niUCSuzywQblHY7OhbbDSFMH3CWUWRll
eMFCBJKLSnu807tnN2Q6+1yw5M6F/7mX7xLHLsUKS28C/1jn5xvOzx7r/D1j
/dakoZ280le0xSUtWcVoaJISV5DGiNhRgaWGryFvmq2hxEuhxH5PKPEslNjv
DiWrSjWUnj4FTyGhribdPqUlDMKH0iHFDEgNguDJ2bvJ9End/ebnI3s9Hvz5
3XA8OKbryZve6WlxwbIRkzejd6fH66v1zP7o7Gxwfuwm4ymvPGJPznofnrhE
9mT0djocnfdOn7iYU5Re/dQGDmKTXGBG4QjFlzEQAkUzgMr4cABXCl733/7r
n60XiK8/UJ/eanUQYO7mqHX4guIfTZtbTUfIWe4WYN0wsVxKEZMUEWLvxFIl
IkQwCeuY1xG/lDHh+Me/EDJ/7fJvZ/6y9eJV9oAMrjzMMas8tJjdf3JvsgNx
y6MtyxRoVp5vIF3Vt/ehcp/jXnr47fchuZ/XOvr+FbPOY7lLlmw36jH2BpxX
xoL2JDXk047p3N5a+nV3V88ekydbdsO2sRu7L4kl5Q9xFye6A9HOtd9gBkg8
Y0iFdJxQzw4cXGg6qa5OtCpxSWLyIwgry87vHNYzXnN//n5lfq5x0Syw7dI7
hyXpnbqrKIPpCZ+r2CRrPrNrHYrpdTFieTFylYQOpHLx1NhuU/7BvJSvQBWS
be19TGEPLVJasP15e3Y0Up+ziM7VyGscvKogfBjthynVA5MuqQoUye4h+3Jl
W50cnSyLUhqJeLokrkspZhufdVvC1ua3HN6/EpsocwWQ953FdINHOMzQVCC9
se0d5Ge14WVtqMNGdkPm0teGPWq/XTaF0oEjRTvYE0P+u5bIiPi93SsoAC2n
Li1ZokJ8kC/pSk1pVKFMvXBVgHTfrnpmGG0U6iA0V1HghFuqXuE7lVJ4raA5
zNxCeqxbVUukLe1rhPK0TgJQcAzVIWU12IEVRPS1XZ2yVR+8w4rIfNatuBYP
URX/IKWuL5V/CYjYA/YUvgtC8itqWK5fnfsVBZhVYCHiq83VBVGJyEPtpDPM
EKq/Yp8+fWJ01M7XPyrwfOmt94yNhsel1/zWjeAHL/kdM+4kIP85f4fKVlMN
2eDPmgfN5rM3xK1sfh+Miy54j+U6ECXEj1UZNp70TicDqxPrbXAly4oKOpRG
gYztN6pNIxfEpkmW3XX0T3AyhHslIkpIA1JQ9P74dI/PY73IeFedw+Xd9fjU
7gCL5ErGxb7CKyV9T8hzUUU89oPYuyt+ZeVs2IwwPM7ieWvMGFZi35ZiElcu
HGp7OK09NxvJtqaATJoltxRUZQVKn9JOC1QYMW+jUGjpmwOMzXoXHmZjDSXA
UWSpQ1naJBFJavjbWCfa1yGrjfqTt3tYxCy13TzqYea77bEFoAhAUTbHptGo
C15mc1DZ0AIF8DhdAY028jjvHGiBt4SB2Z4pv+FoCumDkh35otFutBqtfbK0
1Fg2vkyBE1hzKYErafL4VQ92rbruycpHUD2fmpjt8utczddZY9NhyKcR2CLw
tG+WXFhBZxKLBPcVg2r39coIIz9Dw47Yu30qTNTyFjq4y/KsySSs+98om7LI
puTksYirUhraYRPlAEWkwNULG4w6WtGHGvJOIC6yxMlspcm+21HpxEx7Tx/v
rAXIPJ+QJqMGnRGuPwcjNN2BJVKf0bXWHoAi+XMlgVZ8ISL1Dwt/bX8POSqo
vdxzPQtqPkZnZ2Im+0pbO9jjCxR/zDILQ3fLK/WxdkhSCa1aM5/h7kupuDZ9
fbyHrIv3x4OT4fmQSPyED8/eng7Bffm09+OEd7vf4f3rwY/DcxqIl6Px1H33
GbyfDs4nmGPvTsajM/725+F7j74huq/Zhoheh9PHQXvIBqRYkfa/3vavsb6w
nwY4Db1mu3aAoXf8GzINSj5MQDg5SwnDNQiEFL+1q00+nE977235svfD48H5
dHgyHBzz1x/uV0R7HjsG+v3e6XD6AdjYygW97h6pF0dRpaGulI5e/zToT9er
jp1q/DfKUR5w93xfJUmtDYgtZu2OW2lTs52SSiWbYx4aROvs7LbLjU5jH2wz
kB6xBqTm79zfZtxRSOd/WwCWCsUD6vhsXN0+xY569Pcc2XnCroFF0LnTOOoc
UdnlSkRJw81ESoKcQBUnGejLXem35bPwFudDYAWOU7hTkkpa2DxmevwJE3Mn
TI8+Xc1K17bF2XpxoiqgoX9P8R5qW13qlK1820DQIdU16Im+pmSqbXeTRqQ/
HY2CeguftoPUlB+XoVZ0hIS2APlzoYjFL2O1oqXBSu0xlYwlZkq7BFHdOPWV
COlA0Qfu8zSEEsIYqhBkqJFkMMEda4gSyXaDMjTZzArnig5B6YQm7+4f0YdZ
wvqoHoXOFfOGjwp/eVid0TlNaU/8S+nbkz06irxZkmlBnYOpRVTqPlP266xc
jutEbD5bT2uWMVmDNUFGZGbNZfZ2kS1y9qzgYn+oi9BoIpR08C/pO4iCfFeL
6e+iYsmK478SVGVQikOs8r7ZMys6DoZf2KY0ZriixkBdpHEGlk7DIDsUddBu
nEZqsjDNjLR/6cWEOzyt9rUNzthEI4ooTlVOAxfihtvT3kAu0baC61vGGO3q
0yjOjUkXkinQsKxRU9QRuM81YgbYfNtf75BAK8YILgXUUCeKw1nLU0VINch+
pOZVHOD1tJMUVsxhToQEPl62p6hXdqfmaWSZi21Y4M4TRZolj9YyVAuVZOOt
ievMw8rxDL0XgjxEpxUOZ+qVvSJgKYM5wwLplEFXnJ0aK5PRIXvonRtSuFu9
GsJl36UvYALiWO6o9cxTCR/4nTvSoxvh8LBeE+sQdH68oSEMZ0jzISU/0goW
qMz8OghfZJsK27NSgrGAYeXspBawxitnDByJGAcyNIUbnNsXSydHZScRw955
7359UiISqE0nGZOscFNblAp6eld3IoAb+ROygqsN8E91gUCJmJ79hr1aU5+Y
11DA9wqamvHX9Xvnw9Q5V4cw1AAKQ2pQQ9tDuTxHI55MzobrMkrziJzlKg8L
2U8AxQXltBteazX2Gy/RJxzg32GjuedouH8V6etQBu5zFBrKM8oNVAKvbDUZ
xOqK92wblpVc26fOcZXYAQtxtdlrbs9xGycs+WniZz7ksgePlugL4Aylj/0b
Hx/gF4kqAAA=

-->

</rfc>
