<?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-rfc2629 version 1.5.26 (Ruby 2.3.7) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-housley-lamps-norevavail-00" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.17.1 -->
  <front>
    <title abbrev="NoRevAvail for Short-lived X.509 Certificates">No Revocation Available for Short-lived X.509 Certificates</title>
    <seriesInfo name="Internet-Draft" value="draft-housley-lamps-norevavail-00"/>
    <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="May" day="18"/>
    <area>Security</area>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <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>
    <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>
      </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>With greater use of short-lived certificates in the Internet, the next
revision of ITU-T Recommendation X.509 <xref target="X.509-TBD"/> is expected to 
allow 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-TBD"/>, allows an CA to indicate that
no revocation information will be made available for this certificate.</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>The certificate <bcp14>MUST NOT</bcp14> also include the CRL Distribution Points certificate extension; see Section 4.2.1.13 of <xref target="RFC5280"/>.</li>
        <li>The certificate <bcp14>MUST NOT</bcp14> also include the Freshest CRL certificate extension; see Section 4.2.1.15 of <xref target="RFC5280"/>.</li>
        <li>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"/>.</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's validity period is sufficiently short to enable the
timely detection, reporting, and distribution of 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>
        <name>Normative References</name>
        <reference anchor="RFC5280" target="https://www.rfc-editor.org/info/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">
              <organization/>
            </author>
            <author fullname="S. Santesson" initials="S." surname="Santesson">
              <organization/>
            </author>
            <author fullname="S. Farrell" initials="S." surname="Farrell">
              <organization/>
            </author>
            <author fullname="S. Boeyen" initials="S." surname="Boeyen">
              <organization/>
            </author>
            <author fullname="R. Housley" initials="R." surname="Housley">
              <organization/>
            </author>
            <author fullname="W. Polk" initials="W." surname="Polk">
              <organization/>
            </author>
            <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-TBD" 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 -- (Replace with the next revision when it is published)</title>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date year="2019" month="October"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="X.509"/>
        </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" target="https://www.rfc-editor.org/info/rfc2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner">
              <organization/>
            </author>
            <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" target="https://www.rfc-editor.org/info/rfc8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/>
            </author>
            <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>
        <name>Informative References</name>
        <reference anchor="RFC2459" target="https://www.rfc-editor.org/info/rfc2459">
          <front>
            <title>Internet X.509 Public Key Infrastructure Certificate and CRL Profile</title>
            <author fullname="R. Housley" initials="R." surname="Housley">
              <organization/>
            </author>
            <author fullname="W. Ford" initials="W." surname="Ford">
              <organization/>
            </author>
            <author fullname="W. Polk" initials="W." surname="Polk">
              <organization/>
            </author>
            <author fullname="D. Solo" initials="D." surname="Solo">
              <organization/>
            </author>
            <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" target="https://www.rfc-editor.org/info/rfc3281">
          <front>
            <title>An Internet Attribute Certificate Profile for Authorization</title>
            <author fullname="S. Farrell" initials="S." surname="Farrell">
              <organization/>
            </author>
            <author fullname="R. Housley" initials="R." surname="Housley">
              <organization/>
            </author>
            <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" target="https://www.rfc-editor.org/info/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">
              <organization/>
            </author>
            <author fullname="J. Schaad" initials="J." surname="Schaad">
              <organization/>
            </author>
            <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" target="https://www.rfc-editor.org/info/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">
              <organization/>
            </author>
            <author fullname="S. Turner" initials="S." surname="Turner">
              <organization/>
            </author>
            <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" target="https://www.rfc-editor.org/info/rfc8555">
          <front>
            <title>Automatic Certificate Management Environment (ACME)</title>
            <author fullname="R. Barnes" initials="R." surname="Barnes">
              <organization/>
            </author>
            <author fullname="J. Hoffman-Andrews" initials="J." surname="Hoffman-Andrews">
              <organization/>
            </author>
            <author fullname="D. McCarney" initials="D." surname="McCarney">
              <organization/>
            </author>
            <author fullname="J. Kasten" initials="J." surname="Kasten">
              <organization/>
            </author>
            <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>
      </references>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAGiJZmQAA81a7XLbuBX9j6dAnR+RW1GR7Di2tO3OKrK80da2XEnZTabT
6UAkZGNNESpBSnE9zrP0WfpkPRcgKVKWYic77dTJjPkBXNx7cD/OBe15HjOJ
iIK/i1BHssOTOJVMLWJ7ZZKDZrPdPGCB9iMxx+sgFrPEu9GpCeWdF4r5wniR
juVSLIUKvWaT+SLpcJMEzNeRkZFJTYe/JKkv2UJ1GOeJ9vHkTpqXuDE6TmI5
M6Und/Pyg0QlIdZ9ean5SC41pCsd8S6tJqah5DMd8/ENpHihWsqAf2gcNdu8
J+NEzRRGkwwxnULDDr/UEGGnPmMaM+l0rozBcpO7BVQY9CdnTMRSdPhY+mms
kjt2u8LzKJFxJBPvlLBhASZ3+EHz4NBrHnmtE8ZEmmClDvO4w3CUGsPfOQhh
sI6vO/xndQ2tcrl1fn7ew6tc8epbvPDxq8PfYd1AR3X+c5ee6TRKYjx+P8ad
nMPMDs926oclSTDSb/h6Xigy0XM9S+eKD2/Tqc5VOcVQAqIOy/xGSYv8RbH+
mVDxTHz60vpJtkRD0xJ/UDKZ/XBNryqK/KSNXNzwC/ihDHM9rLnyx00tsseF
EhMBSaLOf9nQobtW4lctG3Mr+wdjZ183lGZMRfCCORxqKckvR2e9g9dH7ezy
8OCklV0etVsH2eWbgzcn2eXJ0dERXVrP8VrtE/sC7i3ia4kQuEmShem8erVa
rRoqSRsqSl7F0n818Ub9nree1Wp5YzfRefr39obDzlhJwz8Ad5EI3tPzeRqp
zP8vZbLS8a2hTYHQRMd3HJHsZk5uZOUx78IBZZTkk89igE7T7fjcO+nac8j3
eoPJxD5wzkxqeq2WfWKsWgRdJ1vOjkZwYhvmMgrsGp0SLCWM2sffglH7uHmy
HaNBvoOwaiL9m0iH+rqExHAhIz6+M4mcGxenSEoRgKEJ2/HqbKI1ewqtweS9
V0Wrfew1T3agZUfvRKt9XKCFzNv8erRoVvPwf4jWVToNle/dyjuOCOMiSWI1
TRPJ/XUuXWNongsi2eE1D78BRJrJWLQR2UcHJ811tE7enn4LtK12q+kN/l+h
XcupjeQiFL7kK5XccHgzj+SnhCN9KipnfAX/5irhyvAFrWFuZLD//J1pwVOb
X78zFv03J1/p1JjwFODJFsC7U5PEwk8AepSITyj9iRs8jCSvdceXjdZ+rvN4
IX0HJw3QMz4VRvk8yqY8H5iDlgeu9HXA5PZhxHj4atDvdfjJycFrr9UheQ6z
9tdi1v42zAgVLiNfByq65nEaShSYR+i8tej082EjGsZrb/uj/XpeEUSkqVSF
j0b1MMo686kyCZ6n1vceDTvFsP8y7O1tsIOveRZ25qFsisyHGHvEFJeHLnJ8
TtFZikfDBYIq1jMVYqyKKPdwSj4czJEZKcnKa5BIpACeGklDKEBzEtmwSWDN
Qy3ZtSCA7AC/7j6Gi4SBmKZYDFMhw5TUq+gSaPLiPMgpAeQEWq19gU2lL0gV
0qOcWkI1k2YhIrsiJQu7DvTGvdM6UXPKLTLAwolmgYRbgTfGcqGJP9JGB9jo
LG1tX75BeY+El/0MomYqcgbChIK2l9VDSkN7QdKMdioKLBHeEcILEQMuX0QM
UAcqvOOkWzyHTDeU5Pa6AAhrPA0RtQtsA56Gc5K5CoJQMvaCtjDWQepy+v0L
RbcPjD3lL/f3WXl6eHD52qLMlyJUAe35Aj6tA/Ns/+FnaG3kJ3RmoayT72iy
wS/3NgxEW1xLBESC0FuqWEf2utbtXfT3nUZEb6ERXHmpAnJrTsGgrm8SYLES
ccBX4o4lmutpIqDELh9sUN7hYN+0HUaaOuAuoczKKMML5iKQXFS6u53ePb0j
09mXgiV3LvzPvXyXOHYjllh6E/jnOj/fcH72XOfvGuu3Jg3t5KW+pS0uackq
RkOTlJiDNEbEjhgsNHwNedNsDSVeCiX2W0KJZ6HEfnMoWVWqofTiBXgTCXU1
6f4FLWEQPpQOKWZAcRAEexfvx5O9uvvNL4f2etT/y/vBqH9K1+N33fPz4oJl
I8bvhu/PT9dX65m94cVF//LUTcZTXnnE9i66H/dcItsbXk0Gw8vu+Z6LOUXp
1U9t4CA2yQWmFI5QfBEDIRA2A6iMDwdwpeBt7+rf/2q9Rnz9jnrNVquNAHM3
J63j1xT/IGZuNR0hZ7lbgHXHxGIhRUxSRIi9EwuViBDBJKxjriJ+I2PC8fd/
JWT+1uF/nPqL1uvvswdkcOVhjlnlocXs8ZNHkx2IWx5tWaZAs/J8A+mqvt2P
lfsc99JD6y+WrmT5daMEYzuuZSRjQduQGnJjR27u7y3jenioZ4/JeS2hYdsI
jd2KxLLyp+iKE92GaOfN7zADLJ4xZD/qgutZn+yi0Ul1paFVCUUSk3fOVpad
3z6uZ1Tm8fzDyvxc46JbYNult49L0tt1V0T6kzM+U7FJ1hRm1zoUxuv6w/L6
44oHnaPk4qkf26b8k6koX4GKItva/JjCHlqktODBl+3Z0Ul9ySI6DiKvcfCq
guNhtB+mVAJMuqDEX+S3p+yDsr9QuS8Xc7DrndVuo9DXi76OFX0dpm/ju9nh
Zo4Vml+kGpggP6FOJK56MaQVvXrexrhMB30DR1jWzIZtMuGVRLbC7+3bR5Fi
+W5pyRJN4f18SVcGSqMKZeqFTwGfioV1bk3C2hGVJyitosDJtQy6QkMqFWql
oDQs3MJF7NZXK1dP26mUDnqo5TbbZk7hhq+Bg4oVgEji6kb5NzCNPaFM0aij
yP9C/TuKjEHtqXO/ogCzCsxFfLu5uqDyHHmoR3S2FUL179nnz58ZHcHy9Y8K
PF96a6zZcHBaes3v3Qh+9IY/MOO66/zn8j2qRU01ZIO/bB41my/fkZ/ZBNof
FZ3lPst1IJqFH6sybDzrno/7VifW3eAflmkUFCONAhnbzxabRs6JoZIsu2Xo
SeAcqMQVTy4hDUhBe3uj830+i/U84zJ1Dld116NzuwMskksZF/sKl5J0zpwH
e0U89oMYsasuZeWsuw8xPH78uWHt64aVGK2lbcQ/C4faHgY8L/L5SLY1dDNp
ljBSRJQVKH1dOS9QYcRmjUIlo7NoGJv1AzzMxhpKOsMoJDZYljZORJIafhXr
RPs6ZLVhb3y1j0XMQtvNo75gttsem2Gtg1vOUzbHZr6oA65jc0fZ0AIFcCNd
AY028jRn47TAFWFgtme47zgaLfrQYEe+bhw0Wo3WIVlaatYaX6fAGaxBs55Y
TZ6/6tGuVdd9TvlYp+tTY7Bdfp2r2TprbDoM+TQCWwSe9s2CCyvoQmKR4LFi
UO2xXhkj4xdoghF79y+EiVreXAeWxVNbkklY95RRNmWeTcnZWRFXpTS0wybK
AYqqrkv2Nhh1tKQDfPJOIC6yxMlshci+52ANmmnv6aOOtQCZ5zPSZNSgc7f1
x0KEpjsEROozutbaB1Akf6Yk0IqvRaT+aeGvHe4jRwW1N/uuD0CZxujsnMlk
X+9qR/t8Ln10kcrMDd0tbtWn2jFJJbRqzXyGuy+l4hoK2z6yLt6f9s8GlwMi
xmM+uLg6H4Bc8kn3xzHvdP6E92/7Pw4uaSBeDkcT9z2g/2HSvxxjjr07Gw0v
+NWfBx88+rbkvnIaYlJtTh+N7MEVkGJF2v9227/F+sJ+GuA09JoHtSMMfeDf
kWlQ8mniwMlZShiuQSCk+L1dbfzxctL9YMuXvR+c9i8ng7NB/5S//fi4Itoz
zhHQ73XPB5OPwMZWLuj18Ey9OIoqDXWldPj2p35vsl515FTjv1KO8oC75/sq
SWoHgNhidtB2K21qtlNSqWRzzEPTZZ2d3XfQ8aexD74YSI9YA1Lzn9zn+gcK
6fybMwfNMdj6OMv69y+wox594s969F0Di6BzJ1zUmqGyy6WIkoabiZQEOYEq
TgfQ67rSb8tn4S3Oh8AKHKdwJw/ltPDSPDq8oayTzvBawWkx052tofLJyBEE
SKBznOyA0Oan/AgHGmwcYWYce8dRDsvqWTlRbdGH+AuI5T9SvM81qlMK820j
gKzIVuAsIONYStueIo1IhIUmSYRPe2Rt+LQItaKzGrB9JNW5Ikq+iNWSlgYd
bxC+scREWc++9/hx6isR0nQfezFLQ+ggjKGqQbYaNDxIy9iCWEOS2OgfN+2Z
WuFc0WEjnYTkLfX2HoJVmh8isc/qN+j8Lu+yiAyUh9WpcSnviH8jfXuCRkd+
dwsyLahzsLeIyt8XqECdlUt0ncjOF2tszbIoa7AmyIjgrPnN/i4CRgGQFWFQ
IDQmCx2Sezr4F/S9QUG+q8/05zMxPDQ/ZitBVQalOCwq75s9G6JjV7iF7S1j
hitqFtR1Gmdg6TQMssNHB+3GqZ8mC9PMSPsHQUy4Q8pqe9rgjI01+giKXZVT
w7m44/ZUNZALNKPg/5ZFRrsaL3JwY9K5ZArULOu8FHUJ7rOImAI2X+6OQbti
jNhSQA21ozgEtdxVhFSX7FdhXsUBXk87SVHFHOZEUuDjZXuKGmZ3apZGNlvY
JgbuPFakWfJsLUM1V0k23pq4PkNm5XCG3nNBHqLTCq8z9cpeEbB0Fu0MC6RT
Bm1udjqrTEaR7OFybkjhbvVqCJd9l740CYhjuaPWM08lfOB37hyNboTDw3pN
rENQ/NGGhjCcIfWHlPtIK1igMvPrIIGRbTRsH0sJxgKGlbMTUcAaL50xcCRi
IehOKNzg3L5YODkqO1UYdC+7j2uWEpFAvTrL2GWFr9pCVVDWh7oTAdzIn5AV
3DkJ/FNdI1Aipqe/Yq/WdCjmNRT1/YK6Zpx2/d75MHXT1SEMJYDCkJrW0PZV
Ls/RiL3xxWBdWmkeEbZc5UEhew9QXFNOu+O1VuOw8Qa9wxH+HTea+46a+7eR
XoUycJ990GReUG6gjxm3tpj0Y3XLu7Y1y8qw7V1nuErsgLm43ew/t+e4jSOT
/AjvCx9M2ZPHRPSlbYrKx/4DputsIbAoAAA=

-->

</rfc>
