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

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

<?rfc rfcedstyle="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc text-list-symbols="o-*+"?>
<?rfc compact="yes"?>
<?rfc subcompact="yes"?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-acme-star-11" category="std"> number="8739" category="std" obsoletes="" updates="" submissionType="IETF" consensus="true" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">

  <front>
    <title abbrev="ACME abbrev="Support for ACME STAR">Support for Short-Term, Automatically-Renewed
    Automatically Renewed (STAR) Certificates in the Automated Certificate
    Management Environment (ACME)</title>
    <seriesInfo name="RFC" value="8739"/>
    <author initials="Y." surname="Sheffer" fullname="Yaron Sheffer">
      <organization>Intuit</organization>
      <address>
        <email>yaronf.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="D." surname="Lopez" fullname="Diego Lopez">
      <organization>Telefonica I+D</organization>
      <address>
        <email>diego.r.lopez@telefonica.com</email>
      </address>
    </author>
    <author initials="O." surname="Gonzalez de Dios" fullname="Oscar Gonzalez de Dios">
      <organization>Telefonica I+D</organization>
      <address>
        <email>oscar.gonzalezdedios@telefonica.com</email>
      </address>
    </author>
    <author initials="A." surname="Pastor Perales" fullname="Antonio Agustin Pastor Perales">
      <organization>Telefonica I+D</organization>
      <address>
        <email>antonio.pastorperales@telefonica.com</email>
      </address>
    </author>
    <author initials="T." surname="Fossati" fullname="Thomas Fossati">
      <organization>ARM</organization>
      <address>
        <email>thomas.fossati@arm.com</email>
      </address>
    </author>
    <date year="2019" month="October" day="24"/> month="March" year="2020" />
    <area>Security</area>
    <workgroup>ACME Working Group</workgroup>
    <keyword>Internet-Draft</keyword>

<keyword>OCSP</keyword>
<keyword>CRL</keyword>
<keyword>revocation</keyword>

    <abstract>

<t>Public-key
      <t>Public key certificates need to be revoked when they are compromised,
      that is, when the associated private key is exposed to an unauthorized
      entity.
However  However, the revocation process is often unreliable. An
      alternative to revocation is issuing a sequence of certificates, each
      with a short validity period, and terminating this the sequence upon
      compromise.  This memo proposes an ACME Automated Certificate Management
      Environment (ACME) extension to enable the issuance of short-term and automatically renewed Short-Term,
      Automatically Renewed (STAR) X.509 certificates.</t>

<t>[RFC Editor: please remove before publication]</t>

<t>While the draft is being developed, the editor’s version can be found at
https://github.com/yaronf/I-D/tree/master/STAR.</t>
    </abstract>
  </front>
  <middle>

    <section anchor="introduction" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>The ACME protocol <xref target="RFC8555"/> target="RFC8555" format="default"/> automates
      the process of issuing a certificate to a named entity (an Identifier
      Owner or IdO). Typically, but not always, the identifier is a domain
      name.</t>
      <t>If the IdO wishes to obtain a string of short-term certificates
      originating from the same private key (see <xref target="Topalovic"/> target="TOPALOVIC"
      format="default"/> about why using short-lived certificates might be
      preferable to explicit revocation), she must go through the whole ACME
      protocol each time a new short-term certificate is needed – needed, e.g., every
      2-3 days.  If done this way, the process would involve frequent
      interactions between the registration function of the ACME Certification
      Authority (CA) and the identity provider infrastructure (e.g.: (e.g., DNS, web
      servers), therefore making the issuance of short-term certificates
      exceedingly dependent on the reliability of both.</t>
      <t>This document presents an extension of the ACME protocol that
      optimizes this process by making short-term certificates first class first-class
      objects in the ACME ecosystem.  Once the Order for a string of
      short-term certificates is accepted, the CA is responsible for
      publishing the next certificate at an agreed upon URL before the
      previous one expires.  The IdO can terminate the automatic renewal
      before the negotiated deadline, deadline if needed – needed, e.g., on key compromise.</t>
      <t>For a more generic treatment of STAR certificates, readers are referred to <xref target="I-D.nir-saag-star"/>.</t> target="I-D.nir-saag-star" format="default"/>.</t>
      <section anchor="name-delegation-use-case" title="Name numbered="true" toc="default">
        <name>Name Delegation Use Case"> Case</name>

        <t>The proposed mechanism can be used as a building block of an
        efficient name-delegation protocol, for example example, one that exists between a CDN
        Content Distribution Network (CDN) or a cloud provider and its
        customers <xref target="I-D.ietf-acme-star-delegation"/>. target="I-D.ietf-acme-star-delegation"
        format="default"/>.  At any time, the service customer (i.e., the IdO)
        can terminate the delegation by simply instructing the CA to stop the
        automatic renewal and letting the currently active certificate expire
        shortly thereafter.</t>
        <t>Note that in the name delegation use case case, the delegated entity needs to access
the auto-renewed certificate without being in possession of the ACME account
key that was used for initiating the STAR issuance.  This leads to the optional
use of unauthenticated GET in this protocol (<xref target="certificate-get-nego"/>).</t> target="certificate-get-nego" format="default"/>).</t>
      </section>
      <section anchor="terminology" title="Terminology">

<t><list style="hanging">
  <t hangText='IdO'> numbered="true" toc="default">
        <name>Terminology</name>
        <dl newline="false" spacing="compact" indent="8">
          <dt>IdO</dt>
          <dd>
  Identifier Owner, the owner of an identifier, e.g.: e.g., a domain name, a
	  telephone number.</t>
  <t hangText='STAR'>
  Short-Term and number, etc.</dd>
          <dt>STAR</dt>
          <dd>
  Short-Term, Automatically Renewed X.509 certificates.</t>
</list></t> certificates.</dd>
        </dl>
      </section>
      <section anchor="conventions-used-in-this-document" title="Conventions used numbered="true" toc="default">
        <name>Conventions Used in this document">

<t>The This Document</name>

        <t>
    The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL
NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”,
“MAY”, "<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 “OPTIONAL” "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>

      </section>
    </section>
    <section anchor="protocol-flow" title="Protocol Flow"> numbered="true" toc="default">
      <name>Protocol Flow</name>
      <t>The following subsections describe the three main phases of the protocol:</t>

<t><list style="symbols">
  <t>Bootstrap:
      <ul spacing="compact">
        <li>Bootstrap: the IdO asks an ACME CA to create a short-term and automatically-renewed short-term,
	automatically renewed (STAR) certificate (<xref target="proto-bootstrap"/>);</t>
  <t>Auto-renewal: target="proto-bootstrap" format="default"/>);</li>
        <li>Auto-renewal: the ACME CA periodically re-issues reissues the short-term
	certificate and posts it to the star-certificate URL (<xref target="proto-auto-renewal"/>);</t>
  <t>Termination: target="proto-auto-renewal" format="default"/>);</li>
        <li>Termination: the IdO requests the ACME CA to discontinue the
	automatic renewal of the certificate (<xref target="proto-termination"/>).</t>
</list></t> target="proto-termination" format="default"/>).</li>
      </ul>
      <section anchor="proto-bootstrap" title="Bootstrap"> numbered="true" toc="default">
        <name>Bootstrap</name>
        <t>The IdO, in its role as an
ACME client, requests the CA to issue a STAR certificate, i.e., one that:</t>

<t><list style="symbols">
  <t>Has
        <ul spacing="compact">
          <li>Has a short validity, e.g., 24 to 72 hours. Note that the exact definition of “short” "short" depends on the use case;</t>
  <t>Is case;</li>
          <li>Is automatically renewed by the CA for a certain period of time;</t>
  <t>Is time;</li>
          <li>Is downloadable from a (highly available) location.</t>
</list></t> location.</li>
        </ul>
        <t>Other than that, the ACME protocol flows as usual between IdO and CA.
In particular, IdO is responsible for satisfying the requested ACME challenges until the CA is willing to issue the requested certificate.
Per normal ACME processing, the IdO is given back an Order resource associated with the STAR certificate to be used in subsequent interaction with the CA (e.g., if
the certificate needs to be terminated.)</t>
        <t>The bootstrap phase ends when the ACME CA updates the Order resource to include the URL for the issued STAR certificate.</t>
      </section>
      <section anchor="proto-auto-renewal" title="Refresh"> numbered="true" toc="default">

        <name>Auto Renewal</name>

        <t>The CA issues the initial certificate after the authorization
        completes successfully.  It then automatically re-issues reissues the
        certificate using the same CSR Certificate Signing Request (CSR) (and therefore the same identifier and
        public key) before the previous one expires, expires and publishes it to the
        URL that was returned to the IdO at the end of the bootstrap phase.
        The certificate user, which could be either the IdO itself or a
        delegated third
party, party as described in <xref target="I-D.ietf-acme-star-delegation"/>,
        target="I-D.ietf-acme-star-delegation" format="default"/>, obtains the
        certificate (<xref target="fetching-certificates"/>) target="fetching-certificates" format="default"/>)
        and uses it.</t>
        <t>The refresh auto-renewal process (<xref target="figprotorefresh"/>) target="figprotorefresh" format="default"/>) goes on until either:</t>

<t><list style="symbols">
  <t>IdO
        <ul spacing="compact">
          <li>IdO explicitly terminates the automatic renewal (<xref target="proto-termination"/>); or</t>
  <t>Automatic target="proto-termination" format="default"/>); or</li>
          <li>Automatic renewal expires.</t>
</list></t> expires.</li>
        </ul>

        <figure title="Auto renewal" anchor="figprotorefresh"><artwork><![CDATA[ anchor="figprotorefresh">
          <name>Auto-renewal</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
   Certificate             ACME/STAR
   User                    Server
   |     Retrieve cert     |                     [...]
   |---------------------->|                      |
   |                       +------.              /
   |                       |      |             /
   |                       | Automatic renewal :
   |                       |      |             \
   |                       |<-----'              \
   |     Retrieve cert     |                      |
   |---------------------->|            short validity period
   |                       |                      |
   |                       +------.              /
   |                       |      |             /
   |                       | Automatic renewal :
   |                       |      |             \
   |                       |<-----'              \
   |     Retrieve cert     |                      |
   |---------------------->|            short validity period
   |                       |                      |
   |                       +------.              /
   |                       |      |             /
   |                       | Automatic renewal :
   |                       |      |             \
   |                       |<-----'              \
   |                       |                      |
   |         [...]         |                    [...]
]]></artwork></figure>
]]></artwork>
        </figure>
      </section>
      <section anchor="proto-termination" title="Termination"> numbered="true" toc="default">
        <name>Termination</name>
        <t>The IdO may request early termination of the STAR certificate by
        sending a cancellation request to the Order resource, resource as described in
        <xref target="protocol-details-canceling"/>. target="protocol-details-canceling" format="default"/>.  After
        the CA receives and verifies the request, it shall:</t>

<t><list style="symbols">
  <t>Cancel
        <ul spacing="compact">
          <li>Cancel the automatic renewal process for the STAR certificate;</t>
  <t>Change certificate;</li>
          <li>Change the certificate publication resource to return an error indicating the termination of the issuance;</t>
  <t>Change issuance;</li>
          <li>Change the status of the Order to “canceled”.</t>
</list></t> "canceled".</li>
        </ul>
        <t>Note that it is not necessary to explicitly revoke the short-term certificate.</t>
        <figure title="Termination" anchor="figprototerm"><artwork><![CDATA[ anchor="figprototerm">
          <name>Termination</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
   Certificate                                     ACME/STAR
   User                    IdO                     Server
   |                       |                       |
   |                       |      Cancel Order     |
   |                       +---------------------->|
   |                       |                       +-------.
   |                       |                       |       |
   |                       |                       | End auto renewal auto-renewal
   |                       |                       | Remove cert link
   |                       |                       | etc.
   |                       |                       |       |
   |                       |         Done          |<------'
   |                       |<----------------------+
   |                       |                       |
   |                                               |
   |              Retrieve cert                    |
   +---------------------------------------------->|
   |              Error: autoRenewalCanceled       |
   |<----------------------------------------------+
   |                                               |
]]></artwork></figure>
]]></artwork>
        </figure>
      </section>
    </section>

    <section anchor="protocol-details" title="Protocol Details"> numbered="true" toc="default">
      <name>Protocol Details</name>
      <t>This section describes the protocol details, namely the extensions
to the ACME protocol required to issue STAR certificates.</t>
      <section anchor="acme-extensions" title="ACME Extensions"> numbered="true" toc="default">
        <name>ACME Extensions</name>
        <t>This protocol extends the ACME protocol, protocol to allow for automatically renewed Orders.</t>
        <section anchor="star-order-ext" title="Extending numbered="true" toc="default">
          <name>Extending the Order Resource"> Resource</name>
          <t>The Order resource is extended with a new “auto-renewal” "auto-renewal" object
          that MUST <bcp14>MUST</bcp14> be present for STAR certificates.  The “auto-renewal”
          "auto-renewal" object has the following structure:</t>

<t><list style="symbols">
  <t>start-date
          <ul spacing="compact">
            <li>start-date (optional, string): the The earliest date of validity
            of the first certificate issued, in <xref target="RFC3339"/> target="RFC3339"
            format="default"/> format.  When omitted, the start date is as
            soon as authorization is complete.</t>
  <t>end-date complete.</li>
            <li>end-date (required, string): the The latest date of validity of
            the last certificate issued, in <xref target="RFC3339"/> format.</t>
  <t>lifetime target="RFC3339"
            format="default"/> format.</li>
            <li>lifetime (required, integer): the The maximum validity period of
            each STAR certificate, an integer that denotes a number of
            seconds.  This is a nominal value which that does not include any extra
            validity time due to server or client adjustment (see below).</t>
  <t>lifetime-adjust below).</li>
            <li>lifetime-adjust (optional, integer): The amount of “left pad” "left pad"
            added to each STAR certificate, an integer that denotes a number
            of seconds.  The default is 0.  If present, the value of the
            notBefore field that would otherwise appear in the STAR
            certificates is pre-dated by the specified number of seconds.  See also
            <xref target="operational-cons-clocks"/> target="operational-cons-clocks" format="default"/> for
            why a client might want to use this control control, and <xref target="computing-effective-cert-lifetime"/>
            target="computing-effective-cert-lifetime" format="default"/> for
            how the effective certificate lifetime is computed.  The value
            reflected by the server, together with the value of the lifetime
            attribute, can be used by the client as a hint to configure its
            polling timer.</t>
  <t>allow-certificate-get timer.</li>
            <li>allow-certificate-get (optional, boolean): see See <xref target="certificate-get-nego"/>.</t>
</list></t>
            target="certificate-get-nego" format="default"/>.</li>
          </ul>

          <t>These attributes are included in a POST message when creating the Order,
          Order as part of the “payload” object encoded object. as "payload".  They are returned
          when the Order has been created, and the created. The ACME server MAY <bcp14>MAY</bcp14>
          adjust them at will, will according to its local policy (see also <xref target="capability-discovery"/>).</t>
          target="capability-discovery" format="default"/>).</t>
          <t>The optional notBefore and notAfter fields defined in Section 7.1.3 of <xref target="RFC8555"/> MUST NOT
          target="RFC8555" sectionFormat="of" section="7.1.3"/> <bcp14>MUST
          NOT</bcp14> be present in a STAR Order.  If they are included, the
          server MUST <bcp14>MUST</bcp14> return an error with status code 400 “Bad
Request” (Bad
          Request) and type “malformedRequest”.</t>

<t>Section 7.1.6 of <xref target="RFC8555"/> "malformedRequest".</t>
          <t><xref target="RFC8555" sectionFormat="of" section="7.1.6"/>
          defines the following values for the Order resource’s resource's status: “pending”, “ready”, “processing”, “valid”,
          "pending", "ready", "processing", "valid", and “invalid”. "invalid".  In the
          case of auto-renewal Orders, the status MUST <bcp14>MUST</bcp14> be “valid”
          "valid" as long as STAR certificates are being issued.  We add  This
          document adds a new status value: “canceled”, see "canceled" (see <xref target="protocol-details-canceling"/>.</t>
          target="protocol-details-canceling" format="default"/>).</t>
          <t>A STAR certificate is by definition a dynamic resource, i.e., it
          refers to an entity that varies over time.  Instead of overloading
          the semantics of the “certificate” "certificate" attribute, this document defines
          a new attribute “star-certificate” attribute, "star-certificate", to be used instead of “certificate”.</t>

<t><list style="symbols">
  <t>star-certificate
          "certificate".</t>
          <ul spacing="compact">
            <li>star-certificate (optional, string): A URL for the (rolling)
            STAR certificate that has been issued in response to this Order.</t>
</list></t>
            Order.</li>
          </ul>
        </section>
        <section anchor="protocol-details-canceling" title="Canceling numbered="true" toc="default">
          <name>Canceling an Auto-renewal Order"> Order</name>
          <t>An important property of the auto-renewal Order is that it can be
          canceled by the IdO, IdO with no need for certificate revocation. To
          cancel the Order, the ACME client sends a POST to the Order URL as
          shown in <xref target="figcancelingstarorder"/>.</t> target="figcancelingstarorder"
          format="default"/>.</t>
          <figure title="Canceling anchor="figcancelingstarorder">
            <name>Canceling an Auto-renewal Order" anchor="figcancelingstarorder"><artwork><![CDATA[ Order</name>
<sourcecode>
  POST /acme/order/ogfr8EcolOT HTTP/1.1
  Host: example.org example.com
  Content-Type: application/jose+json

  {
    "protected": base64url({
      "alg": "ES256",
      "kid": "https://example.com/acme/acct/gw06UNhKfOve",
      "nonce": "Alc00Ap6Rt7GMkEl3L1JX5",
      "url": "https://example.com/acme/order/ogfr8EcolOT"
    }),
    "payload": base64url({
      "status": "canceled"
    }),
    "signature": "g454e3hdBlkT4AEw...nKePnUyZTjGtXZ6H"
  }
]]></artwork></figure>
</sourcecode>
          </figure>
          <t>After a successful cancellation, the server MUST NOT <bcp14>MUST NOT</bcp14> issue any additional certificates for this Order.</t>
          <t>When the Order is canceled, the server:</t>

<t><list style="symbols">
  <t>MUST
          <ul spacing="compact">
            <li><bcp14>MUST</bcp14> update the status of the Order resource to “canceled” "canceled" and MUST <bcp14>MUST</bcp14> set an appropriate “expires” date;</t>
  <t>MUST "expires" date;</li>
            <li><bcp14>MUST</bcp14> respond with 403 (Forbidden) to any
            requests to the star-certificate endpoint.  The response SHOULD
            <bcp14>SHOULD</bcp14> provide additional information using a
            problem document <xref target="RFC7807"/> target="RFC7807" format="default"/> with
            type “urn:ietf:params:acme:error:autoRenewalCanceled”.</t>
</list></t> "urn:ietf:params:acme:error:autoRenewalCanceled".</li>
          </ul>
          <t>Issuing a cancellation for an Order that is not in “valid” "valid" state
          is not allowed.  A client MUST NOT <bcp14>MUST NOT</bcp14> send such a
          request, and a server MUST <bcp14>MUST</bcp14> return an error response
          with status code 400 (Bad Request) and type “urn:ietf:params:acme:error:autoRenewalCancellationInvalid”.</t>
          "urn:ietf:params:acme:error:autoRenewalCancellationInvalid".</t>
          <t>The state machine described in Section 7.1.6 of <xref target="RFC8555"/>
          target="RFC8555" sectionFormat="of" section="7.1.6"/> is extended as illustrated in
          <xref target="fig-order-state-transitions-ext"/> (State target="fig-order-state-transitions-ext" format="default"/>.</t>

          <figure anchor="fig-order-state-transitions-ext">
	    <name>State Transitions for STAR Order Objects).</t>

<figure anchor="fig-order-state-transitions-ext"><artwork><![CDATA[ Objects</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    pending --------------+
       |                  |
       | All authz        |
       | "valid"          |
       V                  |
     ready ---------------+
       |                  |
       | Receive          |
       | finalize         |
       | request          |
       V                  |
   processing ------------+
       |                  |
       | First            |
       | certificate      | Error or
       | issued           | Authorization failure
       |                  |
       |                  V                  V
     valid
       |               invalid
       V
     valid----------------+
       |                  |
       | STAR             |
       | Certificate      | Natural
       | canceled         | Expiration
       V                  |
    canceled

]]></artwork></figure>             ='=
]]></artwork>
          </figure>
          <t>Explicit certificate revocation using the revokeCert interface (Section 7.6 of <xref target="RFC8555"/>)
          (<xref target="RFC8555" sectionFormat="of" section="7.6"/>) is not
          supported for STAR certificates.  A server receiving a revocation
          request for a STAR certificate MUST <bcp14>MUST</bcp14> return an error
          response with status code 403 (Forbidden) and type “urn:ietf:params:acme:error:autoRenewalRevocationNotSupported”.</t>
          "urn:ietf:params:acme:error:autoRenewalRevocationNotSupported".</t>
        </section>
      </section>
      <section anchor="capability-discovery" title="Capability Discovery"> numbered="true" toc="default">
        <name>Capability Discovery</name>
        <t>In order to support the discovery of STAR capabilities, the “meta” "meta"
        field inside the directory object defined in Section 9.7.6 of <xref target="RFC8555"/>
        target="RFC8555" sectionFormat="of" section="9.7.6"/> is extended with a new “auto-renewal”
        "auto-renewal" object.  The “auto-renewal” "auto-renewal" object MUST <bcp14>MUST</bcp14>
        be present if the server supports STAR.  Its structure is as
        follows:</t>

<t><list style="symbols">
  <t>min-lifetime
        <ul spacing="compact">
          <li>min-lifetime (required, integer): minimum Minimum acceptable value for
          auto-renewal lifetime, in seconds.</t>
  <t>max-duration seconds.</li>
          <li>max-duration (required, integer): maximum Maximum allowed delta between
          the auto-renewal end-date and start-date, in seconds.</t>
  <t>allow-certificate-get start-date attributes of the Order's auto-renewal
	  object.</li>
          <li>allow-certificate-get (optional, boolean): see See <xref target="certificate-get-nego"/>.</t>
</list></t>
          target="certificate-get-nego" format="default"/>.</li>
        </ul>
        <t>An example directory object advertising STAR support with one day one-day
        min-lifetime and one year max-duration, one-year max-duration and supporting certificate
        fetching with an HTTP GET is shown in <xref target="figstardir"/>.</t> target="figstardir"
        format="default"/>.</t>
        <figure title="Directory object anchor="figstardir">
          <name>Directory Object with STAR support" anchor="figstardir"><artwork><![CDATA[ Support</name>

<sourcecode type="JSON">
 {
    "new-nonce": "https://example.com/acme/new-nonce",
    "new-account": "https://example.com/acme/new-account",
    "new-order": "https://example.com/acme/new-order",
    "new-authz": "https://example.com/acme/new-authz",
    "revoke-cert": "https://example.com/acme/revoke-cert",
    "key-change": "https://example.com/acme/key-change",
    "meta": {
      "terms-of-service": "https://example.com/acme/terms/2017-5-30",
      "website": "https://www.example.com/",
      "caa-identities": ["example.com"],
      "auto-renewal": {
        "min-lifetime": 86400,
        "max-duration":  31536000,
        "allow-certificate-get": true
      }
    }
 }
]]></artwork></figure>
</sourcecode>

        </figure>
      </section>
      <section anchor="fetching-certificates" title="Fetching numbered="true" toc="default">
        <name>Fetching the Certificates"> Certificates</name>
        <t>The certificate is fetched from the star-certificate endpoint with
        POST-as-GET as per <xref target="RFC8555"/> Section 7.4.2, target="RFC8555" sectionFormat="of"
        section="7.4.2"/> unless the client and server have successfully
        negotiated the “unauthenticated GET” "unauthenticated GET" option described in <xref target="certificate-get-nego"/>.
        target="certificate-get-nego" format="default"/>.  In such case, the
        client can simply issue a GET to the star-certificate resource without
        authenticating itself to the server as illustrated in <xref target="figunauthgetstarcert"/>.</t>
        target="figunauthgetstarcert" format="default"/>.</t>
        <figure title="Fetching anchor="figunauthgetstarcert">
          <name>Fetching a STAR certificate Certificate with unauthenticated GET" anchor="figunauthgetstarcert"><artwork><![CDATA[ Unauthenticated GET</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  GET /acme/cert/g7m3ZQeTEqa HTTP/1.1
  Host: example.org example.com
  Accept: application/pem-certificate-chain

  HTTP/1.1 200 OK
  Content-Type: application/pem-certificate-chain
  Link: <https://example.com/acme/some-directory>;rel="index"
  Cert-Not-Before: Thu, 3 Oct 2019 00:00:00 GMT
  Cert-Not-After: Thu, 10 Oct 2019 00:00:00 GMT

  -----BEGIN CERTIFICATE-----
  [End-entity certificate contents]
  -----END CERTIFICATE-----
  -----BEGIN CERTIFICATE-----
  [Issuer certificate contents]
  -----END CERTIFICATE-----
  -----BEGIN CERTIFICATE-----
  [Other certificate contents]
  -----END CERTIFICATE-----
]]></artwork></figure>
]]></artwork>
        </figure>
        <t>The Server SHOULD server <bcp14>SHOULD</bcp14> include the “Cert-Not-Before” "Cert-Not-Before" and “Cert-Not-After”
        "Cert-Not-After" HTTP header fields in the response.  When they exist,
        they MUST <bcp14>MUST</bcp14> be equal to the respective fields inside the
        end-entity certificate. Their format is “HTTP-date” "HTTP-date" as defined in Section 7.1.1.2 of
        <xref target="RFC7231"/>. target="RFC7231" sectionFormat="of" section="7.1.1.2"/>.  Their
        purpose is to enable client implementations that do not parse the
        certificate.</t>

<t>Following
        <t>The following are further clarifications regarding usage of these
        header fields, fields as per <xref target="RFC7231"/> Sec. 8.3.1. target="RFC7231" sectionFormat="of"
	section="8.3.1"/>. All apply to both headers.</t>

<t><list style="symbols">
  <t>This
        <ul spacing="compact">
          <li>This header field is a single value, not a list.</t>
  <t>The list.</li>
          <li>The header field is used only in responses to GET, HEAD HEAD, and
          POST-as-GET requests, and only for MIME types that denote public key certificates.</t>
  <t>Header
          certificates.</li>
          <li>Header field semantics are independent of context.</t>
  <t>The context.</li>
          <li>The header field is not hop-by-hop.</t>
  <t>Intermediaries MAY hop-by-hop.</li>
          <li>Intermediaries <bcp14>MAY</bcp14> insert or delete the value;</t>
  <t>If value;</li>
          <li>If an intermediary inserts the value, it MUST <bcp14>MUST</bcp14>
          ensure that the newly added value matches the corresponding value in
          the certificate.</t>
  <t>The certificate.</li>
          <li>The header field is not appropriate for a Vary field.</t>
  <t>The field.</li>
          <li>The header field is allowed within message trailers.</t>
  <t>The trailers.</li>
          <li>The header field is not appropriate within redirects.</t>
  <t>The redirects.</li>
          <li>The header field does not introduce additional security
          considerations. It discloses in a simpler form information that is
	  already available inside the certificate.</t>
</list></t> certificate.</li>
        </ul>

<t>To improve robustness, the next certificate MUST <bcp14>MUST</bcp14> be made
available by the ACME CA at the URL
pointed indicated by “star-certificate” at the latest "star-certificate" halfway
through the lifetime of the currently active certificate. certificate at the latest.  It is
worth noting that this has an implication in case of cancellation: cancellation; in fact,
from the time the next certificate is made available, the cancellation is not
completely effective until the “next” "next" certificate also expires.  To avoid the
client accidentally entering a broken state, the notBefore of the “next” "next"
certificate MUST <bcp14>MUST</bcp14> be set so that the certificate is already
valid when it is published at the “star-certificate” "star-certificate" URL.  Note that the
server might need to increase the auto-renewal lifetime-adjust value to
satisfy the latter requirement.  For a detailed description of the renewal
scheduling logic, see <xref target="computing-effective-cert-lifetime"/>. target="computing-effective-cert-lifetime"
format="default"/>.  For further rationale on the need for adjusting the
certificate validity, see <xref target="operational-cons-clocks"/>.</t> target="operational-cons-clocks"
format="default"/>.</t>
        <t>The server MUST NOT <bcp14>MUST NOT</bcp14> issue any certificates for this
        Order with notAfter after the auto-renewal end-date.</t>
        <t>For expired Orders, the server MUST <bcp14>MUST</bcp14> respond with 403
        (Forbidden) to any requests to the star-certificate endpoint.  The
        response SHOULD <bcp14>SHOULD</bcp14> provide additional information using a
        problem document <xref target="RFC7807"/> target="RFC7807" format="default"/> with type “urn:ietf:params:acme:error:autoRenewalExpired”.
        "urn:ietf:params:acme:error:autoRenewalExpired". Note that the Order resource’s
        resource's state remains “valid”, "valid", as per the base protocol.</t>
      </section>

      <section anchor="certificate-get-nego" title="Negotiating numbered="true" toc="default">
        <name>Negotiating an unauthenticated GET"> Unauthenticated GET</name>
        <t>In order to enable the name delegation workflow defined in <xref target="I-D.ietf-acme-star-delegation"/> as well as
        target="I-D.ietf-acme-star-delegation" format="default"/> and to
        increase the reliability of the STAR ecosystem (see <xref target="dependability"/>
        target="dependability" format="default"/> for details), this document
        defines a mechanism that allows a server to advertise support for
        accessing star-certificate resources via unauthenticated GET (in
        addition to POST-as-GET), and a client to enable this service with
        per-Order granularity.</t>

        <t>Specifically, a server states its availability to grant
        unauthenticated access to a client’s client's Order star-certificate by setting
        the allow-certificate-get attribute to true "true" in the auto-renewal object
        of the meta field inside the
Directory directory object:</t>

<t><list style="symbols">
  <t>allow-certificate-get
        <ul spacing="compact">
          <li>allow-certificate-get (optional, boolean): If this field is
          present and set to true, "true", the server allows GET (and HEAD) requests
          to star-certificate URLs.</t>
</list></t> URLs.</li>
        </ul>
        <t>A client states its desire to access the issued star-certificate
        via unauthenticated GET by adding an allow-certificate-get attribute
        to the auto-renewal object of the payload of its newOrder request and
        setting it to
true.</t>

<t><list style="symbols">
  <t>allow-certificate-get "true".</t>
        <ul spacing="compact">
          <li>allow-certificate-get (optional, boolean): If this field is
          present and set to true, "true", the client requests the server to allow
          unauthenticated GET (and HEAD) to the star-certificate associated
          with this Order.</t>
</list></t> Order.</li>
        </ul>
        <t>If the server accepts the request, it MUST <bcp14>MUST</bcp14> reflect
        the attribute setting in the resulting Order order object.</t>

        <t>Note that even when the use of unauthenticated GET has been agreed, agreed
        upon, the server
MUST <bcp14>MUST</bcp14> also allow POST-as-GET requests
        to the star-certificate resource.</t>
      </section>
      <section anchor="computing-effective-cert-lifetime" title="Computing numbered="true" toc="default">
        <name>Computing notBefore and notAfter of STAR Certificates"> Certificates</name>
        <t>We define “nominal "nominal renewal date” date" as the point in time when a new
        short-term certificate for a given STAR Order is due.  Its cadence is
        a multiple of the
Order’s Order's auto-renewal lifetime that starts with the
        issuance of the first short-term certificate and is upper-bounded by
        the Order’s Order's auto-renewal end-date (<xref target="fignrd"/>).</t> target="fignrd"
        format="default"/>).</t>
        <figure title="Nominal anchor="fignrd">
          <name>Nominal Renewal Date" anchor="fignrd"><artwork><![CDATA[ Date</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
    T      - STAR Order's auto-renewal lifetime
    end    - STAR Order's auto-renewal end-date
    nrd[i] - nominal renewal date of the i-th STAR certificate

                 .- T -.   .- T -.   .- T -.   .__.
                /       \ /       \ /       \ /  end
    -----------o---------o---------o---------o----X-------> t
              nrd[0]    nrd[1]    nrd[2]    nrd[3]
]]></artwork></figure>
]]></artwork>
        </figure>
        <t>The rules to determine the notBefore and notAfter values of the i-th STAR
certificate are as follows:</t>

<figure><artwork><![CDATA[
        <artwork name="" type="" align="left" alt=""><![CDATA[
    notAfter  = min(nrd[i] + T, end)
    notBefore = nrd[i] - max(adjust_client, adjust_server)
]]></artwork></figure>
]]></artwork>

        <t>Where “adjust_client” "adjust_client" is the min minimum value between the auto-renewal
        lifetime-adjust value
(“la”), ("la"), optionally supplied by the client, and
        the auto-renewal lifetime of each short-term certificate (“T”); “adjust_server” ("T");
        "adjust_server" is the amount of padding added by the ACME server to
        make sure that all certificates being published are valid at the time
        of publication.  The server padding is a fraction f (f) of T (i.e., f
        * T with .5 &lt;= f &lt; 1, 1; see <xref target="fetching-certificates"/>):</t>

<figure><artwork><![CDATA[ target="fetching-certificates"
        format="default"/>):</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
    adjust_client = min(T, la)
    adjust_server = f * T
]]></artwork></figure>
]]></artwork>
        <t>Note that the ACME server MUST NOT <bcp14>MUST NOT</bcp14> set the notBefore of the first STAR
certificate to a date prior to the auto-renewal start-date.</t>
        <section anchor="example" title="Example"> numbered="true" toc="default">
          <name>Example</name>
          <t>Given a server that intends to publish the next STAR certificate halfway
through the lifetime of the previous one, and a STAR Order with the following
attributes:</t>

<figure><artwork><![CDATA[
          <artwork name="" type="" align="left" alt=""><![CDATA[
     "auto-renewal": {
       "start-date": "2019-01-10T00:00:00Z",
       "end-date": "2019-01-20T00:00:00Z",
       "lifetime": 345600,          // 4 days
       "lifetime-adjust": 259200    // 3 days
     }
]]></artwork></figure>
]]></artwork>
          <t>The amount of time that needs to be subtracted from each nominal renewal
date is 3 days – days, i.e., max(min(345600, 259200), 345600 * .5).</t>
          <t>The notBefore and notAfter of each short-term certificate are:</t>

<texttable>
      <ttcol align='left'>notBefore</ttcol>
      <ttcol align='left'>notAfter</ttcol>
      <c>2019-01-10T00:00:00Z</c>
      <c>2019-01-14T00:00:00Z</c>
      <c>2019-01-11T00:00:00Z</c>
      <c>2019-01-18T00:00:00Z</c>
      <c>2019-01-15T00:00:00Z</c>
      <c>2019-01-20T00:00:00Z</c>
</texttable>
          <table align="center">
            <thead>
              <tr>
                <th align="left">notBefore</th>
                <th align="left">notAfter</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">2019-01-10T00:00:00Z</td>
                <td align="left">2019-01-14T00:00:00Z</td>
              </tr>
              <tr>
                <td align="left">2019-01-11T00:00:00Z</td>
                <td align="left">2019-01-18T00:00:00Z</td>
              </tr>
              <tr>
                <td align="left">2019-01-15T00:00:00Z</td>
                <td align="left">2019-01-20T00:00:00Z</td>
              </tr>
            </tbody>
          </table>
          <t>The value of the notBefore is also the time at which the client should expect
the new certificate to be available from the star-certificate endpoint.</t>
        </section>
      </section>
    </section>
    <section anchor="operational-considerations" title="Operational Considerations"> numbered="true" toc="default">
      <name>Operational Considerations</name>
      <section anchor="operational-cons-clocks" title="The numbered="true" toc="default">
        <name>The Meaning of “Short Term” "Short Term" and the Impact of Skewed Clocks">

<t>“Short Term” Clocks</name>
        <t>"Short Term" is a relative concept, therefore concept; therefore, trying to define a cut-off
        cutoff point that works in all cases would be a useless exercise.  In
        practice, the expected lifetime of a STAR certificate will be counted
        in minutes, hours hours, or days, depending on different factors: the
        underlying requirements for revocation, how much clock synchronization
        is expected among relying parties and the issuing CA, etc.</t>
        <t>Nevertheless, this section attempts to provide reasonable
        suggestions for the Web use case, informed by current operational and
        research experience.</t>
        <t>Acer et al. <xref target="Acer"/> al.&nbsp;<xref target="ACER" format="default"/> find that one of
        the main causes of “HTTPS error” "HTTPS error" warnings in browsers is misconfigured
        client clocks.  In particular, they observe that roughly 95% of the “severe”
        "severe" clock skews – -- the 6.7% of clock-related breakage reports which
        that account for clients that are more than 24 hours behind – -- happen
        to be within 6-7 days.</t>

        <t>In order to avoid these spurious warnings about a not (yet) yet valid
        server certificate, site owners could use the auto-renewal
        lifetime-adjust attribute to control the effective lifetime of their Web facing
        Web-facing certificates.  The exact number depends on the percentage
        of the “clock-skewed” "clock-skewed" population that the site owner expects to
        protect – -- 5 days cover 97.3%, 7 days cover 99.6% – -- as well as the
        nominal auto-renewal lifetime of the STAR Order.  Note that exact
        choice is also likely to depend on the kinds of client that is are
        prevalent for a given site or app – -- for example, Android and Mac OS
        clients are known to behave better than Windows clients.  These
        considerations are clearly out of scope of the present this document.</t>

        <t>In terms of security, STAR certificates and certificates with OCSP must-staple the
        Online Certificate Status Protocol (OCSP) "must-staple" flag asserted <xref target="RFC7633"/>
        target="RFC7633" format="default"/> can be considered roughly
        equivalent if the STAR certificate’s certificate's and the OCSP response’s response's lifetimes
        are the same. (Here, "must-staple" refers to a certificate carrying a
	TLS feature extension with the "status_request" extension identifier
	<xref target="RFC6066"/>.)  Given OCSP responses can be cached cached, on average average, for 4
        days <xref target="Stark"/>, target="STARK" format="default"/>, it is RECOMMENDED
        <bcp14>RECOMMENDED</bcp14> that a STAR certificate that is used on the
        Web has an “effective” "effective" lifetime (excluding any adjustment to account
        for clock skews) no longer than 4 days.</t>
      </section>
      <section anchor="impact-on-certificate-transparency-ct-logs" title="Impact numbered="true" toc="default">
        <name>Impact on Certificate Transparency (CT) Logs"> Logs</name>
        <t>Even in the highly unlikely case STAR becomes the only certificate
        issuance model, discussion with the IETF TRANS Working Group and
        implementers of Certificate Transparency (CT) logs implementers suggests that existing
        CT Log Server server implementations
are capable are capable of sustaining the resulting
        100-fold increase in ingestion
rate.  Additionally, rate. Additionally, such a future, future
        higher load could be managed with a variety of techniques (e.g.,
        sharding by modulo of certificate hash, using “smart” "smart" load-balancing
        CT proxies, etc.).  With etc.). With regards to the increase in the log size,
        current CT log growth is already being managed with schemes like Chrome’s
        Chrome's Log Policy <xref target="OBrien"/> target="OBRIEN" format="default"/>, which
        allow Operators to define their log life-cycle; and life cycle, as well as allowing the CAs,
        User Agents, Monitors, and any other interested entities to
build-in build in
        support for that life-cycle life cycle ahead of time.</t>
      </section>
      <section anchor="dependability" title="HTTP numbered="true" toc="default">
        <name>HTTP Caching and Dependability"> Dependability</name>
        <t>When using authenticated POST-as-GET, the HTTPS endpoint from where
        the STAR certificate is fetched can’t can't be easily replicated by an
        on-path HTTP cache.  Reducing the caching properties of the protocol
        makes STAR clients increasingly dependent on the ACME server
        availability.  This might be problematic given the relatively high
        rate of client-server interactions in a STAR ecosystem and ecosystem, especially
        when multiple endpoints (e.g., a high number of CDN edge nodes) end up
        requesting the same certificate.  Clients and servers should consider
        using the mechanism described in <xref target="certificate-get-nego"/> target="certificate-get-nego"
        format="default"/> to mitigate the risk.</t>
        <t>When using unauthenticated GET to fetch the STAR certificate, the server SHALL <bcp14>SHALL</bcp14>
use the appropriate cache directives to set the freshness lifetime of the
response (Section 5.2 of <xref target="RFC7234"/>) (<xref target="RFC7234" sectionFormat="of" section="5.2"/>) such that on-path caches will consider
it stale before or at the time its effective lifetime is due to expire.</t>
      </section>
    </section>

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

<t>Note to RFC Editor: please remove anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>

      <section anchor="new-registries" numbered="true" toc="default">
        <name>New Registries</name>
        <t>Per this section before publication,
including document, IANA has created the reference to <xref target="RFC7942"/> and <xref target="I-D.sheffer-acme-star-request"/>.</t>

<t>This section records the status of known implementations of the
protocol defined by this specification at the time of posting of
this Internet-Draft, and is based on following new registries:</t>
        <ul spacing="compact">
          <li>ACME Order Auto-Renewal Fields (<xref target="iana-order-auto-renewal-registry" format="default"/>)</li>
          <li>ACME Directory Metadata Auto-Renewal Fields (<xref target="iana-metadata-auto-renewal-registry" format="default"/>)</li>
        </ul>
        <t>These registries are administered under a proposal described in Specification Required policy
<xref target="RFC7942"/>.  The description of implementations in target="RFC8126" format="default"/>.</t>
      </section>
      <section anchor="new-error-types" numbered="true" toc="default">
        <name>New Error Types</name>
        <t>Per this section is
intended to assist document, IANA has added the IETF in its decision processes in
progressing drafts following entries to RFCs.  Please note that the listing of any
individual implementation here does not imply endorsement by the
IETF.  Furthermore, "ACME Error Types" registry:</t>
        <table align="center">
          <thead>
            <tr>
              <th align="left">Type</th>
              <th align="left">Description</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">autoRenewalCanceled</td>
              <td align="left">The short-term certificate is no effort longer available because the auto-renewal Order has been spent to verify the
information presented here that was supplied explicitly canceled by IETF contributors.
This the IdO</td>
              <td align="left">RFC 8739</td>
            </tr>
            <tr>
              <td align="left">autoRenewalExpired</td>
              <td align="left">The short-term certificate is not intended as, and must not be construed to be, a
catalog of no longer available implementations or their features.  Readers
are advised to note that other implementations may exist.</t>

<t>According to <xref target="RFC7942"/>, “this will allow reviewers and working
groups to assign due consideration to documents that have because the
benefit of running code, which may serve as evidence of valuable
experimentation and feedback auto-renewal Order has expired</td>
              <td align="left">RFC 8739</td>
            </tr>
            <tr>
              <td align="left">autoRenewalCancellationInvalid</td>
              <td align="left">A request to cancel an auto-renewal Order that have made the implemented
protocols more mature.  It is up not in state "valid" has been received</td>
              <td align="left">RFC 8739</td>
            </tr>
            <tr>
              <td align="left">autoRenewalRevocationNotSupported</td>
              <td align="left">A request to revoke an auto-renewal Order has been received</td>
              <td align="left">RFC 8739</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="new-fields-in-order-objects" numbered="true" toc="default">
        <name>New Fields in Order Objects</name>
        <t>Per this document, IANA has added the individual working groups following entries to use this information as they see fit”.</t> the
        "ACME Order Object Fields" registry:</t>
        <table align="center">
          <thead>
            <tr>
              <th align="left">Field Name</th>
              <th align="left">Field Type</th>
              <th align="left">Configurable</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">auto-renewal</td>
              <td align="left">object</td>
              <td align="left">true</td>
              <td align="left">RFC 8739</td>
            </tr>
            <tr>
              <td align="left">star-certificate</td>
              <td align="left">string</td>
              <td align="left">false</td>
              <td align="left">RFC 8739</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="overview" title="Overview">

<t>The implementation is constructed around 3 elements: STAR Client for anchor="iana-order-auto-renewal-registry" numbered="true" toc="default">
        <name>Fields in the Name Delegation Client (NDC),
STAR Proxy for IdO and ACME Server for CA. The communication between
them is over "auto-renewal" Object within an IP network and the HTTPS protocol.</t> Order Object</name>
        <t>The software of "ACME Order Auto-Renewal Fields" registry lists field names that are
defined for use in the implementation is available at: https://github.com/mami-project/lurk</t>

<t>The following subsections offer a basic description, detailed information
is available JSON object included in https://github.com/mami-project/lurk/blob/master/proxySTAR_v2/README.md</t>

<section anchor="acme-server-with-star-extension" title="ACME Server with STAR extension">

<t>This is a fork of the Let’s Encrypt Boulder project that implements "auto-renewal" field of an
ACME compliant CA.
It includes modifications order object.</t>
        <t>Template:</t>
        <ul spacing="compact">
          <li>Field name: The string to extend the ACME protocol be used as it is specified a field name in this draft,
to support recurrent Orders and cancelling Orders.</t>

<t>The implementation understands the new “recurrent” attributes as part JSON object</li>
          <li>Field type: The type of value to be provided, e.g., string, boolean, array of
string</li>
          <li>Configurable: Boolean indicating whether the Certificate
issuance server should accept values
provided by the client</li>
          <li>Reference: Where this field is defined</li>
        </ul>
        <t>Initial contents: The fields and descriptions defined in <xref target="star-order-ext" format="default"/>.</t>
        <table align="center">
          <thead>
            <tr>
              <th align="left">Field Name</th>
              <th align="left">Field Type</th>
              <th align="left">Configurable</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">start-date</td>
              <td align="left">string</td>
              <td align="left">true</td>
              <td align="left">RFC 8739</td>
            </tr>
            <tr>
              <td align="left">end-date</td>
              <td align="left">string</td>
              <td align="left">true</td>
              <td align="left">RFC 8739</td>
            </tr>
            <tr>
              <td align="left">lifetime</td>
              <td align="left">integer</td>
              <td align="left">true</td>
              <td align="left">RFC 8739</td>
            </tr>
            <tr>
              <td align="left">lifetime-adjust</td>
              <td align="left">integer</td>
              <td align="left">true</td>
              <td align="left">RFC 8739</td>
            </tr>
            <tr>
              <td align="left">allow-certificate-get</td>
              <td align="left">boolean</td>
              <td align="left">true</td>
              <td align="left">RFC 8739</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="new-fields-in-the-meta-object-within-a-directory-object" numbered="true" toc="default">
        <name>New Fields in the POST request for "meta" Object within a new resource.
An additional process “renewalManager.go” Directory Object</name>
        <t>Per this document, IANA has been included added the following entry to the "ACME Directory Metadata Fields":</t>
        <table align="center">
          <thead>
            <tr>
              <th align="left">Field Name</th>
              <th align="left">Field Type</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">auto-renewal</td>
              <td align="left">object</td>
              <td align="left">RFC 8739</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="iana-metadata-auto-renewal-registry" numbered="true" toc="default">
        <name>Fields in parallel that reads the details of each recurrent request, automatically produces "auto-renewal" Object within a “cron” Linux based task Directory Metadata Object</name>
        <t>The "ACME Directory Metadata Auto-Renewal Fields" registry lists field names
that issues the recurrent certificates, until the lifetime ends or are defined for use in the Order is canceled.
This process is also JSON object included in charge of maintaining a fixed URI to enable the NDC to download certificates,
unlike Boulder’s regular process of producing a unique URI per certificate.</t>

</section>
<section anchor="star-proxy" title="STAR Proxy">

<t>The STAR Proxy has a double role as ACME client and STAR Server. The former is a fork "auto-renewal"
field of the EFF
Certbot project that implements an ACME compliant client with the STAR extension. directory "meta" object.</t>
        <t>Template:</t>
        <ul spacing="compact">
          <li>Field name: The latter is string to be used as a basic HTTP REST API server.</t>

<t>The STAR Proxy understands field name in the basic API request with a server. JSON object</li>
          <li>Field type: The current implementation type of the API value to be provided, e.g., string, boolean, array of
string</li>
          <li>Reference: Where this field is defined</li>
        </ul>
        <t>Initial contents: The fields and descriptions defined in draft-ietf-acme-star-01. Registration or Order cancellation
triggers the modified Certbot client that requests, or cancels, the recurrent generation
of certificates using the STAR extension over ACME protocol.
The URI <xref target="capability-discovery" format="default"/>.</t>
        <table align="center">
          <thead>
            <tr>
              <th align="left">Field Name</th>
              <th align="left">Field Type</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">min-lifetime</td>
              <td align="left">integer</td>
              <td align="left">RFC 8739</td>
            </tr>
            <tr>
              <td align="left">max-duration</td>
              <td align="left">integer</td>
              <td align="left">RFC 8739</td>
            </tr>
            <tr>
              <td align="left">allow-certificate-get</td>
              <td align="left">boolean</td>
              <td align="left">RFC 8739</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="iana-http-headers" numbered="true" toc="default">
        <name>Cert-Not-Before and Cert-Not-After HTTP Headers</name>
        <t>The "Message Headers" registry has been updated with the location of the recurrent certificate is delivered to the STAR client as a response.</t> following additional values:</t>
        <table align="center">
          <thead>
            <tr>
              <th align="left">Header Field Name</th>
              <th align="left">Protocol</th>
              <th align="left">Status</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">Cert-Not-Before</td>
              <td align="left">http</td>
              <td align="left">standard</td>
              <td align="left">RFC 8739, <xref target="fetching-certificates" format="default"/></td>
            </tr>
            <tr>
              <td align="left">Cert-Not-After</td>
              <td align="left">http</td>
              <td align="left">standard</td>
              <td align="left">RFC 8739, <xref target="fetching-certificates" format="default"/></td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
    <section anchor="level-of-maturity" title="Level of Maturity">

<t>This is a prototype.</t>

</section> anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <section anchor="coverage" title="Coverage">

<t>A STAR Client anchor="no-revocation" numbered="true" toc="default">
        <name>No Revocation</name>
        <t>STAR certificates eliminate an important security feature of PKI,
        which is not included in this implementation, but the ability to revoke certificates.  Revocation allows the
        administrator to limit the damage done by direct HTTP request with any open HTTP REST API tool.
This is expected to be covered as part a rogue node or an adversary
        who has control of the <xref target="I-D.sheffer-acme-star-request"/> implementation.</t>

<t>This implementation completely covers STAR Proxy and ACME Server with private key.  With STAR extension.</t>

</section>
<section anchor="version-compatibility" title="Version Compatibility">

<t>The implementation is compatible with version draft-ietf-acme-star-01.
The implementation certificates,
        expiration replaces revocation so there is based on the Boulder and Certbot code release from 7-Aug-2017.</t>

</section>
<section anchor="licensing" title="Licensing">
<t>This implementation inherits the Boulder license (Mozilla Public License 2.0)
and Certbot license (Apache License Version 2.0 ).</t>

</section>
<section anchor="implementation-experience" title="Implementation experience">

<t>To prove potential for lack of
        timeliness in the concept all revocation taking effect.  To that end, see also the implementation has been done with a self-signed CA,
to avoid impact
        discussion on real domains. To clock skew in <xref target="operational-cons-clocks"
        format="default"/>.</t>
        <t>It should be able to do it we use the FAKE_DNS property
of Boulder noted that revocation also has timeliness issues
        because both Certificate Revocation Lists (CRLs) and static /etc/hosts entries with domains names.
Nonetheless this implementation OCSP responses
        have nextUpdate fields that tell relying parties (RPs) how long they
        should run with real domains.</t>

<t>Most of the implementation has been made trust this revocation data.  These fields are typically set to avoid deep changes inside of Boulder
        hours, days, or Certbot, for example, the recurrent certificates issuance by even weeks in the CA is based
on an external process future.  Any revocation that auto-configures happens
        before the standard Linux “cron” daemon time in nextUpdate goes unnoticed by the ACME CA server.</t>

<t>The reference setup recommended is one physical host with 3 virtual machines,
one for each RP.</t>
        <t>One situation where the lack of explicit revocation could create a
        security risk to the 3 components (client, proxy and server) and IdO is when the connectivity based on host bridge.</t>

<t>Network security Order is not enabled (iptables default policies are “accept” and all rules removed) created with a
        start-date of some appreciable amount of time in this implementation to simplify and test the protocol.</t>

</section>
<section anchor="contact-information" title="Contact Information">

<t>See author details below.</t>

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

<t>[[RFC Editor: please replace XXXX below by the RFC number.]]</t>

<section anchor="new-registries" title="New Registries">

<t>This document requests future.  Recall
        that IANA create when authorizations have been fulfilled, the following new registries:</t>

<t><list style="symbols">
  <t>ACME Order Auto Renewal Fields (<xref target="iana-order-auto-renewal-registry"/>)</t>
  <t>ACME Directory Metadata Auto Renewal Fields (<xref target="iana-metadata-auto-renewal-registry"/>)</t>
</list></t>

<t>All of these registries are administered under a Specification Required policy
<xref target="RFC8126"/>.</t>

</section>
<section anchor="new-error-types" title="New Error Types">

<t>This document adds the following entries moves to the ACME Error Type registry:</t>

<texttable>
      <ttcol align='left'>Type</ttcol>
      <ttcol align='left'>Description</ttcol>
      <ttcol align='left'>Reference</ttcol>
      <c>autoRenewalCanceled</c>
      <c>The short-term certificate is no longer available because the auto-renewal Order has been explicitly canceled by
        "valid" state and the IdO</c>
      <c>RFC XXXX</c>
      <c>autoRenewalExpired</c>
      <c>The short-term certificate star-certificate endpoint is no longer available because populated with the auto-renewal Order has expired</c>
      <c>RFC XXXX</c>
      <c>autoRenewalCancellationInvalid</c>
      <c>A request
        first cert (<xref target="fig-order-state-transitions-ext"
        format="default"/>).  So, if an attacker manages to cancel a auto-renewal Order that get hold of the
        private key as well as the first (post-dated) certificate, there is not in state “valid” has been received</c>
      <c>RFC XXXX</c>
      <c>autoRenewalRevocationNotSupported</c>
      <c>A request to revoke
        a auto-renewal Order has been received</c>
      <c>RFC XXXX</c>
</texttable>

</section>
<section anchor="new-fields-in-order-objects" title="New fields time window in Order Objects">

<t>This document adds the following entries future when they will be able to successfully
        impersonate the ACME Order Object Fields registry:</t>

<texttable>
      <ttcol align='left'>Field Name</ttcol>
      <ttcol align='left'>Field Type</ttcol>
      <ttcol align='left'>Configurable</ttcol>
      <ttcol align='left'>Reference</ttcol>
      <c>auto-renewal</c>
      <c>object</c>
      <c>true</c>
      <c>RFC XXXX</c>
      <c>star-certificate</c>
      <c>string</c>
      <c>false</c>
      <c>RFC XXXX</c>
</texttable>

</section>
<section anchor="iana-order-auto-renewal-registry" title="Fields IdO.  Note that cancellation is pointless in this
        case.  In order to mitigate the “auto-renewal” Object within an Order Object">

<t>The “ACME Order Auto Renewal Fields” registry lists field names described threat, it is
        <bcp14>RECOMMENDED</bcp14> that are
defined for use in IdO place their Orders at a time that
        is close to the JSON object included in Order's start-date.</t>
        <t>More discussion of the “auto-renewal” field security of an
ACME order object.</t>

<t>Template:</t>

<t><list style="symbols">
  <t>Field name: The string to be used as a field name STAR certificates is available in
<xref target="TOPALOVIC" format="default"/>.</t>
      </section>
      <section anchor="denial-of-service-considerations" numbered="true" toc="default">
        <name>Denial-of-Service Considerations</name>
        <t>STAR adds a new attack vector that increases the JSON object</t>
  <t>Field type: The type threat of value
        denial-of-service attacks, caused by the change to be provided, e.g., string, boolean, array of
string</t>
  <t>Configurable: Boolean indicating whether the server should accept values
provided by CA's
        behavior. Each STAR request amplifies the client</t>
  <t>Reference: Where this field is defined</t>
</list></t>

<t>Initial contents: The fields and descriptions defined in <xref target="star-order-ext"/>.</t>

<texttable>
      <ttcol align='left'>Field Name</ttcol>
      <ttcol align='left'>Field Type</ttcol>
      <ttcol align='left'>Configurable</ttcol>
      <ttcol align='left'>Reference</ttcol>
      <c>start-date</c>
      <c>string</c>
      <c>true</c>
      <c>RFC XXXX</c>
      <c>end-date</c>
      <c>string</c>
      <c>true</c>
      <c>RFC XXXX</c>
      <c>lifetime</c>
      <c>integer</c>
      <c>true</c>
      <c>RFC XXXX</c>
      <c>lifetime-adjust</c>
      <c>integer</c>
      <c>true</c>
      <c>RFC XXXX</c>
      <c>allow-certificate-get</c>
      <c>boolean</c>
      <c>true</c>
      <c>RFC XXXX</c>
</texttable>

</section>
<section anchor="new-fields-in-the-meta-object-within-a-directory-object" title="New fields in resource demands upon the “meta” Object within a Directory Object">

<t>This document adds
        CA, where one Order produces not one but potentially dozens or
        hundreds of certificates, depending on the following entry auto-renewal "lifetime"
        parameter. An attacker can use this property to aggressively reduce
        the auto-renewal "lifetime" (e.g., 1 second) jointly with other ACME Directory Metadata Fields:</t>

<texttable>
      <ttcol align='left'>Field Name</ttcol>
      <ttcol align='left'>Field Type</ttcol>
      <ttcol align='left'>Reference</ttcol>
      <c>auto-renewal</c>
      <c>object</c>
      <c>RFC XXXX</c>
</texttable>

</section>
<section anchor="iana-metadata-auto-renewal-registry" title="Fields
        attack vectors identified in <xref target="RFC8555"
        sectionFormat="of" section="10"/>. Other collateral impact is related to the “auto-renewal” Object within a Directory Metadata Object">

<t>The “ACME Directory Metadata Auto Renewal Fields” registry lists field names
that are defined for use in
        certificate endpoint resource where the JSON object included in client can retrieve the “auto-renewal”
field of an ACME directory “meta” object.</t>

<t>Template:</t>

<t><list style="symbols">
  <t>Field name: The string
        certificates periodically. If this resource is external to be used as the CA
        (e.g., a field name in hosted web server), the JSON object</t>
  <t>Field type: The type previous attack will be reflected to
        that resource.</t>

        <t>Mitigation recommendations from ACME still apply, but some of value them
        need to be provided, e.g., string, boolean, array adjusted. For example, applying rate limiting to the
        initial request, due to the nature of
string</t>
  <t>Reference: Where this field is defined</t>
</list></t>

<t>Initial contents: the auto-renewal behavior,
        cannot solve the above problem. The fields CA server needs complementary
        mitigation, and descriptions defined in <xref target="capability-discovery"/>.</t>

<texttable>
      <ttcol align='left'>Field Name</ttcol>
      <ttcol align='left'>Field Type</ttcol>
      <ttcol align='left'>Reference</ttcol>
      <c>min-lifetime</c>
      <c>integer</c>
      <c>RFC XXXX</c>
      <c>max-duration</c>
      <c>integer</c>
      <c>RFC XXXX</c>
      <c>allow-certificate-get</c>
      <c>boolean</c>
      <c>RFC XXXX</c>
</texttable> specifically, it <bcp14>SHOULD</bcp14> enforce a
        minimum value on auto-renewal "lifetime". Alternatively, the CA can
        set a rate limit for internal certificate generation processes. Note
        that this limit has to take account of already scheduled renewal
        issuances as well as new incoming requests.</t>
      </section>

      <section anchor="iana-http-headers" title="Cert-Not-Before and Cert-Not-After HTTP Headers">

<t>The “Message Headers” registry should be updated with the following additional values:</t>

<texttable>
      <ttcol align='left'>Header Field Name</ttcol>
      <ttcol align='left'>Protocol</ttcol>
      <ttcol align='left'>Status</ttcol>
      <ttcol align='left'>Reference</ttcol>
      <c>Cert-Not-Before</c>
      <c>http</c>
      <c>standard</c>
      <c>RFC XXXX, <xref target="fetching-certificates"/></c>
      <c>Cert-Not-After</c>
      <c>http</c>
      <c>standard</c>
      <c>RFC XXXX, <xref target="fetching-certificates"/></c>
</texttable>

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

<section anchor="no-revocation" title=" No revocation">

<t>STAR certificates eliminate an important security feature of PKI which is the
ability to revoke certificates.  Revocation allows the administrator to limit
the damage done by a rogue node or an adversary who has control of the private
key.  With STAR certificates, expiration replaces revocation so there is
potential for lack of timeliness in the revocation taking effect.  To that end,
see also the discussion on clock skew in <xref target="operational-cons-clocks"/>.</t>

<t>It should be noted that revocation also has timeliness issues, because
both CRLs and OCSP responses have nextUpdate fields that tell relying parties (RPs) how
long they should trust this revocation data.  These fields are typically
set to hours, days, or even weeks in the future.  Any revocation that
happens before the time in nextUpdate goes unnoticed by the RP.</t>

<t>One situation where the lack of explicit revocation could create a security
risk to the IdO is when the Order is created with start-date some appreciable
amount of time in the future.  Recall that when authorizations have been
fulfilled, the Order moves to the “valid” state and the star-certificate
endpoint is populated with the first cert
(<xref target="fig-order-state-transitions-ext"/>).  So, if an attacker manages to get hold
of the private key as well as of the first (post-dated) certificate, there is a
time window in the future when they will be able to successfully impersonate
the IdO.  Note that cancellation is pointless in this case.  In order to
mitigate the described threat, it is RECOMMENDED that IdO place their Orders at
a time that is close to the Order’s start-date.</t>

<t>More discussion of the security of STAR certificates is available in
<xref target="Topalovic"/>.</t>

</section>
<section anchor="denial-of-service-considerations" title="Denial of Service Considerations">

<t>STAR adds a new attack vector that increases the threat of denial of
    service attacks, caused by the change to the CA’s behavior. Each STAR
    request amplifies the resource demands upon the CA, where one Order
    produces not one, but potentially dozens or hundreds of certificates,
    depending on the auto-renewal “lifetime” parameter. An attacker
    can use this property to aggressively reduce the
    auto-renewal “lifetime” (e.g. 1 sec.) jointly with other ACME
    attack vectors identified in Sec. 10 of <xref target="RFC8555"/>. Other collateral impact is
    related to the certificate endpoint resource where the client can
    retrieve the certificates periodically. If this resource is external to
    the CA (e.g. a hosted web server), the previous attack will be reflected to
    that resource.</t>

<t>Mitigation recommendations from ACME still apply, but some of them need
    to be adjusted. For example, applying rate limiting to the initial
    request, by the nature of the auto-renewal behavior cannot solve the
    above problem. The CA server needs complementary mitigation and
    specifically, it SHOULD enforce a minimum value on
    auto-renewal “lifetime”. Alternatively, the CA can set an
    internal certificate generation processes rate limit.
    Note that this limit has to take account of already-scheduled renewal
    issuances as well as new incoming requests.</t>

</section>
<section anchor="privacy-considerations" title="Privacy Considerations">

<t>In order to avoid correlation of certificates by account, if unauthenticated
GET is negotiated (<xref target="certificate-get-nego"/>) the recommendation in Section 10.5
of <xref target="RFC8555"/> regarding the choice of URL structure applies, i.e. servers SHOULD
choose URLs of certificate resources in a non-guessable way, for example using
capability URLs <xref target="W3C.WD-capability-urls-20140218"/>.</t>

</section>
</section>
<section anchor="acknowledgments" title="Acknowledgments">

<t>This work is partially supported by the European Commission under
Horizon 2020 grant agreement no. 688421 Measurement and Architecture
for a Middleboxed Internet (MAMI). This support does not imply endorsement.</t>

<t>Thanks to
Ben Kaduk,
Richard Barnes,
Roman Danyliw,
Jon Peterson,
Eric Rescorla,
Ryan Sleevi,
Sean Turner,
Alexey Melnikov,
Adam Roach,
Martin Thomson and
Mehmet Ersue
for helpful comments and discussions that have shaped this document.</t>

</section>

  </middle>

  <back>

    <references title='Normative References'>

<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 initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<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="RFC3339" target='https://www.rfc-editor.org/info/rfc3339'>
<front>
<title>Date and Time on the Internet: Timestamps</title>
<author initials='G.' surname='Klyne' fullname='G. Klyne'><organization /></author>
<author initials='C.' surname='Newman' fullname='C. Newman'><organization /></author>
<date year='2002' month='July' />
<abstract><t>This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.</t></abstract>
</front>
<seriesInfo name='RFC' value='3339'/>
<seriesInfo name='DOI' value='10.17487/RFC3339'/>
</reference>

<reference  anchor="RFC7231" target='https://www.rfc-editor.org/info/rfc7231'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems.  This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.</t></abstract>
</front>
<seriesInfo name='RFC' value='7231'/>
<seriesInfo name='DOI' value='10.17487/RFC7231'/>
</reference>

<reference  anchor="RFC7807" target='https://www.rfc-editor.org/info/rfc7807'>
<front>
<title>Problem Details for HTTP APIs</title>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham'><organization /></author>
<author initials='E.' surname='Wilde' fullname='E. Wilde'><organization /></author>
<date year='2016' month='March' />
<abstract><t>This document defines a &quot;problem detail&quot; as a way to carry machine- readable details of errors in a HTTP response to avoid the need to define new error response formats for HTTP APIs.</t></abstract>
</front>
<seriesInfo name='RFC' value='7807'/>
<seriesInfo name='DOI' value='10.17487/RFC7807'/>
</reference>

<reference  anchor="RFC8555" target='https://www.rfc-editor.org/info/rfc8555'>
<front>
<title>Automatic Certificate Management Environment (ACME)</title>
<author initials='R.' surname='Barnes' fullname='R. Barnes'><organization /></author>
<author initials='J.' surname='Hoffman-Andrews' fullname='J. Hoffman-Andrews'><organization /></author>
<author initials='D.' surname='McCarney' fullname='D. McCarney'><organization /></author>
<author initials='J.' surname='Kasten' fullname='J. Kasten'><organization /></author>
<date year='2019' month='March' />
<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="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
<date year='2017' month='May' />
<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>

<reference  anchor="RFC7234" target='https://www.rfc-editor.org/info/rfc7234'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Caching</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems.  This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.</t></abstract>
</front>
<seriesInfo name='RFC' value='7234'/>
<seriesInfo name='DOI' value='10.17487/RFC7234'/>
</reference>

<reference  anchor="RFC8126" target='https://www.rfc-editor.org/info/rfc8126'>
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author initials='M.' surname='Cotton' fullname='M. Cotton'><organization /></author>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
<author initials='T.' surname='Narten' fullname='T. Narten'><organization /></author>
<date year='2017' month='June' />
<abstract><t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters.  To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper.  For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t><t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed.  This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t><t>This is the third edition of this document; it obsoletes RFC 5226.</t></abstract>
</front>
<seriesInfo name='BCP' value='26'/>
<seriesInfo name='RFC' value='8126'/>
<seriesInfo name='DOI' value='10.17487/RFC8126'/>
</reference>

    </references>

    <references title='Informative References'>

<reference  anchor="RFC7942" target='https://www.rfc-editor.org/info/rfc7942'>
<front>
<title>Improving Awareness of Running Code: The Implementation Status Section</title>
<author initials='Y.' surname='Sheffer' fullname='Y. Sheffer'><organization /></author>
<author initials='A.' surname='Farrel' fullname='A. Farrel'><organization /></author>
<date year='2016' month='July' />
<abstract><t>This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section.  This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.</t><t>This process is not mandatory.  Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications.  This document obsoletes RFC 6982, advancing it to a Best Current Practice.</t></abstract>
</front>
<seriesInfo name='BCP' value='205'/>
<seriesInfo name='RFC' value='7942'/>
<seriesInfo name='DOI' value='10.17487/RFC7942'/>
</reference>

<reference  anchor="RFC7633" target='https://www.rfc-editor.org/info/rfc7633'>
<front>
<title>X.509v3 Transport Layer Security (TLS) Feature Extension</title>
<author initials='P.' surname='Hallam-Baker' fullname='P. Hallam-Baker'><organization /></author>
<date year='2015' month='October' />
<abstract><t>The purpose of the TLS feature extension is to prevent downgrade attacks that are not otherwise prevented by the TLS protocol.  In particular, the TLS feature extension may be used to mandate support for revocation checking features in the TLS protocol such as Online Certificate Status Protocol (OCSP) stapling.  Informing clients that an OCSP status response will always be stapled permits an immediate failure in the case that the response is not stapled.  This in turn prevents a denial-of-service attack that might otherwise be possible.</t></abstract>
</front>
<seriesInfo name='RFC' value='7633'/>
<seriesInfo name='DOI' value='10.17487/RFC7633'/>
</reference>

<reference anchor="I-D.sheffer-acme-star-request">
<front>
<title>Generating Certificate Requests for Short-Term, Automatically-Renewed (STAR) Certificates</title>

<author initials='Y' surname='Sheffer' fullname='Yaron Sheffer'>
    <organization />
</author>

<author initials='D' surname='Lopez' fullname='Diego Lopez'>
    <organization />
</author>

<author initials='O' surname='Dios' fullname='Oscar de Dios'>
    <organization />
</author>

<author initials='A' surname='Pastor' fullname='Antonio Pastor'>
    <organization />
</author>

<author initials='T' surname='Fossati' fullname='Thomas Fossati'>
    <organization />
</author>

<date month='June' day='29' year='2018' />

<abstract><t>This memo proposes a protocol that allows a domain name owner to delegate to a third party (such as a CDN) control over a certificate that bears one or more names in that domain.  Specifically the third party creates a Certificate Signing Request for the domain, which can then be used by the domain owner to request a short term and automatically renewed (STAR) certificate.  This is a component in a solution where a third-party such as a CDN can terminate TLS sessions on behalf of a domain name owner (e.g., a content provider), and the domain owner can cancel this delegation at any time without having anchor="privacy-considerations" numbered="true" toc="default">
        <name>Privacy Considerations</name>
        <t>In order to rely on certificate revocation mechanisms.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-sheffer-acme-star-request-02' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-sheffer-acme-star-request-02.txt' />
</reference>

<reference anchor="I-D.ietf-acme-star-delegation">
<front>
<title>An ACME Profile for Generating Delegated STAR Certificates</title>

<author initials='Y' surname='Sheffer' fullname='Yaron Sheffer'>
    <organization />
</author>

<author initials='D' surname='Lopez' fullname='Diego Lopez'>
    <organization />
</author>

<author initials='A' surname='Pastor' fullname='Antonio Pastor'>
    <organization />
</author>

<author initials='T' surname='Fossati' fullname='Thomas Fossati'>
    <organization />
</author>

<date month='August' day='26' year='2019' />

<abstract><t>This memo proposes a profile avoid correlation of certificates by account, if
        unauthenticated GET is negotiated (<xref target="certificate-get-nego"
        format="default"/>), the ACME protocol that allows recommendation in <xref target="RFC8555"
        sectionFormat="of" section="10.5"/> regarding the owner of an identifier (e.g., a domain name) to delegate to a third party access to a certificate associated with said identifier.  A primary use case is that of a CDN (the third party) terminating TLS sessions on behalf of a content provider (the owner choice of a domain name).  The presented mechanism allows the owner URL
        structure applies, i.e., servers <bcp14>SHOULD</bcp14> choose URLs of the identifier to retain control over the delegation and revoke it at any time by cancelling the associated STAR
        certificate renewal with the ACME CA. Another key property of this mechanism is it does not require any modification to the deployed TLS ecosystem.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-acme-star-delegation-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-acme-star-delegation-01.txt' />
</reference>

<reference anchor="I-D.nir-saag-star">
<front>
<title>Considerations For Using Short Term Certificates</title>

<author initials='Y' surname='Nir' fullname='Yoav Nir'>
    <organization />
</author>

<author initials='T' surname='Fossati' fullname='Thomas Fossati'>
    <organization />
</author>

<author initials='Y' surname='Sheffer' fullname='Yaron Sheffer'>
    <organization />
</author>

<author initials='T' surname='Eckert' fullname='Toerless Eckert'>
    <organization />
</author>

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

<abstract><t>Recently there has been renewed interest resources in an old idea: Issue certificates with short validity periods and forego revocation processing, reasoning that expiration is a sufficient replacement for revocation as long as that expiration is not too far off.  This document covers considerations, both security and operational, non-guessable way, for example, using such Short Term Auto Renewed (STAR) certificates for various scenarios where Using a revocation protocol is considered inappropriate.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-nir-saag-star-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-nir-saag-star-01.txt' />
</reference>
        capability URLs <xref target="W3C.CAPABILITY-URLS"
        format="default"/>.</t>
      </section>
    </section>

  </middle>
  <back>

<displayreference target="I-D.ietf-acme-star-delegation" to="STAR-DELEGATION"/>
<displayreference target="I-D.nir-saag-star" to="SHORT-TERM-CERTS"/>

 <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3339.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7231.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7807.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8555.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7234.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
      </references>
      <references>
        <name>Informative References</name>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7633.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6066.xml"/>

<!--I-D.draft-ietf-acme-star-delegation-01; IESG state I-D Exists -->
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-acme-star-delegation.xml"/>

<!--I-D.draft-nir-saag-star; IESG state Expired -->
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.nir-saag-star.xml"/>

        <reference anchor="Stark" target="http://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-prefetch.html"> anchor="STARK" target="https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-prefetch.html">
          <front>
            <title>The case for prefetching and prevalidating TLS server certificates</title>
            <author initials="E." surname="Stark" fullname="Emily Stark">
              <organization>Google</organization>
            </author>
            <author initials="L." initials="L.S." surname="Huang" fullname="Lin-Shung Huang">
              <organization>Carnegie Mellon University</organization>
            </author>
            <author initials="D." surname="Israni" fullname="Dinesh Israni">
              <organization>Carnegie Mellon University</organization>
            </author>
            <author initials="C." surname="Jackson" fullname="Collin Jackson">
              <organization>Carnegie Mellon University</organization>
            </author>
            <author initials="D." surname="Boneh" fullname="Dan Boneh">
              <organization>Stanford University</organization>
            </author>
            <date month="February" year="2012"/>
          </front>
        </reference>

        <reference anchor="Acer" anchor="ACER" target="https://acmccs.github.io/papers/p1407-acerA.pdf">
          <front>
            <title>Where the Wild Warnings Are: Root Causes of Chrome HTTPS Certificate Errors</title>
            <seriesInfo name="DOI" value="10.1145/3133956.3134007"/>
            <author initials="M.E." surname="Acer" fullname="Mustafa Emre Acer">
              <organization>Google</organization>
            </author>
            <author initials="E." surname="Stark" fullname="Emily Stark">
              <organization>Google</organization>
            </author>
            <author initials="A.P." surname="Felt" fullname="Adrienne Porter Felt">
              <organization>Google</organization>
            </author>
            <author initials="S." surname="Fahl" fullname="Sascha Fahl">
              <organization>Leibniz University Hannover</organization>
            </author>
            <author initials="R." surname="Bhargava" fullname="Radhika Bhargava">
              <organization>Purdue University</organization>
            </author>
            <author initials="B." surname="Dev" fullname="Bhanu Dev">
              <organization>International Institute of Information Technology Hyderabad</organization>
            </author>
            <author initials="M." surname="Braithwaite" fullname="Matt Braithwaite">
              <organization>Google</organization>
            </author>
            <author initials="R." surname="Sleevi" fullname="Ryan Sleevi">
              <organization>Google</organization>
            </author>
            <author initials="P." surname="Tabriz" fullname="Parisa Tabriz">
              <organization>Google</organization>
            </author>
            <date month="October" year="2017"/>
          </front>
  <seriesInfo name="DOI" value="10.1145/3133956.3134007"/>
        </reference>

        <reference anchor="Topalovic" target="http://www.ieee-security.org/TC/W2SP/2012/papers/w2sp12-final9.pdf"> anchor="TOPALOVIC" target="https://www.ieee-security.org/TC/W2SP/2012/papers/w2sp12-final9.pdf">
          <front>
            <title>Towards Short-Lived Certificates</title>
            <author initials="E." surname="Topalovic" fullname="Emin Topalovic">
              <organization>Stanford University</organization>
            </author>
            <author initials="B." surname="Saeta" fullname="Brennan Saeta">
              <organization>Stanford University</organization>
            </author>
            <author initials="L." initials="L.S." surname="Huang" fullname="Lin-Shung Huang">
              <organization>Carnegie Mellon University</organization>
            </author>
            <author initials="C." surname="Jackson" fullname="Colling Jackson">
              <organization>Carnegie Mellon University</organization>
            </author>
            <author initials="D." surname="Boneh" fullname="Dan Boneh">
              <organization>Stanford University</organization>
            </author>
            <date year="2012"/>
          </front>
        </reference>

        <reference anchor="OBrien" anchor="OBRIEN" target="https://github.com/chromium/ct-policy">
          <front>
            <title>Chromium Certificate Transparency Log Policy</title>
            <author initials="D." surname="O'Brien" fullname="Devon O'Brien">
              <organization>Google</organization>
            </author>
            <author initials="R." surname="Sleevi" fullname="Ryan Sleevi">
              <organization>Google</organization>
            </author>
            <date month="April" year="2017"/>
          </front>
        </reference>

   <reference anchor="W3C.WD-capability-urls-20140218"
           target='http://www.w3.org/TR/2014/WD-capability-urls-20140218'> anchor="W3C.CAPABILITY-URLS" target="https://www.w3.org/TR/2014/WD-capability-urls-20140218">
          <front>
            <title>Good Practices for Capability URLs</title>
            <author initials='J.' surname='Tennison' fullname='Jeni Tennison'>
    <organization /> initials="J." surname="Tennison" fullname="Jeni Tennison">
              <organization/>
            </author>
            <date month='February' day='18' year='2014' /> month="February"  year="2014"/>
          </front>

<seriesInfo name='World Wide Web Consortium WD' value='WD-capability-urls-20140218' />
<format type='HTML' target='http://www.w3.org/TR/2014/WD-capability-urls-20140218' />
            <refcontent>W3C First Public Working Draft</refcontent>
<refcontent>Latest version available at &lt;https://www.w3.org/TR/capability-urls/&gt;
</refcontent>
        </reference>
      </references>
    </references>

    <section anchor="document-history" title="Document History">

<t>[[Note to RFC Editor: please remove before publication.]]</t>

<section anchor="draft-ietf-acme-star-11" title="draft-ietf-acme-star-11">

<t><list style="symbols">
  <t>One more nit re: random URL</t>
</list></t>

</section>
<section anchor="draft-ietf-acme-star-10" title="draft-ietf-acme-star-10">

<t>IESG processing:</t>

<t><list style="symbols">
  <t>More clarity on IANA registration (Alexey);</t>
  <t>HTTP header requirements adjustments (Adam);</t>
  <t>Misc editorial (Ben)</t>
</list></t>

</section>
<section anchor="draft-ietf-acme-star-09" title="draft-ietf-acme-star-09">

<t>Richard and Ryan’s review resulted in anchor="acknowledgments" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>This work is partially supported by the following updates:</t>

<t><list style="symbols">
  <t>STAR Order and Directory Meta attributes renamed slightly and grouped European Commission under two brand new “auto-renewal” objects;</t>
  <t>IANA registration updated accordingly (note that two new registries have been added as a consequence);</t>
  <t>Unbounded pre-dating of certificates removed so that STAR certs are never issued with their notBefore in the past;</t>
  <t>Changed “recurrent” to “autoRenewal” in error codes;</t>
  <t>Changed “recurrent” to “auto-renewal” in reference to Orders;</t>
  <t>Added operational considerations for HTTP caches.</t>
</list></t>

</section>
<section anchor="draft-ietf-acme-star-08" title="draft-ietf-acme-star-08">

<t><list style="symbols">
  <t>Improved text on interaction with CT Logs, responding to Mehmet Ersue’s review.</t>
</list></t>

</section>
<section anchor="draft-ietf-acme-star-07" title="draft-ietf-acme-star-07">

<t><list style="symbols">
  <t>Changed the HTTP headers names and clarified the IANA registration, following feedback
from the IANA expert reviewer</t>
</list></t>

</section>
<section anchor="draft-ietf-acme-star-06" title="draft-ietf-acme-star-06">

<t><list style="symbols">
  <t>Roman’s AD review</t>
</list></t>

</section>
<section anchor="draft-ietf-acme-star-05" title="draft-ietf-acme-star-05">

<t><list style="symbols">
  <t>EKR’s AD review</t>
  <t>A detailed example of the timing of certificate issuance
      Horizon 2020 grant agreement no. 688421 Measurement and predating</t>
  <t>Added an explicit client-side parameter for predating</t>
  <t>Security considerations around unauthenticated GET</t>
</list></t>

</section>
<section anchor="draft-ietf-acme-star-04" title="draft-ietf-acme-star-04">

<t><list style="symbols">
  <t>WG last call comments by Sean Turner</t>
  <t>revokeCert interface handling</t>
  <t>Allow negotiating plain-GET for certs</t>
  <t>In STAR Orders, use star-certificate instead of certificate</t>
</list></t>

</section>
<section anchor="draft-ietf-acme-star-03" title="draft-ietf-acme-star-03">

<t><list style="symbols">
  <t>Clock skew considerations</t>
  <t>Recommendations Architecture for “short” in the Web use case</t>
  <t>CT log considerations</t>
</list></t>

</section>
<section anchor="draft-ietf-acme-star-02" title="draft-ietf-acme-star-02">

<t><list style="symbols">
  <t>Discovery of STAR capabilities via the directory object</t>
  <t>Use the more generic term Identifier Owner (IdO) instead of Domain Name Owner (DNO)</t>
  <t>More precision about what goes in the order</t>
  <t>Detail server side behavior on cancellation</t>
</list></t>

</section>
<section anchor="draft-ietf-acme-star-01" title="draft-ietf-acme-star-01">

<t><list style="symbols">
  <t>Generalized the introduction, separating out the specifics of CDNs.</t>
  <t>Clean out LURK-specific text.</t>
  <t>Using
      a POST Middleboxed Internet (MAMI). This support does not imply
      endorsement.</t>
      <t>Thanks to ensure cancellation is authenticated.</t>
  <t>First and last date of recurrent cert, as absolute dates. Validity of certs in seconds.</t>
  <t>Use RFC7807 “Problem Details” in error responses.</t>
  <t>Add IANA considerations.</t>
  <t>Changed the document’s title.</t>
</list></t>

</section>
<section anchor="draft-ietf-acme-star-00" title="draft-ietf-acme-star-00">

<t><list style="symbols">
  <t>Initial working group version.</t>
  <t>Removed the STAR interface, the protocol between NDC and DNO. What remains is only
the extended ACME protocol.</t>
</list></t>

</section>
<section anchor="draft-sheffer-acme-star-02" title="draft-sheffer-acme-star-02">

<t><list style="symbols">
  <t>Using a more generic term <contact fullname="Ben Kaduk"/>, <contact fullname="Richard
      Barnes"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Jon
      Peterson"/>, <contact fullname="Eric Rescorla"/>, <contact
      fullname="Ryan Sleevi"/>, <contact fullname="Sean Turner"/>, <contact
      fullname="Alexey Melnikov"/>, <contact fullname="Adam Roach"/>, <contact
      fullname="Martin Thomson"/>, and <contact fullname="Mehmet Ersue"/> for the delegation client, NDC.</t>
  <t>Added an additional use case: public cloud services.</t>
  <t>More detail on ACME authorization.</t>
</list></t>

</section>
<section anchor="draft-sheffer-acme-star-01" title="draft-sheffer-acme-star-01">

<t><list style="symbols">
  <t>A terminology section.</t>
  <t>Some cleanup.</t>
</list></t>

</section>
<section anchor="draft-sheffer-acme-star-00" title="draft-sheffer-acme-star-00">

<t><list style="symbols">
  <t>Renamed draft to prevent confusion with other work in helpful comments and
      discussions that have shaped this space.</t>
  <t>Added an initial STAR protocol: a REST API.</t>
  <t>Discussion of CDNI use cases.</t>
</list></t>

</section>
<section anchor="draft-sheffer-acme-star-lurk-00" title="draft-sheffer-acme-star-lurk-00">

<t><list style="symbols">
  <t>Initial version.</t>
</list></t>

</section> document.</t>
    </section>
  </back>

<!-- ##markdown-source:
H4sIAESpsV0AA+19e3PjxpXv//gUWKa2LMUk9ZqHLSd7lyNpPIpHo1lJziTx
ulIg0SQRgQAXAKWhZ2Y/Sz5LPtme3zmnGw0QlMbebO69VatyeSQS6Mfp8371
YDAIqqRKzXF4vVou86IKp3kRXs/pt8GNKRb9cLSq8kVUJZMoTdeDK5OZexOH
O9c3o6vd8MQUVTKl7ypThklmH6YHvG/CiyiLZmZhsio8y+6SIs/4953RycXZ
bhCNx4W5Ow7xV4hhgzifZNGC1hQX0bQaJKaaDqLJwgzKKioGBwcBRp3lxfo4
LKs4CJJlcRxWxaqsDvf3v94/DKLCRLQjM1kVSbUO7vPidlbkq6VO8o7+TrJZ
+C0+C27Nmh6Ij8PzrDJFZqrBKaYNApoti/8cpXlGS1mbMlgmx0EYFtOJictq
neqnYVjlE+/XJItpd/aDkiBZmGnp/l4vGn9WRTJxD0/yBSDjvk2yNMnqacz7
apAmZTWgQcZ5So/lg19/Ke8to3qYcjVufBJEq4pOlBY/oG8xLL36xyEds5lO
TcGfCcD/GNHhND7Pi1mUJT8RAuQZg2iVVPyFWURJSuPjjekQZ/SvM3w0pKkb
E50Ow9f50vzkTXOa0PF5nzYnuTGpmeYZ4U54/uWpP1mM94bFMMWb/1q55zBn
2Jj0chh+m2c/Ran5KYwNTZiX3vyX5SQquh/43KXkGGI40yFiE9MArRU1FjQa
hm+jsiLiemsKesVfziir6KU8HM0IhYmKOh783GVFMtRwyUMsZYSH1nUzDF/m
ZUkDewu6mRMVl40vmgsYXV34s1b8/HAqz/9rVCx4niDLC7COOwO6uXp5cnhw
8LX+enR0ZH99fnh0YH/9av+5/vrV06dPj4m2s2lrkOdfPzm0vz47OsKv54PT
YSlI6zGKwvzHypSVfaDFRmKCyUy2ow9kSTEoo2jG3+PDa/r39pg3OqBNRvwb
fTYzRFjzqloe7+1NivWyyofgFbTQeGji1d5/xtE431uuxuVeNCYKJ0Is98oy
HSyJ9E01mQ/n1SKV0YT59m7mJpxEpWH2ax8DjyIWhL/vojSJabX0yc3r67A0
xZ0pwonHfns8nqN0/hnov3rWZ0PZkvtUTvtskaTr1jd03MdEIPksNd1jvR6G
r1ZRNmuN9TrJBtfzFS2z+S2PdxIRe50lJBBMSlw1/D6jUy1KsOjOOYhznJcF
oV1rklNiiuW8/d0vmuJkGP4umtyWedaa4yRPifdufPlL9/GChMi8vY0oa33O
o18rKrWHpeOnlw73Dw7pzxEd/UOYWRJqEq5PJuVwllTz1XiYEEZGxBDKveXB
k/3nRAmmGA2X8bSBh+/mpjBEzyZ8l6Rx+I52SjhXhqOCvr3K84o2vypJ2OfT
8GRe5AsTvrq5eXvdkPdnRZEXipCEqYkpQcUWKU8vz4/Dg/3hwcGTp3tHB8QH
nj4b0r9P9vefP47DF0OgMbbfguYF8c5oGhE20wYa3z+Ky39PugCfJ5Zq0qo1
2igmQGSZCd+SRkC023jk0WGvacxonrbGvI7KyTxqfsNDvTbJmLi1h0LhqyjL
8jsHltb4V4Sic8Kf6C5qzXEVxfPkNtr8mid6uyrilXmUAl4Mw1Nz1xqZRsxW
jc95SFHDmDNHKf1FIrFaEVYRxp1bYUBEd2Mm8yxP8xltbR2ToBtH8VaUeVFE
RAX39D/TRpuoqjq/fvRICGTXqTF3be50tSa6bn3z6GCEMzfRuEh+ag32NiqS
Mmp/1x7OsQYQ0E2+JJ31Lpk8Irnu7+9JJhoSh6onD2nYvZuTvXeH12/3wGcs
w7g/LJcHh4NpQgfydZtl3OT3URGXajO8JjxoKP/lZ4klt+ZNEsw6vnyQT3Yh
33VkqjZivyiIHHFUje9+3tD/CCn4iIia/T8roy5fgOM9JqVUPJG+uDeBQElW
9Es1WOZpMln7iHai3zZEzQ2pAOWS7L1ssiaDYkbc1b33INLRfi+/4AW2d2zu
CFzt7/5HuYFHvsFgMAit0hgEb1dj2s6ATNSGrhdmhqisysOxCUk3zG/pr/u5
ySC41yFBgy1CgKs0cZ8+jaowKfvumTAqSzJU2VBfFskdIIk5kjI075c5vRTQ
4LTwVSZATH6iJ8kyBZcIXuX3BtonBsLsE2HINN/ElCUGyaeVwcuFSZNonBoS
2FkYpcrX7wyW7r2Z4KVyxeouKQyktWcTExC/9/fcD000mYf3hC54CtwmZK0Y
wo3YVJLTTqEt0yzENURXruY0th0xXC1pshoyw+AGXy/MIsfise8Sm2YfAdna
JiuxOlqrybAL3jAWGmEwWh4vYoD5eOLI95TQ/nxPSfCH4dP9rxsbGgbBD2TD
hGe0A0LTcJkaGAAFLYcgNCaDjc5xyQjAYPoxCN7NE10Ge0YAuLHBPmM6EBjF
fNgmNDzkF2XItIlN07bGMC5WWGcVdBCfGPJ7ZAjtVYUxe2TQ0c72sPqhoOUi
iWPC2OBXENFFHq8mWFYQwHZhmBEQq3ySp+GHD2rAffpkoUKgxcoskhD06iP3
oAJoR0w6Ft+CHVr7OVwq9Ahh3eV9Rv8nK+k8vtwlybFeCsD74XhVhRlpqFF6
H61LgURSv0jAisKY1kIiBRPQrs6n/BCNRHhFBmSJ6fNxhUci9s3Q+poH3SBD
IoyZRbUpIRWPVtLYDaraKY0hkDgxBqCMc1rs/Xwdrkq8LBOkLDwbMyyS2bzC
0bFNWAga5qBSQouk8qhot0+jmHBBanA4y2klRb6azXlF9/M8bR8RE1OV0FIJ
3OZ+yxYBNPAaWhYhgBnOhkSGhFTr8HBwRHxrTVhMQIxJQgitEeT7jYO+z1dk
RyTZXZ4SVk/ZJs8Ic6HkRYxAwOHq3ihnKkhogfsxY5iuMn4EZ1BZLKvZP74Z
CX8iHrBzMtoVBuDOHZyhIJDHOP5sWhBKF4S1KyKsHWyGuP2ba2KLZqwWdbnL
qy+E+BbRrTCRrWTfOCvzfkKgojeI+mOzNOwHDHO7L7DCJMWaaIxxXs2HgTCg
OJ+s2CFKZ1zC/QcmVPMff+/u+Jil50s6QGLNpcDegny8tivfttJpUhCWTNII
lDj+i5lU7L1105hJXq6J/BfD4BKbxheXBaAI98TnUAaIbTIxy8qypJMRPqMN
Eg8uE6AxezrA3sq5hXJGu26gH22SYBHNCsg7Zt/fX722vFHQjARrvqJtEAYS
VSQ0w5B0YKVq8D0rD+QFx6SFQZOF4Y1GGlNeiViMTRTD+doPk+kGCdA6WCR7
oiR4yZBZYKgZjVzQDMRHo4pPliAFRtoSaPQ1wbRkgc3kXYhU//Bhwx316RNN
8atf/Sp8A+5y6nxX4fckMk5IbggbVjEWk1AjwzBLyoVl/St8GoEFjldk2QPi
4zSf3GJpQLcprYoUnioAa/ScYw7l+nxg5n20IEEVCsHT8Zj3RK41CUfhyemb
kEExSfNVHDj6A2Um9OSEGFS+wLZlm1vdcrTlMBwBAdbMqPoBc1ei04RQ0g4T
7iRDM+xbPr7bceTeZog0yoQ2sA5IaWNeYFGP8JMgT2Mut6AJ1p+ayr1ANhN9
VdFQYGPE23y8FUwU6iBuwCyFBLYp6BTf5JXCTkkOEPcXSUclvkBv8U4cMi6y
nAJ9lWVgVzuwCoe/DmhLkDSiJdB8hB2k5WzwFRqLVIMKsRBZ2j2hCqMMDj3J
ElCF3TljsmWITGxE2aS8yLLwBBgTrPcAW6F5RI3EBia8lW/PbmTzwrWEpe18
+OAtfUBGwgD0+OnTLqN+eMOHyhY/Se74MjjeUAsEDXLREBiva/nfD4XjN3QA
0hhDOMeXcyB0tlqM+Yg4CnXshcH49BuRsNBGwjoVO1ruSZ7dYW4IOIak3bBl
90KxgDjCT2XYu/j++qbXl3/DN5f8+9XZv31/fnV2it+vX41ev3a/BPrE9avL
71+f1r/Vb55cXlycvTmVl+nTsPFR0LsY/bEnKnPv8u3N+eWb0evexiqZOYml
wTKbGG7FnCSITTkpkrHs7MXJ27/99eAJ0fQ/qZ+ftBz546uD50/oD9geMlue
EfjkT9grQbRcmghYRppbSpi/TKooJfZIKEgEdJ+FoB4CKimeby2yvEzzewHg
lKzg/J6l3WpcGlUp7OIYIUgXMpDmwP95pN5LVVJ4uGNScMnMzStoHstjpxRG
5W1tEQiHmICnG2uBbFH+B03lv0GShOY87WBs5yMM/4bmHzkijtJjT90ZqXXj
7IoBaE/16S1qG0cNcjBm0hGVKJm9+g9BlLrVRN7suqAba0gh4mNBokGVsrFA
miFOyklO6J6ttslZhXknLKp6Kkfv7jyCD8fhr9owk8OnFfWBOBAsBZRcSLgs
4HVNUsizfnPFslgGIJ1hWybTWCxMrHRjvHjFUrNpcPZVETh8guGeH4bEZQtS
PGrezmbYexINhIpTZqDCcns8UE8VxNKqh5bnA+7n5RZTcry2exA1DCtnpGb8
YACTnNQhYqKcNI9iNhnYOInCnTmZEzRgdBclKb7YDVM1HwjmlxBTWH3GW+h3
qJ1TIrUyZNmwYtVJpD7TCqHcyYjMAVpPRBCdrNKImC6+6lD8ECcsp2srUvSM
aI9ydHPat8lmhOQklZLU0yDvE3F6uVNsvu4d5jB4S9vhEGTqtgGRSa87fQFD
zkh6k2oQkTJEWxc9l9ZLJzppeErY9eAEYMtotSoWHQfzoQ0zp36dNrIj6JNM
gzZJOPEO3mXVmHi4K/ju8F8YWcgo5Lw6lhxXy9gZ3K3tAGzZJF3FAjiwAByH
NXFoA+3NCTFeGTLdyrlHig2GIavjE3KsSbSGtMmXoANZ/sB+JVF5oEmTckVv
litWa6YrQnxCJiakbIMefBbojy/WtLPCT66vwh1CzKC26dx3nmeAuSU7WiCO
dx+zL/r1C/AZBDWLBTid+kSCclVkotE7gaKMIYstO2yd6JAB2dwSdJf7eUL2
+oSNacIMkyitKhJXpUmnonbXCiPJ8YIUcCLGNQvThsB+VPnuqyOEgRy0uLYN
T/vypCTOzZDh+GBSDQUpCsEcZ53i7WTGOKRf4b1ZbpgXCrnL9pj7YnvW2wFN
2pJEuUXKbBEp3xBwVMY2n7c2YxD8p/uBU9Z3Mvs/oDF2iuEhMr6KsOPnmp0J
eOIj/31lyGA2aiPwJx+7Xgt/GA6HP/Jrg86ff+l+LfxYT7X586W8O2x+uvfQ
Kx8b/3zeG5ugPf7ZU/z7g2/8hvfxRfPTf//5UFZwfQ6IO93Mn7Gt7hm3vPO/
B7Qx0v8e0P+VA9o6ycbHzXeYbz38jrA2j8dCk2gJAon0/bYHQFgY9D4FnvXP
7NxTQnwm7ywCsvTWViUMybL0xIbn99hQ4uAbIsGsIQn4NtJU3rBjqSBvqlRd
otXqyyRQSYSm5UCGo6Hhxxs5JYgUpsJMDOmfJUtOEhrQSEpfqe3DhCuhELM8
POGRtgg/K2OtStfeI0yDE9LvZ2ZDc/ICTQ1tUbQYdhEiq4f2F/NjqmZ1ANZ6
hlqTkYJRrZzlLTCk8XsCGhP3mq4xDm4hmpMZbCkq1n7cg5VAxD0fMII/W6Rv
+/ksUQ986/ppqwCbP1s//4yXFAsEio++9OU2TvpLlmcHG/6ivdl/f+HLZ+pp
cRgf/sKBriTKyoKI6PL2Fw5DavA/Ag6nsD7qz4WND774DF6/8fPl3x0lt/10
vbSpAXS9tAVft/104jHnIB4zslwJrpwoo2ksbwuUtv08CL3tgNgi9phjqczz
5BtEnufqPBUZUks9T7B80hCi+j2dHHLBdhlCn+6zz1viEXWAsQxUrjVdPRA/
iQakxNOyEcES1wC/dlaPJiuqA834Ji43Z+hzEAPOW3Fndbq8mMOVGvviSWIr
eoT5XamsYvCwEZvj8wFNqxpBywPCOS4Yx3p0JP7d8/0ZPY2Kiixif7yE4BGe
lQqZDVhI0LF7GLLsecmer9oGolmoY93VIGbj2sZO+hpl3RXfK/SYBEoIP0VS
1Om8KlE1ptuI3cOh0w9YJdGU+0+fQkmhpPW+g2clXySVC9LyOmSGhN18ZU5I
FZUtbw19Zx02Q1o9wVLXbnGmtfYUANq+8jT6WQunGdNkajh3wZsRrraZKXTK
RfQ+WawWbcsAU3Lmw6bnF8EiGUJOPTakfUAv07AQR7vNJCdctjEvzijJctBt
iplWRv00MbwZUF6srw0xTMK6IqoXxOtH7izCjpLOT3glTuswiv+yKiV0zNkj
Y0N4s+tvfSCP+PhSQyBaIJrH7ubUTKtwGcU9GjMWav47AQCxyWm0SllT26eP
zqeWRASbBCJ6yDTWC3GrkYKbxuomY39WDmfPfVISmFwkqEt7ZYDTDIxszhte
Ls0ESnPcucxrAl6Uloip56iGEVgN6GtSyhH/LgWxOBcnsuCXrJv7KGOdf1Vq
cgsCHEUuoeAPH0ACKyjCAxSecAyY3WEDe0Q68pwYHFOwfaqB6w6VlahW8PYK
eAV+ZBul9J63YUYWcM+ZYS+gcyw3AO4GjiqixfEKR+znAuhoFuFwzvNENkz7
JBGFLBnEVZaaZorBCqAg82zf84dYrY+I4zxPTZQRIkrmU3dYV/yDpbdAyYRQ
mmFTKgrfXhLzXcACmBnxdHMEriEE2ASDn9PuvbeM1oh99Ig3TXKMJYyYvatr
zbdQ76zznoucAKseGzuNsTmFVngppV6M/qg0iq8W8OsiMNHnQHoR2wAFQQ/x
lTSUbFahZUXHSbTUfKABx86QVSWxrxsvgu7RDdZBf4n1yERUSmxJQHWtKsDz
4cHwCIDwk/BsSNkXYwxepjHe+VCz4daNQ+h7KCejtA1Cxj417gDr8Mn+fth7
EcXBlRiwPYHgeknnsohScHET2+8QbPcW/qy9cNlgW3oyotdmblPCf1Hqco4J
D0RfQAAcyTZr/FJHgfAX82MbBk8y+ZOjWEwdkSQw+FJddRInMbFxqyLocMDH
NIcjoezgYoCvJmSwoIMoNmDPNhVPxuRNHnsGcl/J6WHvQjDadG0knBTmBSKj
MF6TLsiuA+vGkNAn5xROkZ4jGcCadcLs+i5CLU+Yc/IvcQPw/KysCLCAET4G
0bkIjFlEyPhwNn/PW1LPZ0vNhAN75AIM91jYawewe824m1tIY56h1a8aoe8u
LSscNcJhO4Xwvd2OcB+A4RiFxs2SzAY5jTiKaE9KWKK9nthT4oyCDYTq1O+9
o6WDpbkWqNGOOFcQ8qxWojYxFKdufSnK+C0qWebP4XMm4CyXnHLs3t9qnV+K
Ig0dwOe8jjOqIClZ2Ve+3XCYAbgupYNVOxIybn84ItbcGYfFY8NjoIzN7PFX
e/lsWnx1RvAhToays72D4QE99yovq2ObmoYqFvrshGQ1rWdwQ3znGIqF9W7t
/SUvzZd/QcEEPfaBE/DBEyoWsr3jcEw0/+zJqkh3PmjGfi9KZ/RF7+z68Omz
Xt9+epvg8Z7NpbbzI5ma10yyoNqb3e8/+/7N/Lvp5Z2pX81y2jZeHqWT/f3R
8tlV9fzbi9uz9Oj1we/+8LR+kJbx4BwbcJGqu0+7fd2YCsLObQmj6fk8pvl2
mczIJCVFAM/Mnjx9Yo7m8Yv09ubJ6Ox+OBxm35m32ffrP9385dvqD3969gqv
fwo8M3fzeK29+wg1wAYWSRd5IeGGW3ZTNEHAaWoH6dvEUBMVos3kVyZwjzrf
NTUAKGIKDn8KNtR4Ggmvb3Vq+t7TGrAsYPj10khS6xIkXCC1IOxpFLLHNtI3
diLhJ2qmPtk/Cnde5sU4IT0+2xX27Pzc5dYsH6LHZU6KnSqVjkdptpjmZwYe
tBKvyk4C6hEeG6ek6DguzUIa5dpI7WIFlAU8qQbHCCofkzoWLcpjIOkxKwrH
Ha4YcOfzugzA97mzS8BmY2gBi5pUTsoC+sZ+zlopC9OR5UUOKcCUgEYw9p1b
nbO2HlRtHKw6dZwd0nFC1WN2PR3n54BANnvu1A7W/WRbiwgRdtMMLTyoK/me
DWK0pI+uOJPeRiWIHtU5wjMMKtRO8aGX7C75FO5cV66oSr7gc5BDuJRE8V3H
nsNQ1auww0kWdjvKPtbfjdKU/Qo/dXxnT3jzvd9vHZMVvLDLYff4Wq4kCtP5
HZc9Jj+Zru9sZOjz11lrn+EvWOdLdvJ0fzdphzc+ihMUmQ/uIVVWvAFsBYX6
dqakdhDDf2Abv5fv+IQaX6j27CarZ7VBFPnLi8N4q1eW4CbmX9ynvlB5EImD
4MzWxnTrMV6OkISQsBxJ1JpGxLV3ahprU9iu5TWl9MpRfanLFziyjEXie8Lg
vEVYxJFEvg0N82ezo6Zs+LnM6Mot7E1eXdvN9TSR2Rmq4ak1VPkoOi3YAKZT
bqN7CijJZLfP1NUQdoDEqDnVW5De21MXEan0kEzyLsGxyvGueFQ7DN+vh5sn
1uHtDbZ6ex904badwAmL/EBPWfcp1h7MoqqsXbzqSxXztWQ9YpFkg4edmPQE
OzClioaTOMW9Y33lTl+y43AirPV8YY7o/SBeaSVV9xzqJI1NWkWNKqzGBM6/
C7SqXdXt+f5+bqFR5upMNg4+iu/wGtMwI5FFMT5dxMniaN2Er+Scm3AN36IP
FdEBdAAM6JOg68AiaJOxwSGVC20jBjChhXqWi6rYPQLgwOn6W5X4+qm+957W
ZDz6pn3Of5cJ8NE35anGnJDHj8/IT9n3hIvywT/4pv+cfffWrAcTzhF48FXv
MfsmM4pjC2j6AMG0cpBPB1oh9OCA/DB6HDwfPB0c7Tt7K+zdmzGJk8bbaJTg
j+A9PYmigZYaEg+jl37oeU/2fqyfbDAVb93Yioes9NVXz0i77PvfeyhL34dH
B0+Pnu03n+kkvh53RXNC9lPg/mkYaYq+1jI7bZMcE4BPaxyg/FX40lIIp7L4
LR944M4U0WAjv5WoiR+FMHUltNuMGFkL/AKDqBwQMQbw/BID9nl+LcCfDA/7
4SpLkRNjHd2geGHa8+iOGLiXb+zX/7E06qhb6qlrtqGXB1uZGTxkYnnAldj3
Xe7wyUgxmqtHAHep8qATBM6stDVd3tLYlyg5wNYMlC1GZdBlBsi+aJmYBZN4
rAtrECLBF3uz54ujP/2buTn7j+gxl8uIRVXT2bI0iwZWEhUn7HixY4WHZEpd
fvegx6Z7kBBtNm6Pw99spfIyRymjRed/+aYw6W97aM/3Ho4KYOyA9J2B+NfR
9WzVD4/CS0J54gxfh/v7x/xf+O3Fjf88+yX08YP9Lc/TC6zYvzj79vxNeHJ2
dXP+8vxkdHPGn9K3P5yRWFXvqn/OEwFD+aMd4ezNadf7j4wOs7rZIezvNbKU
ifz8gT2Os4F/lvc4ltKhEzPpd1GkMhXJuLJ+Db/Kodc6anHG9JoH2hMBP+ea
XBtfSWzxtmjeQ+crWkvhq1SwOeWQdCzSl5QE8ZIG/NxoUGhtBUDH4Q+hgCaF
RrrBGntYFKtbPckz7Iz3HAwPneKLbnogZxlpuSpQEMy+YNfHQhkQeA935YzE
1Jeob84WDpkL5UaSIFc52xgMohjTVSHIkEaFK8lH5cMskiDYisN24h6j8RrA
laid5d2ybOxqGH41PKItBewgWII/ws+f0+nL+0gH+bVE4P0BJRwPxdDqyn1x
DIXomTnkV8zGGxw84IpEz4HPwCLU6oevzkanjC2ezHE+N6+cEVr5xfnFGZtd
AspAAuheZUkreebX4St/MXW8RAJwXguBqZDY+627wD7n+XIwXg/oHzzFXbQW
Jk4kZoOAJaEfSI1WijoP9WAyoL7BC1ObAaCvrfWFsn6Ow0OM7CYrV4VX6kZ6
TbrWFAOxUwiBJ3NbopMX6st00TtLWg302r4531sqNvPvsUJ+Ztt76hFkxkGz
2SAyycIkZSz6vOn0dbKdWJJ0v+dlfEhrFOP7n22HLRwjWIDocuWQ7EQ2i1Nu
PSNNR5gqhQX4ntjA+kCjVBxdrobPZytNYr3JQeMFEh2LfExaQEYg6Ot5tTot
WBa2iJCu4sbWQJGtLNPT/v7qdcD6mISSOiJz+qBm/syjdHofYai6KYkzz2xd
qK2nDzfr6bkQDMV/pHwiVqXhf54EXICrPpmf2RTmJHOxW9+tfIwvpjRBv1Y2
sYigEyZoDtQAh+pvvp9aEcbmQ9Hy6zyPunaxh7F7/uABpwG46iM6quguT+JG
TsZkwrYFJ8QZEKZIxnFBdlQmbuJ+K7nGhlo35nMHXJoqKPOaclsbtugl7j1O
jpBcbFvvFtuz7Th1wgvSeJtFsKKJBpJSY/tWkXQujG1x0OnNsPlNwizgSpKK
UYtWFfvW2KcBETbU/hsSN+X+HVDPl35iup2ihLGx4thTms+SiY2rf0ZCj0xj
xZ5NJzK2iteFUGXxrlWEB+K6glgm3ZqVZIMBW+NbDwS1bExXk0UaVZebfh1t
XiK4GDfTGxrRkX9YNCr8h0ajzmTjvXb5dmdaCTfo4rLIOnVE1Bi8giCrS3AV
9+kbtSk11NmhwIoztcN+DFveVK8NWbtnCFqcozjb0xCDR0s8sfJ7Ay2r3CDK
Vr8i+DpZI3etgWxbK1FT9FFNedPshd2tqR1B3Z+Gwc2iuqzDcUAndfQZ5+Fj
wppo9CTYaiCX4V0SdbYc2YGEVcxC0rOn0+3aeKDyXh/anF8tXWcYt+iwB5Ky
MSuiDGXu3BYvuJZMRO1G5vbCWFNyMpgKEoEqTYH3q42l2sYuuVvOF5auNzbN
RUt1U5pON1BQ59CALIta+WqwA/X2KLOEf63hh2cUaPuG2Jn9Mxy/nGIGj49V
tqw7XdwyaIirS2zwH0UPPkM8Ca18t8FsuppblJwMZfNS6lMg0ZBIUxOBNM+k
gbGNcQiXgi5cGkuCgRB1NwSaYCfoPQBuzdPgvngVeq7dW+4jcSKFj3p62ElE
QBr+D4NfYdfooOFRKOfudxIaau5DPaZtomCzs4KXk6Gd+ez5s2dpsyxO5RIn
yApCO5A7YDkLfpXyBwJXmw/qlZwZdIFw2aAPdC5ymV/Sl8zH1IBXxKqdQKfL
bNwKEcvBbAMhVUe25YDaMNqG6/VxRSYI3hnlxkhGkgx2i5nO28CIyW5XQBG6
OoOn3TCw0RxAjDNpqVEnlwLX4pXRyNiElOpMSjGicIFz4ZZiImX4+S/Kbq1Q
TopjUGWd9+w356tsKUTwQGsc2P1LsPExGmLW+XBdcwd1eQP7TrMiljRdmwRx
I971gbfdbcvn55GL8sjzdkp+nib8IfmRnu86J1d0Oag2c/qDoI4Q2J/hgBbM
pcydv/35z8ONd/b033/f9pvJJGzv5TPkj//2B/3jX8KqNSV2vP+j/e3A/Xbo
fjv60Xcn0ifWgfhGYaSqXXgKXFYHYbFKxbND6glXW5mW8dSgLs0xbsO3gexw
1DQiuxYn3CjhbxGL3NEz/DK86QNau/Yhnfi39SEvovc7Yj382TYw0j+Fw+zy
HIH06e81nuxJxqfBjNujuZ0GVrDTS6MeKUFWapDFCbUrTdqVAnU+fDeB5tOA
60u2UN9O76a3+41buOzJLbyuW1mKcA3Eo+R7IWr5s4huoRxaNxQ3D/NtIsmx
9uzWwgRi1qqCb90PXu2z2iU6ia5CGNXUNvKZ4p2bQBsPTsNfE/UwLxo+DX/z
W/rgN+GBNe+2NUrxcKVxhoovhCZptOt/rSv6rcwnSNA0Vxr1CXXmW9XtIZBy
sQ2MZqWTGcuySPLCiqrGWdcpAK4ujwMvQfAts/1ai5cmh1r/l9ujqB1QGz5+
dRQFDzmK/JY8Vmv3JI2TCq5coNZ/fRLdHpLt1RtEGBixncH+weBg/8ZGeP7k
hYAtr/YfPex+1AvyHj15+mx/v+8x2b3wCTfU3XhaCZVeOnz6NaJl8vSR97SE
c5nJ1SRUy0u/p1S5GnNvcRtuZWJtSZbAVgDKHOh7KrgO5gT0tKuXBRHbkA8I
M4dPbQXLdqXlIf4QcUXkR+/tj/W7HwO/J4j3O30Rdh1T6H38xP/Yf/6g+/mv
tj3/tPP5w8a0AoItBXDsZSvzmgWheojrBj2dm+CD2jjzHjEkdU/edzQdq121
j0fPQa7hZe1wQsjVc0dLn405rgyIMu3v2+MemCGqk3uO85/z3WKsf95yle4J
+6xYHG/xZ8GV0RiLWWphUukHP0H2y7Lymy9XxVrLqFRPJWN4VQ3y6VR1Uq0g
LG7LunUk3Oj3tklWBCWeY//mvSkmaNPL4fglM/KJ2jgCYdqEz2c6w49pyjUU
oC8JwREprLiRL3f/48AKNx4XlwhDMAvjBNdScd1wBNO5lAJV6J1Fylv03Jji
yKvzBPtcPbjg/AHu1luuM9ySkHmluG4DRPo8mozKTfi0r4hVkvH5yagvbQuC
N+jkTV+lGhXw6sjhX10sxVSxPjn4hnLxiZSr2YwsGZcgjPHfmbHrYthXr52I
bvXshx5q8Kpge0YFbQ07wG0LbPng6p4Q1nM6JPmJv+BUSjItGUUil3VRROzl
t9cR9eQiInbv9cJ7e3MRdKGCtDOUNMGhz30qpbwxdqkYjKOKHV7zQg7u5mMW
ZzI9iyVSjr5++s/O114CjmQx6QkRSTDLxHfPhs/5Of5qwOgOmBAobxGKKoxk
DQr1ayKX1ODwwjQmCzVzIR3pogw9JwXfxmYOsNBUcxTOZsoRNF71bPBcG7Q3
fIguygDH2nJVsCR1wJK+9BGHNHbWptrVOMDmfWOk4CSV9tottTHd6nMc+g2v
iK2oZUJ0cZOWxE8KRi4in1aOnq1Dlj6bWv7baqxJmDVBDGVWx0bkMEpmXT1i
JsuVxnLqmIXbmlKXJQQUCQHgT0Uwcj5r+PXz4dE/98Pnjc++Hj77Zzzpu1hZ
Coik3aY880NeUaYfTZFtTuZ5MqmFSJrcGomQy8btvm8TBsLUOTQ1fCh3ydk2
BtZSlw0XiHti0V6n7344yuICOMMFLNEkvLx22AnEvM2QCsmoh4QqGB6VbSP6
jhYBx50+L8dVmlYYVC4sSaVTE/APFdwT4haexsdeKutHFpTmHD6t9uboar+r
1jJrXajA6uHlyfVbvikBPnH4HiR+8OzoiHiNrZXTNRK9WqIHn1bgJd1NpL6o
+S3PYeMb9Lk9ZNkuY1nEJZSiNDceL+uCPU6MA0cmrAIS42hEUaRF891kaNUo
ITqvv7Myji21i3Xeg2PdGkPtOSrseV0WzHsk04izc+03JxAfqse1HAfcRUkh
amAtLjyx3IiUDKtAZNvv8tk5udnFhT6klZwBPurH0wa2q0zxnoO8vMmxmeQL
zTfglIx2Rwn2EC3y2KT9AEH3lbRBd/bC+dnNy/DmavTmunlBrHS2fWidQZpD
0Nh0GjBElZClpdxEooEnN3xJkaYqtRJwcG3t3/7KSfHiDitxpV2S1eUK1od5
sL8/IPMmrkM26IGcqUwOkOw3/Ntf//bXkQujISKhBVDTFZLS+wxKWgS7nV1j
0QVf1es6o3DFb7XGXTwV7ltL4MG03WvLuWb54MKJPF6ledi8swdINe9r1K5X
Lkiy9gLMNxhHKR2HQoT46nuuAIBasssLf4fpJY3IuUv9vbJdmM+CMvkJbQ1U
waCx6MNwRuKeXveC2eIJaOwNQWCgC/BIbzL8ogzqG6SIuuT+Km5dzuKZHbqi
PudF6WmmIqMwNUhmMFkTM/sGaBNENlsKCz4Z0R65j9hoBnbYDy9IkcNYasYS
bXEvDMnCkYbGNrcYLn++uWHAHYbriBgjWD1vGM21DJortJncOLHtJKovFD31
Y3astjejeFoTqeHWhgPcc2iL/qxal03QZSvk3t0iueFg8NJ9icd9wXfb0Kkm
3PNH8jdEaySWkWeDZURnxetnVjgMrky8mrjAuu5Ji6GTzc7u7CSyRfgqtRSR
+KKWYOOiFt+N4sfrbNMX70YeDkJzAz6RonBfW5OG9gMCQ46AqcXwQAduXH9T
N2Kog6tAHs4fTNgXx3535ym3wHaUGMlcdQMUXMJh4hn0jdgQL4aHljiZRiAa
PZIbaTYnVrC7LOnSWqJWHnr1U3UQ97OSodlnR8g8s9WzRVLeDhu41hVuobcY
YzoFbiNMKPciOC3Uy+Fi5NFiEu62yE13RNnj1pPIjGrrYYHLTnA1YU9touU/
ScriExSFMV9V40QQlqeTXuUObmgTTew8dVd7Qd3y/JAI+3WowBI40d6HCd+D
wPLTExy4ja9aldYfmIfbbxVrGHmbV4yh5ZKV9CJx2HSVWmbRkb5+cojEAe6A
8+C1y5rB4s1HwOeLLtRHoYXToj+2c1H1BLwOZpLWwJ5gjGlj7WquNv25ueB4
jvbq9HDzYve+DQEhWUN0K703BzGVJiK7HbuOR42sovaq7eUZdsdJGYj7U7Ke
ItI4pGOMKBt6cUFMWym9G/Q4FRBbnxVaKcq3vZV6tFCj38qpZg0HcJrYbUOU
BOjUSYY7MpKb6+T7NLyMRS5BoEWSIOKH1N0eYI0010vJdoIBioRaIClkj4uC
0lGIJsjdS+VVP2lHtXcCgUoF7Y/uxxcYHGwMwjTMkZxpO2xpUqUta5bT41vO
8I0q6ghZ64WI9EBAaBFBHAMSdZpkG8UKFdxTwz0OANcrSTAOOLAT3+H6RIxa
w1nlc2soNJxlHY/9F14HIA+D+mFPbkgDUxBdAo5sMkIL4bf3onQGMyidpcWX
Wcb037CYWPVQW0g1TDa9APkx2ZTThG2oYpWx7ogSUdtBHisVdwadgIFfR+Om
8FUCTIE4Y2pkwdKmxsR8P0I9FydGslrm1N7YkWsp7ooFw5WDvhJyrVU5h5q6
61B2HfjttnwkEvN5zVEV2p6Wpl7eIS/H6E0wLSyXhl1ShcnRH7788Cg08hAu
VeboudjH1o3Vvl9Lv955c3qy25cUqLekr0rGt733gnUGVerx+cmIM/mRFbpY
ZZZLaUgOztwF35LJKkYWnr8NiTkBEM54FKXKSyTjoFQ+re6jOoSzud8a2aPu
G1YX0SIZ0LBIfthLV8XtQ3fo5GDsyDclXWnis75+nWbpZyg3FkC87XPm3xun
+djeNQlDYA0Q//nucO/qbHR6cTZcxBJj8kFcF6S5JpZBUHfkmwKSCqPXBslT
Z6TxrZdV+AKaDOJ6sgI1hi0Y66t+OJs3QW4W32ji+vgBr2Ov0IGlMlhTrTk6
iRWVapXXDerc3UoshgKvProw1oaR7EvxW0iesUtaIQbViejsSiaBartscoGz
G7HX6K/W7JPmV+I7E1nNK26+0yxTx8B1jsoo89M0bevpnjq1LtjYKoazvOe1
SvJauyElM02NXmUIO03uMtPcQRcoqkFTd+5otApdSr49Tr43KfKsh7qw1XsV
71VU3trceXdlSD2m7xvqewnbTv8SX6LfZ8zrDzN0vU7tzbfsk4NbGrelM6XC
S22teGTUvadFfX913srnJPYiXF0u7WmuKxB3h0XfL7jCBh5q/zpVAYPMsmJD
nadZNt22GrGt+ZjWTtV8jR1BtJAVlmbvVPI7PAE1+XmhRuF07O0vNunv7OXL
AFg2zqufQXU6U/PCHUfrckeK5oDzjMKh2Ey8OiO0Hb09V5tguLG/NrXIu3jD
Iru9YtjbnkWXJuUF9go9ejlpFGcxhQ9aqbf7B0NSMLzrTV1rFb+iICBinc24
AdvcKL/RK9UBRN+dW9ch5XYMzduuEZzvonSrbbhCa0OuCV8RTA1uJiAHPrkz
sRdH1dn1HTQlYMG9tkV9EY5njEvfybq8DkL9Ne4yxqgXUB/goPB4u/RNXi8N
eCEnyYlf1LW9U3mdNPqv1qy3eYByZzDfXov+eGweCho1cQGOGQRYmhhW5QIY
WZsLw0kUhsMA0ojH57iPGk2tFVobqsXyvXITnqj0MbytkXSIS4Xe7/V6aKQa
0sDqD9qqTMlDqaZB27ult+L6lnGc2QV4WIlsfayM4jlHG8XEYX/S88FoNRug
XF9RJJlgH6QsdwEnyUhHTzRd1E6Q8itkyl/kP5EGHoVytboOZcLD4f5u4K/C
vTBasvPAPmhhRi+Eu86d7c9fhzO5BEsKsNhdJVFujlV3KHBOTDJCOi6UTgcw
A8ADRqw0SAgvcT50kp2pXmpZcpc+xL71ougYXUjDe+Nicy9H3539+fTNtWsg
CLbgnwIsc4LLnqkme3O+QtDALLOhE52HCxDISntDS9UQcheBWecRmSLyenOt
QXBBM2zRZx04xNSw+46NWYbSDMJV1NZbCKB9ywn2m2Gs7XK/jg7UF+xZPA3y
zN7GXPhqjoRXEMRz0WTn2MjiqIhVCVGNJI7MIndBDFtNZyWMuyhLnS2lqdhZ
B/NB7N5ELiBbztcltJ4QByMAPQrvkqKCJaUNw0hdwKO8d+hPCtwjpl/6ht2G
Npdv6RiGZhc6C4S2lbEvCqUKjmR53nGRxDPDCQRitbjyRuW6otfE4U4inWtK
1yma++AmGgPrSVq35JWAJiRBU1xV8W7QzbPZdcelflNZOVcY+j5fJxroDaKQ
c89ECbgfNDe8coom99YWt9rozWgjJ+aHHzrdacsUzaL+QD8ygMUdPKz3yP74
oxYA3VuxTztv3/nt5dYTRvEK9IrRqmGYie5tRzlGBTSjkSgQfGOOzXl9KdXm
Ox8+kDIVabcsP+A80IHQb9iOU1d2XBBc4qiKHhx0oQ9tH5fLt13ld710SZqN
0d8IRh/u9c6Y94TXDZ/elb1/QHonB/Yy2cNnehc2A1Y6nKFlxAZkyThp9w22
nMy/8KAewS5yzRlo/MnH8NTz+KFPnKVRl4vWvKaqkaBGo3TdP/FRUky7E+CY
hGzg1KvDNZzosple0epa7V2Q09HsFTsg/GSsba1Oi+D+pxZn3PDbFtDREBHN
6fzLl7T7bNQ1SatFpJTq2TaCDjx629JD6+juhdZeit4+1LmUR2azqFu3mGj0
V/yFaOyPYYm1gc/8mbi37B+K4icqwfgsO3G8A9Nbt7N14b0Dy0db7PRRqs9a
wN/IV/yoTZnRfJEMarMJv5eN9hytjm2XdduiJKubiMrHHO18lC+KRO49zGF7
DsDserdlVawZhTZxK7BWIQTyqo5e/+768o0FS9NK2diPDMtefbnZOG+WMN0Y
koYENxYKL90ajoWSBZJep2w2ueqldizIDVNxKx4Mw/W06ia2qaeaGBjby5Bl
Kldv1qftFxGqR4NQv6OBfWQ7xh3PeNS/Vex+LrcaeHE9VSJFXdDCjCB08zcL
FGgOh8HH4TuNOfhFb3oiSCLSG2q1f41sVekSqoXn82yY9x8+tG6agUT6R5OY
d2mMRzBdBOYqmB55zjm9PrqbQB5+0Ob0PfZ8d4niR4spnW9tskkmDWkQ2SJx
T3tRKv88JrpusNAOFUgI/RH++fNP8yEO+d/gdF07aHO9RxQ3n/F9nkr4EBcM
XPrqf5sLBh4XlOOqW0MqUvz/yRD/Acyq+6qRR1jWL+NRNGSj96bPGRosodGd
dOtTjzOOFrm0On05v1Ld50uceK800OvoAsGqgfaXslRwoR2D9GEP01UiAYOW
sV/C7HMYLzoiMov5SGi7PnmgRwNkd9/bR83nCMOHTqH7DLp/5WNpQ0Z+PnKU
Tn91vosarP3tNWxhY1Qtd/x7jEqW+LX1KGxWqPztr29yr0IiCDaTfk2ayCXh
2hVIr8xwbgoN+IN83353rpFxKUEMvO4MquO3Es5r+8C2JWCzRw1azg3Ey1iC
1O3E0QJIZL3MUVjks5VkZoXS5J5bXfAVp/fznM0HmxfvstmSO8Tobg3S0N4l
HbW+SJ+EjWXbS7N/ovRbTkvFEdcfBcscPATsBAw5RWhfMwbThFOhXNm8e72K
OE4vKUpIh9EeQqRc9AN3rxFvuE6uhava5QQLM3qo4c155VEWki5iG+jwYF4K
iPzFcmSvb+3QgHvFnVy9Fr7Yyqzm7AVUH34v1zgoB5UsGmTqtwtodq7elruo
wwn4Sh9JQ5BVktZSag8qb4mQlC7V3TLogkWGhCwDTj3LpYyjr0VD8NdxBwJj
bh38JVcX/cSzdeMw0F9Oqj5Km8dVZ5Jl/v5myPNZZWiaNal15au3BO7LjEsd
VtpCxiVtWnywzgR/ZskUVhdV5GgqQC6f1abgaUCmy+a9GnKnlmtgbvVXNOrk
fD3kOyIJpVXF2IbGlZmID50r51By6vew1zOGCR5MV+k0Sd1VHrIS+Bed9dy8
TMK6P9s2aeASXBHvlZKRBtd3ty8GO59x08IurqbL+ygjiLjaiiCOhXHQnJcG
OTfP0zhosgBuI+jVlDSqeXeQ+Ca34+1uJElq4WEgfRy4MKMJV3dea1frZqMI
jSa5xFCJW+Xgr4GedqNMpd0ejcGWOqbC4XNbimfLkoJGXmidhFfNgTFb6xuA
aOKIlUwumzxRBZFX/ooZ0WGvcR2RtHOq65gvQEI+57INSFRmuJ71zcBBI+Ml
+PDhJl9GKWmBE+ukPDUZ2Cxe1x5CbZHGw7KB4m68Av3dsXKrO9DUd5E1AhQM
GdvBuQzYNimSAcq+1MbV5rHexZ1rjOOLUkp2krwYhmf2TkgeyXWdYTd7fSG5
diCO0akyRkKXRvFQUyjsA0JOeiNhHJeaAa8cl2sj3uqEDyFTnP9kJBdvvsri
wmjNUiP7ASM1Sio3/Ix1ZTWnlSzQ32EYjmrKspdJ1Mll7v4sBJZmkmnJWduF
4e6N0AW4/H7LPJx5HR4AQYa74V8Yx9fahJ79F7BRZAT/PAlnuF24zQfifqcH
+61rC4ahNtnNQUeEKqkN9yWlHpDwHz3MzlbZdcNox9jrztM6it7G3Bqj1NtS
RVoNXdug9h26HBEj4sVYGjcTsEQcKAJ/NGMbWeorG9PifYWK5TT1LZduvKje
AuhTGITNI+bAmHJ7DhFL2n6V2J6xgmosWISUF1wGL2NLiJR9F7gx6KUfJ+S3
uSw34us5wZnEXuQYpVhhPpX0LYFlTqvcQFBLaAA9XyCSp3cejo0RIdZ6Akk4
cdFBLd6XgD8HwYq1zaLX9Ewh/kbzMeKX2lHPIPoFpuBulNCq9Owh9CbiSfl8
pZShb4+Xe5bz/VX8NpcxtC7Y8jJOvITmGpjSX8ZvXZGU8o2odTk0TePKymDw
SxXPQPs2oiBP+xTwGjR4W/piMWNtc4Jiy5kLsQlDfgtBOtm0LDaLZLlrbeqS
XJq9RdZ2hSzEW3ULgV4T4fWT39lWFbFrI9MeTvv9nQ/2h0+D1q0mdYNlYexc
EUrP4Iq9+toRbqEOvRjNG1w5h+BFQC9BJKJNWrtqq26kx06lLM8GZLCQKcyp
H9G6EViXLKKgdjHIkB8+/J93RyfDd6cDz/mwKtISWRxP9g8PvhIBGY4mKACg
Q51xMpg67jisnEjqTOK60UgkRqntbAUOHnHyyiIRoc2RxOAVNEFkaOwf7muL
Pe7UxZ7ALB+Gz7766snhAdocoHvMwia1jQoySFHhi/uPJOPxIonj1IxzJO3Z
KoJw52J0cb47lHIgm8G5PZ2eU3ii7JZLuF6QivVdFK9u+8FVgiTBOHwRFRy1
v8pJqoanUbZOk/t+8DvawVsIshJ1GWdFMsFd54STaUTPrunR69QQM+0H14DC
DW6zLfrBKDXv0ZHcpFlym9/RB2R/hlc5yfd+cAFw0rPzfFEq77gwcxKX4VlB
JhRvem7SJV+1x/iotUC1YuTnm5dkgbCS5rla0ZJuMAiRLY7jPbUe2FdkHOfF
GvH0x8tUNitTbDC9M9no4AB98GDNcNp5xhbLMfEcOoQFNyve/uo+Uf7Z9bfe
vVxy0V/ONcmR6H6ZBOYLP3lvRyC9i9v6/M7xjW4Odaks2ZE4CX78gqAZGt45
1LcdQord7Uvc/zpwuIKzwNlzCigy37UotPaa1u4n8UzJfUNefxyu/2t4dv0E
YeKsEdo2lCnK3FLJsODcfBeor+5JfBbc1GXbTUoldrkJMusrc5ck0/g7Xg3L
fd5Kc6gNOW0tzq5aeA3A0onpMzi/z2wbN70cXItgGgxbs0pC2/rYKfNim2eG
y/KkCaS16sii8Lq2aD+BqKww6Qlr03Ej0RoXPnqR5B7ekau7kNJWPvZaDUVu
N+6VXoldg/dHDAa/k0arlh4kXNdLqszrxquvgBnn0iAcaTTvOZvMK00UQEjN
MokRr4U7rclnHA4dH5rueeDtv9IiB9vSX6OmnPYulwnoQxtY1PdQ3NalBK73
DT/OCXiVK695YE3PsCZmvLSF0am+8sALT/HC2XdXjcfpWOqKCCsXVQ2sksUm
OtYZZ9gwYa0grTvfqE7kcIWjyHNzxg0fs//edXeHeVv10tV1ePsmn2CT774N
0wg+De6sY4UBCV9P3NBjnXfo0SHHqW6IK50yrwkyGexJxg0x7WXDJfDQbxeJ
VPyyo5GRd8lzo83h1p0cMc7VHsgmdHD2bVuCltTj7JeepXi/sQ1GkyLzyYZj
essSDrGE0wfvvuOGxeI5bbbXBXPTvBqWbKxakyLAiTnn1pAswktuVbJzHl/u
+jA65TxLCTHoI6dvLneteGN3G+tN0vblHnyR3YW6c9aHsXrGbReNByY6gwYu
QT97fTsgWEh/y8YBrtPUrkR6XYJQdmmA4cK/V9qKRe2aUsua+aq5Ew7+4JHX
3199N7DPhHJFBoAmdRD2Emq9raLtmWrQBN6T6zVBk4z6tsFmM22UG35HYzLh
0MQmlrDA77Wtu0XN0r8cL9Rz1B7lYe+t9i8XwJaeoHB+6qEwA80IbF4b0eKj
VvX6opQumA8x4X3m+RpKbNTe2XzuIVOFCEuXre9I21rxGquyXSZRvsKKxZvL
YfhOTHfJE+bM1XTNnkJ3E2OrtqBe7mZivNCPPdBNKrB1e14vdJvcSosa+izV
i8dZej62t7NM0nwVWw8aQ1gcgoL5uYacG27mR9bN6D4KpdNoTixjbcuCMfo1
HBPoeZOtlo8MxEd2pXoZPyXNiBAtQLJ8Nl3VjUzE9yTmky1GXkbwoHiAUCeG
HK09hmMCry1tGCrLqn2hRHnnDmrlwytGXV8L0xxu/Rc07CATcbwAAA==

-->

</rfc>