rfc8739xml2.original.xml   rfc8739.xml 
<?xml version="1.0" encoding="UTF-8"?> <?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"?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?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"?>
<rfc ipr="trust200902" docName="draft-ietf-acme-star-11" category="std"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft -ietf-acme-star-11" number="8739" category="std" obsoletes="" updates="" submiss ionType="IETF" consensus="true" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
<front> <front>
<title abbrev="ACME STAR">Support for Short-Term, Automatically-Renewed (STA <title abbrev="Support for ACME STAR">Support for Short-Term,
R) Certificates in Automated Certificate Management Environment (ACME)</title> 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"> <author initials="Y." surname="Sheffer" fullname="Yaron Sheffer">
<organization>Intuit</organization> <organization>Intuit</organization>
<address> <address>
<email>yaronf.ietf@gmail.com</email> <email>yaronf.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author initials="D." surname="Lopez" fullname="Diego Lopez"> <author initials="D." surname="Lopez" fullname="Diego Lopez">
<organization>Telefonica I+D</organization> <organization>Telefonica I+D</organization>
<address> <address>
<email>diego.r.lopez@telefonica.com</email> <email>diego.r.lopez@telefonica.com</email>
skipping to change at line 55 skipping to change at line 42
<address> <address>
<email>antonio.pastorperales@telefonica.com</email> <email>antonio.pastorperales@telefonica.com</email>
</address> </address>
</author> </author>
<author initials="T." surname="Fossati" fullname="Thomas Fossati"> <author initials="T." surname="Fossati" fullname="Thomas Fossati">
<organization>ARM</organization> <organization>ARM</organization>
<address> <address>
<email>thomas.fossati@arm.com</email> <email>thomas.fossati@arm.com</email>
</address> </address>
</author> </author>
<date month="March" year="2020" />
<date year="2019" month="October" day="24"/>
<area>Security</area> <area>Security</area>
<workgroup>ACME Working Group</workgroup> <workgroup>ACME Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<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 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 sequenc
e upon compromise.
This memo proposes an ACME extension to enable the issuance of short-term and au
tomatically 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 <keyword>OCSP</keyword>
https://github.com/yaronf/I-D/tree/master/STAR.</t> <keyword>CRL</keyword>
<keyword>revocation</keyword>
<abstract>
<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, the revocation process is often unreliable. An
alternative to revocation is issuing a sequence of certificates, each
with a short validity period, and terminating the sequence upon
compromise. This memo proposes an Automated Certificate Management
Environment (ACME) extension to enable the issuance of Short-Term,
Automatically Renewed (STAR) X.509 certificates.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" title="Introduction"> <section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name>
<t>The ACME protocol <xref target="RFC8555"/> automates the process of issuing a <t>The ACME protocol <xref target="RFC8555" format="default"/> automates
certificate to a named entity the process of issuing a certificate to a named entity (an Identifier
(an Identifier Owner or IdO). Typically, but not always, the identifier is a dom Owner or IdO). Typically, but not always, the identifier is a domain
ain name.</t> name.</t>
<t>If the IdO wishes to obtain a string of short-term certificates
<t>If the IdO wishes to obtain a string of short-term certificates originating f originating from the same private key (see <xref target="TOPALOVIC"
rom the same private key (see <xref target="Topalovic"/> about why using short-l format="default"/> about why using short-lived certificates might be
ived certificates might be preferable to explicit revocation), she must go throu preferable to explicit revocation), she must go through the whole ACME
gh the whole ACME protocol each time a new short-term certificate is needed – e. protocol each time a new short-term certificate is needed, e.g., every
g., every 2-3 days. 2-3 days. If done this way, the process would involve frequent
If done this way, the process would involve frequent interactions between the re interactions between the registration function of the ACME Certification
gistration function of the ACME Certification Authority (CA) and the identity pr Authority (CA) and the identity provider infrastructure (e.g., DNS, web
ovider infrastructure (e.g.: DNS, web servers), therefore making the issuance of servers), therefore making the issuance of short-term certificates
short-term certificates exceedingly dependent on the reliability of both.</t> exceedingly dependent on the reliability of both.</t>
<t>This document presents an extension of the ACME protocol that
<t>This document presents an extension of the ACME protocol that optimizes this optimizes this process by making short-term certificates first-class
process by making short-term certificates first class objects in the ACME ecosys objects in the ACME ecosystem. Once the Order for a string of
tem. short-term certificates is accepted, the CA is responsible for
Once the Order for a string of short-term certificates is accepted, the CA is re publishing the next certificate at an agreed upon URL before the
sponsible for publishing the next certificate at an agreed upon URL before the p previous one expires. The IdO can terminate the automatic renewal
revious one expires. The IdO can terminate the automatic renewal before the neg before the negotiated deadline if needed, e.g., on key compromise.</t>
otiated deadline, if 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" format="default"/>.</t>
<t>For a more generic treatment of STAR certificates, readers are referred to <x <section anchor="name-delegation-use-case" numbered="true" toc="default">
ref target="I-D.nir-saag-star"/>.</t> <name>Name Delegation Use Case</name>
<section anchor="name-delegation-use-case" title="Name Delegation Use Case">
<t>The proposed mechanism can be used as a building block of an efficient
name-delegation protocol, for example one that exists between a CDN or a cloud
provider and its customers <xref target="I-D.ietf-acme-star-delegation"/>. At a
ny 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 the delegated entity needs to acces <t>The proposed mechanism can be used as a building block of an
s efficient name-delegation protocol, for example, one that exists between
a
Content Distribution Network (CDN) or a cloud provider and its
customers <xref 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, the delegated entity needs
to access
the auto-renewed certificate without being in possession of the ACME account 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 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" use of unauthenticated GET in this protocol (<xref target="certificate-get-nego"
/>).</t> format="default"/>).</t>
</section>
</section> <section anchor="terminology" numbered="true" toc="default">
<section anchor="terminology" title="Terminology"> <name>Terminology</name>
<dl newline="false" spacing="compact" indent="8">
<t><list style="hanging"> <dt>IdO</dt>
<t hangText='IdO'> <dd>
Identifier Owner, the owner of an identifier, e.g.: a domain name, a telephone Identifier Owner, the owner of an identifier, e.g., a domain name, a
number.</t> telephone number, etc.</dd>
<t hangText='STAR'> <dt>STAR</dt>
Short-Term and Automatically Renewed X.509 certificates.</t> <dd>
</list></t> Short-Term, Automatically Renewed X.509 certificates.</dd>
</dl>
</section> </section>
<section anchor="conventions-used-in-this-document" title="Conventions used in t <section anchor="conventions-used-in-this-document" numbered="true" toc="d
his document"> efault">
<name>Conventions Used in This Document</name>
<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL
NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”,
“MAY”, and “OPTIONAL” in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and
only when, they
appear in all capitals, as shown here.</t>
</section>
</section>
<section anchor="protocol-flow" title="Protocol Flow">
<t>The following subsections describe the three main phases of the protocol:</t>
<t><list style="symbols">
<t>Bootstrap: the IdO asks an ACME CA to create a short-term and automatically
-renewed (STAR) certificate (<xref target="proto-bootstrap"/>);</t>
<t>Auto-renewal: the ACME CA periodically re-issues the short-term certificate
and posts it to the star-certificate URL (<xref target="proto-auto-renewal"/>);
</t>
<t>Termination: the IdO requests the ACME CA to discontinue the automatic rene
wal of the certificate (<xref target="proto-termination"/>).</t>
</list></t>
<section anchor="proto-bootstrap" title="Bootstrap"> <t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<t>The IdO, in its role as an </section>
</section>
<section anchor="protocol-flow" numbered="true" toc="default">
<name>Protocol Flow</name>
<t>The following subsections describe the three main phases of the protoco
l:</t>
<ul spacing="compact">
<li>Bootstrap: the IdO asks an ACME CA to create a short-term,
automatically renewed (STAR) certificate (<xref target="proto-bootstrap"
format="default"/>);</li>
<li>Auto-renewal: the ACME CA periodically reissues the short-term
certificate and posts it to the star-certificate URL (<xref 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" fo
rmat="default"/>).</li>
</ul>
<section anchor="proto-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> ACME client, requests the CA to issue a STAR certificate, i.e., one that:</t>
<ul spacing="compact">
<t><list style="symbols"> <li>Has a short validity, e.g., 24 to 72 hours. Note that the exact de
<t>Has a short validity, e.g., 24 to 72 hours. Note that the exact definition finition of "short" depends on the use case;</li>
of “short” depends on the use case;</t> <li>Is automatically renewed by the CA for a certain period of time;</
<t>Is automatically renewed by the CA for a certain period of time;</t> li>
<t>Is downloadable from a (highly available) location.</t> <li>Is downloadable from a (highly available) location.</li>
</list></t> </ul>
<t>Other than that, the ACME protocol flows as usual between IdO and CA.
<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 u ntil the CA is willing to issue the requested certificate. In particular, IdO is responsible for satisfying the requested ACME challenges u ntil the CA is willing to issue the requested certificate.
Per normal ACME processing, the IdO is given back an Order resource associated w ith the STAR certificate to be used in subsequent interaction with the CA (e.g., if Per normal ACME processing, the IdO is given back an Order resource associated w ith the STAR certificate to be used in subsequent interaction with the CA (e.g., if
the certificate needs to be terminated.)</t> 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" numbered="true" toc="default">
<t>The bootstrap phase ends when the ACME CA updates the Order resource to inclu <name>Auto Renewal</name>
de the URL for the issued STAR certificate.</t>
</section>
<section anchor="proto-auto-renewal" title="Refresh">
<t>The CA issues the initial certificate after the authorization completes succe
ssfully.
It then automatically re-issues the certificate using the same CSR (and
therefore the same identifier and public key) before the previous one expires, a
nd 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, as described in <xref target="I-D.ietf-acme-star-delegation"/>, obtains t
he
certificate (<xref target="fetching-certificates"/>) and uses it.</t>
<t>The refresh process (<xref target="figprotorefresh"/>) goes on until either:<
/t>
<t><list style="symbols"> <t>The CA issues the initial certificate after the authorization
<t>IdO explicitly terminates the automatic renewal (<xref target="proto-termin completes successfully. It then automatically reissues the
ation"/>); or</t> certificate using the same Certificate Signing Request (CSR) (and theref
<t>Automatic renewal expires.</t> ore the same identifier and
</list></t> public key) before the previous one 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 as described in <xref
target="I-D.ietf-acme-star-delegation" format="default"/>, obtains the
certificate (<xref target="fetching-certificates" format="default"/>)
and uses it.</t>
<t>The auto-renewal process (<xref target="figprotorefresh" format="defa
ult"/>) goes on until either:</t>
<ul spacing="compact">
<li>IdO explicitly terminates the automatic renewal (<xref target="pro
to-termination" format="default"/>); or</li>
<li>Automatic renewal expires.</li>
</ul>
<figure title="Auto renewal" anchor="figprotorefresh"><artwork><![CDATA[ <figure anchor="figprotorefresh">
<name>Auto-renewal</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
Certificate ACME/STAR Certificate ACME/STAR
User Server User Server
| Retrieve cert | [...] | Retrieve cert | [...]
|---------------------->| | |---------------------->| |
| +------. / | +------. /
| | | / | | | /
| | Automatic renewal : | | Automatic renewal :
| | | \ | | | \
| |<-----' \ | |<-----' \
| Retrieve cert | | | Retrieve cert | |
skipping to change at line 204 skipping to change at line 204
| Retrieve cert | | | Retrieve cert | |
|---------------------->| short validity period |---------------------->| short validity period
| | | | | |
| +------. / | +------. /
| | | / | | | /
| | Automatic renewal : | | Automatic renewal :
| | | \ | | | \
| |<-----' \ | |<-----' \
| | | | | |
| [...] | [...] | [...] | [...]
]]></artwork></figure> ]]></artwork>
</figure>
</section> </section>
<section anchor="proto-termination" title="Termination"> <section anchor="proto-termination" numbered="true" toc="default">
<name>Termination</name>
<t>The IdO may request early termination of the STAR certificate by sending a ca <t>The IdO may request early termination of the STAR certificate by
ncellation request to the Order resource, as described in <xref target="protocol sending a cancellation request to the Order resource as described in
-details-canceling"/>. <xref target="protocol-details-canceling" format="default"/>. After
After the CA receives and verifies the request, it shall:</t> the CA receives and verifies the request, it shall:</t>
<ul spacing="compact">
<t><list style="symbols"> <li>Cancel the automatic renewal process for the STAR certificate;</li
<t>Cancel the automatic renewal process for the STAR certificate;</t> >
<t>Change the certificate publication resource to return an error indicating t <li>Change the certificate publication resource to return an error ind
he termination of the issuance;</t> icating the termination of the issuance;</li>
<t>Change the status of the Order to “canceled”.</t> <li>Change the status of the Order to "canceled".</li>
</list></t> </ul>
<t>Note that it is not necessary to explicitly revoke the short-term cer
<t>Note that it is not necessary to explicitly revoke the short-term certificate tificate.</t>
.</t> <figure anchor="figprototerm">
<name>Termination</name>
<figure title="Termination" anchor="figprototerm"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
Certificate ACME/STAR Certificate ACME/STAR
User IdO Server User IdO Server
| | | | | |
| | Cancel Order | | | Cancel Order |
| +---------------------->| | +---------------------->|
| | +-------. | | +-------.
| | | | | | | |
| | | End auto renewal | | | End auto-renewal
| | | Remove cert link | | | Remove cert link
| | | etc. | | | etc.
| | | | | | | |
| | Done |<------' | | Done |<------'
| |<----------------------+ | |<----------------------+
| | | | | |
| | | |
| Retrieve cert | | Retrieve cert |
+---------------------------------------------->| +---------------------------------------------->|
| Error: autoRenewalCanceled | | Error: autoRenewalCanceled |
|<----------------------------------------------+ |<----------------------------------------------+
| | | |
]]></artwork></figure> ]]></artwork>
</figure>
</section> </section>
</section> </section>
<section anchor="protocol-details" title="Protocol Details">
<t>This section describes the protocol details, namely the extensions <section anchor="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> to the ACME protocol required to issue STAR certificates.</t>
<section anchor="acme-extensions" numbered="true" toc="default">
<name>ACME Extensions</name>
<t>This protocol extends the ACME protocol to allow for automatically re
newed Orders.</t>
<section anchor="star-order-ext" numbered="true" toc="default">
<name>Extending the Order Resource</name>
<t>The Order resource is extended with a new "auto-renewal" object
that <bcp14>MUST</bcp14> be present for STAR certificates. The
"auto-renewal" object has the following structure:</t>
<ul spacing="compact">
<li>start-date (optional, string): The earliest date of validity
of the first certificate issued, in <xref target="RFC3339"
format="default"/> format. When omitted, the start date is as
soon as authorization is complete.</li>
<li>end-date (required, string): The latest date of validity of
the last certificate issued, in <xref target="RFC3339"
format="default"/> format.</li>
<li>lifetime (required, integer): The maximum validity period of
each STAR certificate, an integer that denotes a number of
seconds. This is a nominal value that does not include any extra
validity time due to server or client adjustment (see below).</li>
<li>lifetime-adjust (optional, integer): The amount of "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
<xref target="operational-cons-clocks" format="default"/> for
why a client might want to use this control, and <xref
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.</li>
<li>allow-certificate-get (optional, boolean): See <xref
target="certificate-get-nego" format="default"/>.</li>
</ul>
<section anchor="acme-extensions" title="ACME Extensions"> <t>These attributes are included in a POST message when creating the
Order as part of the object encoded as "payload". They are returned
<t>This protocol extends the ACME protocol, to allow for automatically renewed O when the Order has been created. The ACME server <bcp14>MAY</bcp14>
rders.</t> adjust them at will according to its local policy (see also <xref
target="capability-discovery" format="default"/>).</t>
<section anchor="star-order-ext" title="Extending the Order Resource"> <t>The optional notBefore and notAfter fields defined in <xref
target="RFC8555" sectionFormat="of" section="7.1.3"/> <bcp14>MUST
<t>The Order resource is extended with a new “auto-renewal” object that MUST be NOT</bcp14> be present in a STAR Order. If they are included, the
present for STAR certificates. The “auto-renewal” object has the following stru server <bcp14>MUST</bcp14> return an error with status code 400 (Bad
cture:</t> Request) and type "malformedRequest".</t>
<t><xref target="RFC8555" sectionFormat="of" section="7.1.6"/>
<t><list style="symbols"> defines the following values for the Order resource's status:
<t>start-date (optional, string): the earliest date of validity of the first c "pending", "ready", "processing", "valid", and "invalid". In the
ertificate issued, case of auto-renewal Orders, the status <bcp14>MUST</bcp14> be
in <xref target="RFC3339"/> format. When omitted, the start date is as soon as "valid" as long as STAR certificates are being issued. This
authorization is complete.</t> document adds a new status value: "canceled" (see <xref
<t>end-date (required, string): the latest date of validity of the last certif target="protocol-details-canceling" format="default"/>).</t>
icate issued, <t>A STAR certificate is by definition a dynamic resource, i.e., it
in <xref target="RFC3339"/> format.</t> refers to an entity that varies over time. Instead of overloading
<t>lifetime (required, integer): the maximum validity period of each STAR cert the semantics of the "certificate" attribute, this document defines
ificate, an integer that denotes a number of seconds. This is a nominal value w a new attribute, "star-certificate", to be used instead of
hich does not include any extra validity time due to server or client adjustment "certificate".</t>
(see below).</t> <ul spacing="compact">
<t>lifetime-adjust (optional, integer): amount of “left pad” added to each STA <li>star-certificate (optional, string): A URL for the (rolling)
R certificate, an integer that denotes a number of seconds. The default is 0. STAR certificate that has been issued in response to this
If present, the value of the notBefore field that would otherwise appear in the Order.</li>
STAR certificates is pre-dated by the specified number of seconds. See also <xr </ul>
ef target="operational-cons-clocks"/> for why a client might want to use this co </section>
ntrol and <xref target="computing-effective-cert-lifetime"/> for how the effecti <section anchor="protocol-details-canceling" numbered="true" toc="defaul
ve certificate lifetime is computed. The value reflected by the server, togethe t">
r with the value of the lifetime attribute, can be used by the client as a hint <name>Canceling an Auto-renewal Order</name>
to configure its polling timer.</t> <t>An important property of the auto-renewal Order is that it can be
<t>allow-certificate-get (optional, boolean): see <xref target="certificate-ge canceled by the IdO with no need for certificate revocation. To
t-nego"/>.</t> cancel the Order, the ACME client sends a POST to the Order URL as
</list></t> shown in <xref target="figcancelingstarorder"
format="default"/>.</t>
<t>These attributes are included in a POST message when creating the Order, as p <figure anchor="figcancelingstarorder">
art of the “payload” encoded object. <name>Canceling an Auto-renewal Order</name>
They are returned when the Order has been created, and the ACME server MAY adjus <sourcecode>
t them at will, according to its local policy (see also <xref target="capability
-discovery"/>).</t>
<t>The optional notBefore and notAfter fields defined in Section 7.1.3 of <xref
target="RFC8555"/> MUST NOT be present in a STAR Order.
If they are included, the server MUST return an error with status code 400 “Bad
Request” and type “malformedRequest”.</t>
<t>Section 7.1.6 of <xref target="RFC8555"/> defines the following values for th
e Order resource’s status: “pending”, “ready”, “processing”, “valid”, and “inval
id”.
In the case of auto-renewal Orders, the status MUST be “valid” as long as STAR c
ertificates are being issued. We add a new status value: “canceled”, see <xref
target="protocol-details-canceling"/>.</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 “cer
tificate” attribute, this document defines a new attribute “star-certificate” to
be used instead of “certificate”.</t>
<t><list style="symbols">
<t>star-certificate (optional, string): A URL for the (rolling) STAR certific
ate that has been issued in response to this Order.</t>
</list></t>
</section>
<section anchor="protocol-details-canceling" title="Canceling an Auto-renewal Or
der">
<t>An important property of the auto-renewal Order is that it can be canceled by
the 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="figcancelingstar
order"/>.</t>
<figure title="Canceling an Auto-renewal Order" anchor="figcancelingstarorder"><
artwork><![CDATA[
POST /acme/order/ogfr8EcolOT HTTP/1.1 POST /acme/order/ogfr8EcolOT HTTP/1.1
Host: example.org Host: example.com
Content-Type: application/jose+json Content-Type: application/jose+json
{ {
"protected": base64url({ "protected": base64url({
"alg": "ES256", "alg": "ES256",
"kid": "https://example.com/acme/acct/gw06UNhKfOve", "kid": "https://example.com/acme/acct/gw06UNhKfOve",
"nonce": "Alc00Ap6Rt7GMkEl3L1JX5", "nonce": "Alc00Ap6Rt7GMkEl3L1JX5",
"url": "https://example.com/acme/order/ogfr8EcolOT" "url": "https://example.com/acme/order/ogfr8EcolOT"
}), }),
"payload": base64url({ "payload": base64url({
"status": "canceled" "status": "canceled"
}), }),
"signature": "g454e3hdBlkT4AEw...nKePnUyZTjGtXZ6H" "signature": "g454e3hdBlkT4AEw...nKePnUyZTjGtXZ6H"
} }
]]></artwork></figure> </sourcecode>
</figure>
<t>After a successful cancellation, the server MUST NOT issue any additional cer <t>After a successful cancellation, the server <bcp14>MUST NOT</bcp14>
tificates for this Order.</t> issue any additional certificates for this Order.</t>
<t>When the Order is canceled, the server:</t>
<t>When the Order is canceled, the server:</t> <ul spacing="compact">
<li><bcp14>MUST</bcp14> update the status of the Order resource to "
<t><list style="symbols"> canceled" and <bcp14>MUST</bcp14> set an appropriate "expires" date;</li>
<t>MUST update the status of the Order resource to “canceled” and MUST set an <li><bcp14>MUST</bcp14> respond with 403 (Forbidden) to any
appropriate “expires” date;</t> requests to the star-certificate endpoint. The response
<t>MUST respond with 403 (Forbidden) to any requests to the star-certificate e <bcp14>SHOULD</bcp14> provide additional information using a
ndpoint. The response SHOULD provide problem document <xref target="RFC7807" format="default"/> with
additional information using a problem document <xref target="RFC7807"/> with ty type "urn:ietf:params:acme:error:autoRenewalCanceled".</li>
pe “urn:ietf:params:acme:error:autoRenewalCanceled”.</t> </ul>
</list></t> <t>Issuing a cancellation for an Order that is not in "valid" state
is not allowed. A client <bcp14>MUST NOT</bcp14> send such a
<t>Issuing a cancellation for an Order that is not in “valid” state is not allow request, and a server <bcp14>MUST</bcp14> return an error response
ed. A client MUST NOT send such a request, and a server MUST return an error re with status code 400 (Bad Request) and type
sponse with status code 400 (Bad Request) and type “urn:ietf:params:acme:error:a "urn:ietf:params:acme:error:autoRenewalCancellationInvalid".</t>
utoRenewalCancellationInvalid”.</t> <t>The state machine described in <xref
target="RFC8555" sectionFormat="of" section="7.1.6"/> is extended as i
<t>The state machine described in Section 7.1.6 of <xref target="RFC8555"/> is e llustrated in
xtended as illustrated in <xref target="fig-order-state-transitions-ext"/> (Stat <xref target="fig-order-state-transitions-ext" format="default"/>.</t>
e Transitions for Order Objects).</t>
<figure anchor="fig-order-state-transitions-ext"><artwork><![CDATA[ <figure anchor="fig-order-state-transitions-ext">
<name>State Transitions for STAR Order Objects</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
pending --------------+ pending --------------+
| | | |
| All authz | | All authz |
| "valid" | | "valid" |
V | V |
ready ---------------+ ready ---------------+
| | | |
| Receive | | Receive |
| finalize | | finalize |
| request | | request |
V | V |
processing ------------+ processing ------------+
| | | |
| First | | First |
| certificate | Error or | certificate | Error or
| issued | Authorization failure | issued | Authorization failure
V V | |
valid invalid | V
| | invalid
| STAR
| Certificate
| canceled
V V
canceled valid----------------+
| |
]]></artwork></figure> | STAR |
| Certificate | Natural
<t>Explicit certificate revocation using the revokeCert interface (Section 7.6 o | canceled | Expiration
f <xref target="RFC8555"/>) is not supported for STAR certificates. A server re V |
ceiving a revocation request for a STAR certificate MUST return an error respons canceled ='=
e with status code 403 (Forbidden) and type “urn:ietf:params:acme:error:autoRene ]]></artwork>
walRevocationNotSupported”.</t> </figure>
<t>Explicit certificate revocation using the revokeCert interface
</section> (<xref target="RFC8555" sectionFormat="of" section="7.6"/>) is not
</section> supported for STAR certificates. A server receiving a revocation
<section anchor="capability-discovery" title="Capability Discovery"> request for a STAR certificate <bcp14>MUST</bcp14> return an error
response with status code 403 (Forbidden) and type
<t>In order to support the discovery of STAR capabilities, the “meta” field insi "urn:ietf:params:acme:error:autoRenewalRevocationNotSupported".</t>
de </section>
the directory object defined in Section 9.7.6 of <xref target="RFC8555"/> is ext </section>
ended with a <section anchor="capability-discovery" numbered="true" toc="default">
new “auto-renewal” object. The “auto-renewal” object MUST be present if the <name>Capability Discovery</name>
server supports STAR. Its structure is as follows:</t> <t>In order to support the discovery of STAR capabilities, the "meta"
field inside the directory object defined in <xref
<t><list style="symbols"> target="RFC8555" sectionFormat="of" section="9.7.6"/> is extended with a
<t>min-lifetime (required, integer): minimum acceptable value for auto-renewal new
lifetime, in seconds.</t> "auto-renewal" object. The "auto-renewal" object <bcp14>MUST</bcp14>
<t>max-duration (required, integer): maximum delta between the auto-renewal en be present if the server supports STAR. Its structure is as
d-date and start-date, in seconds.</t> follows:</t>
<t>allow-certificate-get (optional, boolean): see <xref target="certificate-ge <ul spacing="compact">
t-nego"/>.</t> <li>min-lifetime (required, integer): Minimum acceptable value for
</list></t> auto-renewal lifetime, in seconds.</li>
<li>max-duration (required, integer): Maximum allowed delta between
<t>An example directory object advertising STAR support with one day min-lifetim the end-date and start-date attributes of the Order's auto-renewal
e and one year max-duration, and supporting certificate fetching with an HTTP GE object.</li>
T is shown in <xref target="figstardir"/>.</t> <li>allow-certificate-get (optional, boolean): See <xref
target="certificate-get-nego" format="default"/>.</li>
<figure title="Directory object with STAR support" anchor="figstardir"><artwork> </ul>
<![CDATA[ <t>An example directory object advertising STAR support with one-day
{ min-lifetime and one-year max-duration and supporting certificate
"new-nonce": "https://example.com/acme/new-nonce", fetching with an HTTP GET is shown in <xref target="figstardir"
"new-account": "https://example.com/acme/new-account", format="default"/>.</t>
"new-order": "https://example.com/acme/new-order", <figure anchor="figstardir">
"new-authz": "https://example.com/acme/new-authz", <name>Directory Object with STAR Support</name>
"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>
</section>
<section anchor="fetching-certificates" title="Fetching the Certificates">
<t>The certificate is fetched from the star-certificate endpoint with POST-as-GE <sourcecode type="JSON">
T {
as per <xref target="RFC8555"/> Section 7.4.2, unless client and server have "new-nonce": "https://example.com/acme/new-nonce",
successfully negotiated the “unauthenticated GET” option described in "new-account": "https://example.com/acme/new-account",
<xref target="certificate-get-nego"/>. In such case, the client can simply issu "new-order": "https://example.com/acme/new-order",
e a GET to "new-authz": "https://example.com/acme/new-authz",
the star-certificate resource without authenticating itself to the server as "revoke-cert": "https://example.com/acme/revoke-cert",
illustrated in <xref target="figunauthgetstarcert"/>.</t> "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
}
}
}
</sourcecode>
<figure title="Fetching a STAR certificate with unauthenticated GET" anchor="fig </figure>
unauthgetstarcert"><artwork><![CDATA[ </section>
<section anchor="fetching-certificates" numbered="true" toc="default">
<name>Fetching the Certificates</name>
<t>The certificate is fetched from the star-certificate endpoint with
POST-as-GET as per <xref target="RFC8555" sectionFormat="of"
section="7.4.2"/> unless the client and server have successfully
negotiated the "unauthenticated GET" option described in <xref
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" format="default"/>.</t>
<figure anchor="figunauthgetstarcert">
<name>Fetching a STAR Certificate with Unauthenticated GET</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
GET /acme/cert/g7m3ZQeTEqa HTTP/1.1 GET /acme/cert/g7m3ZQeTEqa HTTP/1.1
Host: example.org Host: example.com
Accept: application/pem-certificate-chain Accept: application/pem-certificate-chain
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/pem-certificate-chain Content-Type: application/pem-certificate-chain
Link: <https://example.com/acme/some-directory>;rel="index" Link: <https://example.com/acme/some-directory>;rel="index"
Cert-Not-Before: Thu, 3 Oct 2019 00:00:00 GMT Cert-Not-Before: Thu, 3 Oct 2019 00:00:00 GMT
Cert-Not-After: Thu, 10 Oct 2019 00:00:00 GMT Cert-Not-After: Thu, 10 Oct 2019 00:00:00 GMT
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
[End-entity certificate contents] [End-entity certificate contents]
-----END CERTIFICATE----- -----END CERTIFICATE-----
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
[Issuer certificate contents] [Issuer certificate contents]
-----END CERTIFICATE----- -----END CERTIFICATE-----
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
[Other certificate contents] [Other certificate contents]
-----END CERTIFICATE----- -----END CERTIFICATE-----
]]></artwork></figure> ]]></artwork>
</figure>
<t>The Server SHOULD include the “Cert-Not-Before” and “Cert-Not-After” HTTP hea <t>The server <bcp14>SHOULD</bcp14> include the "Cert-Not-Before" and
der fields in the response. "Cert-Not-After" HTTP header fields in the response. When they exist,
When they exist, they MUST be equal to the respective fields inside the end-enti they <bcp14>MUST</bcp14> be equal to the respective fields inside the
ty certificate. Their format is “HTTP-date” as defined in Section 7.1.1.2 of <xr end-entity certificate. Their format is "HTTP-date" as defined in
ef target="RFC7231"/>. <xref target="RFC7231" sectionFormat="of" section="7.1.1.2"/>. Their
Their purpose is to enable client implementations that do not parse the certific purpose is to enable client implementations that do not parse the
ate.</t> certificate.</t>
<t>The following are further clarifications regarding usage of these
<t>Following are further clarifications regarding usage of these header fields, header fields as per <xref target="RFC7231" sectionFormat="of"
as per <xref target="RFC7231"/> Sec. 8.3.1. section="8.3.1"/>. All apply to both headers.</t>
All apply to both headers.</t> <ul spacing="compact">
<li>This header field is a single value, not a list.</li>
<t><list style="symbols"> <li>The header field is used only in responses to GET, HEAD, and
<t>This header field is a single value, not a list.</t> POST-as-GET requests, and only for MIME types that denote public key
<t>The header field is used only in responses to GET, HEAD and POST-as-GET req certificates.</li>
uests, and only for MIME types that <li>Header field semantics are independent of context.</li>
denote public key certificates.</t> <li>The header field is not hop-by-hop.</li>
<t>Header field semantics are independent of context.</t> <li>Intermediaries <bcp14>MAY</bcp14> insert or delete the value;</li>
<t>The header field is not hop-by-hop.</t> <li>If an intermediary inserts the value, it <bcp14>MUST</bcp14>
<t>Intermediaries MAY insert or delete the value;</t> ensure that the newly added value matches the corresponding value in
<t>If an intermediary inserts the value, it MUST ensure that the newly added v the certificate.</li>
alue matches the corresponding value in the certificate.</t> <li>The header field is not appropriate for a Vary field.</li>
<t>The header field is not appropriate for a Vary field.</t> <li>The header field is allowed within message trailers.</li>
<t>The header field is allowed within message trailers.</t> <li>The header field is not appropriate within redirects.</li>
<t>The header field is not appropriate within redirects.</t> <li>The header field does not introduce additional security
<t>The header field does not introduce additional security considerations. It considerations. It discloses in a simpler form information that is
discloses in a simpler form information already available inside the certificate.</li>
that is already available inside the certificate.</t> </ul>
</list></t>
<t>To improve robustness, the next certificate MUST be made available by the ACM
E CA at the URL
pointed by “star-certificate” at the latest halfway through the lifetime of the
currently active certificate.
It is worth noting that this has an implication in case of cancellation: in fact
, from the time
the next certificate is made available, the cancellation is not completely effec
tive until the “next” certificate
also expires.
To avoid the client accidentally entering a broken state, the notBefore of the “
next” certificate MUST be set
so that the certificate is already valid when it is published at the “star-certi
ficate” URL. Note that the server
might need to increase the auto-renewal lifetime-adjust value to satisfy the lat
ter requirement.
For a detailed description of the renewal scheduling logic, see <xref target="co
mputing-effective-cert-lifetime"/>.
For further rationale on the need for adjusting the certificate validity, see <x
ref target="operational-cons-clocks"/>.</t>
<t>The server MUST NOT issue any certificates for this Order with notAfter after
the auto-renewal end-date.</t>
<t>For expired Orders, the server MUST respond with 403 (Forbidden) to any reque
sts to the star-certificate endpoint. The response SHOULD provide additional in
formation using a problem document <xref target="RFC7807"/> with type “urn:ietf:
params:acme:error:autoRenewalExpired”. Note that the Order resource’s state rema
ins “valid”, as per the base protocol.</t>
</section>
<section anchor="certificate-get-nego" title="Negotiating an unauthenticated GET
">
<t>In order to enable the name delegation workflow defined in
<xref target="I-D.ietf-acme-star-delegation"/> as well as to increase the reliab
ility of the
STAR ecosystem (see <xref target="dependability"/> for details), this document d
efines 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 acces
s
to a client’s Order star-certificate by setting the allow-certificate-get
attribute to true in the auto-renewal object of the meta field inside the
Directory object:</t>
<t><list style="symbols">
<t>allow-certificate-get (optional, boolean): If this field is present and set
to true, the server allows GET (and HEAD) requests to star-certificate URLs.</t>
</list></t>
<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 (optional, boolean): If this field is present and set
to true, the client requests the server to allow unauthenticated GET (and
HEAD) to the star-certificate associated with this Order.</t>
</list></t>
<t>If the server accepts the request, it MUST reflect the attribute setting in t
he resulting Order object.</t>
<t>Note that even when the use of unauthenticated GET has been agreed, the serve <t>To improve robustness, the next certificate <bcp14>MUST</bcp14> be made
r available by the ACME CA at the URL indicated by "star-certificate" halfway
MUST also allow POST-as-GET requests to the star-certificate resource.</t> through the lifetime of the currently active certificate at the latest. It is
worth noting that this has an implication in case of cancellation; in fact,
from the time the next certificate is made available, the cancellation is not
completely effective until the "next" certificate also expires. To avoid the
client accidentally entering a broken state, the notBefore of the "next"
certificate <bcp14>MUST</bcp14> be set so that the certificate is already
valid when it is published at the "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"
format="default"/>. For further rationale on the need for adjusting the
certificate validity, see <xref target="operational-cons-clocks"
format="default"/>.</t>
<t>The server <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 <bcp14>MUST</bcp14> respond with 403
(Forbidden) to any requests to the star-certificate endpoint. The
response <bcp14>SHOULD</bcp14> provide additional information using a
problem document <xref target="RFC7807" format="default"/> with type
"urn:ietf:params:acme:error:autoRenewalExpired". Note that the Order
resource's state remains "valid", as per the base protocol.</t>
</section>
</section> <section anchor="certificate-get-nego" numbered="true" toc="default">
<section anchor="computing-effective-cert-lifetime" title="Computing notBefore a <name>Negotiating an Unauthenticated GET</name>
nd notAfter of STAR Certificates"> <t>In order to enable the name delegation workflow defined in <xref
target="I-D.ietf-acme-star-delegation" format="default"/> and to
increase the reliability of the STAR ecosystem (see <xref
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>We define “nominal renewal date” as the point in time when a new short-term <t>Specifically, a server states its availability to grant
certificate for a given STAR Order is due. Its cadence is a multiple of the unauthenticated access to a client's Order star-certificate by setting
Order’s auto-renewal lifetime that starts with the issuance of the first the allow-certificate-get attribute to "true" in the auto-renewal object
short-term certificate and is upper-bounded by the Order’s auto-renewal of the meta field inside the directory object:</t>
end-date (<xref target="fignrd"/>).</t> <ul spacing="compact">
<li>allow-certificate-get (optional, boolean): If this field is
present and set to "true", the server allows GET (and HEAD) requests
to star-certificate 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>
<ul spacing="compact">
<li>allow-certificate-get (optional, boolean): If this field is
present and set to "true", the client requests the server to allow
unauthenticated GET (and HEAD) to the star-certificate associated
with this Order.</li>
</ul>
<t>If the server accepts the request, it <bcp14>MUST</bcp14> reflect
the attribute setting in the resulting order object.</t>
<figure title="Nominal Renewal Date" anchor="fignrd"><artwork><![CDATA[ <t>Note that even when the use of unauthenticated GET has been agreed
upon, the server <bcp14>MUST</bcp14> also allow POST-as-GET requests
to the star-certificate resource.</t>
</section>
<section anchor="computing-effective-cert-lifetime" numbered="true" toc="d
efault">
<name>Computing notBefore and notAfter of STAR Certificates</name>
<t>We define "nominal renewal 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 auto-renewal lifetime that starts with the
issuance of the first short-term certificate and is upper-bounded by
the Order's auto-renewal end-date (<xref target="fignrd"
format="default"/>).</t>
<figure anchor="fignrd">
<name>Nominal Renewal Date</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
T - STAR Order's auto-renewal lifetime T - STAR Order's auto-renewal lifetime
end - STAR Order's auto-renewal end-date end - STAR Order's auto-renewal end-date
nrd[i] - nominal renewal date of the i-th STAR certificate nrd[i] - nominal renewal date of the i-th STAR certificate
.- T -. .- T -. .- T -. .__. .- T -. .- T -. .- T -. .__.
/ \ / \ / \ / end / \ / \ / \ / end
-----------o---------o---------o---------o----X-------> t -----------o---------o---------o---------o----X-------> t
nrd[0] nrd[1] nrd[2] nrd[3] 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 <t>The rules to determine the notBefore and notAfter values of the i-th
STAR
certificate are as follows:</t> certificate are as follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
notAfter = min(nrd[i] + T, end) notAfter = min(nrd[i] + T, end)
notBefore = nrd[i] - max(adjust_client, adjust_server) notBefore = nrd[i] - max(adjust_client, adjust_server)
]]></artwork></figure> ]]></artwork>
<t>Where “adjust_client” is the min between the auto-renewal lifetime-adjust val
ue
(“la”), optionally supplied by the client, and the auto-renewal lifetime of
each short-term certificate (“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 of T
(i.e., f * T with .5 &lt;= f &lt; 1, see <xref target="fetching-certificates"/>)
:</t>
<figure><artwork><![CDATA[ <t>Where "adjust_client" is the minimum value between the auto-renewal
lifetime-adjust value ("la"), optionally supplied by the client, and
the auto-renewal lifetime of each short-term certificate ("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) of T (i.e., f
* T with .5 &lt;= f &lt; 1; see <xref target="fetching-certificates"
format="default"/>):</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
adjust_client = min(T, la) adjust_client = min(T, la)
adjust_server = f * T adjust_server = f * T
]]></artwork></figure> ]]></artwork>
<t>Note that the ACME server <bcp14>MUST NOT</bcp14> set the notBefore o
<t>Note that the ACME server MUST NOT set the notBefore of the first STAR f the first STAR
certificate to a date prior to the auto-renewal start-date.</t> certificate to a date prior to the auto-renewal start-date.</t>
<section anchor="example" numbered="true" toc="default">
<section anchor="example" title="Example"> <name>Example</name>
<t>Given a server that intends to publish the next STAR certificate ha
<t>Given a server that intends to publish the next STAR certificate halfway lfway
through the lifetime of the previous one, and a STAR Order with the following through the lifetime of the previous one, and a STAR Order with the following
attributes:</t> attributes:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
"auto-renewal": { "auto-renewal": {
"start-date": "2019-01-10T00:00:00Z", "start-date": "2019-01-10T00:00:00Z",
"end-date": "2019-01-20T00:00:00Z", "end-date": "2019-01-20T00:00:00Z",
"lifetime": 345600, // 4 days "lifetime": 345600, // 4 days
"lifetime-adjust": 259200 // 3 days "lifetime-adjust": 259200 // 3 days
} }
]]></artwork></figure> ]]></artwork>
<t>The amount of time that needs to be subtracted from each nominal re
<t>The amount of time that needs to be subtracted from each nominal renewal newal
date is 3 days – i.e., max(min(345600, 259200), 345600 * .5).</t> date is 3 days, i.e., max(min(345600, 259200), 345600 * .5).</t>
<t>The notBefore and notAfter of each short-term certificate are:</t>
<t>The notBefore and notAfter of each short-term certificate are:</t> <table align="center">
<thead>
<texttable> <tr>
<ttcol align='left'>notBefore</ttcol> <th align="left">notBefore</th>
<ttcol align='left'>notAfter</ttcol> <th align="left">notAfter</th>
<c>2019-01-10T00:00:00Z</c> </tr>
<c>2019-01-14T00:00:00Z</c> </thead>
<c>2019-01-11T00:00:00Z</c> <tbody>
<c>2019-01-18T00:00:00Z</c> <tr>
<c>2019-01-15T00:00:00Z</c> <td align="left">2019-01-10T00:00:00Z</td>
<c>2019-01-20T00:00:00Z</c> <td align="left">2019-01-14T00:00:00Z</td>
</texttable> </tr>
<tr>
<t>The value of the notBefore is also the time at which the client should expect <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 sho
uld expect
the new certificate to be available from the star-certificate endpoint.</t> the new certificate to be available from the star-certificate endpoint.</t>
</section>
</section>
</section>
<section anchor="operational-considerations" numbered="true" toc="default">
<name>Operational Considerations</name>
<section anchor="operational-cons-clocks" numbered="true" toc="default">
<name>The Meaning of "Short Term" and the Impact of Skewed Clocks</name>
<t>"Short Term" is a relative concept; therefore, trying to define a
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, 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.&nbsp;<xref target="ACER" format="default"/> find that one
of
the main causes of "HTTPS error" warnings in browsers is misconfigured
client clocks. In particular, they observe that roughly 95% of the
"severe" clock skews -- the 6.7% of clock-related breakage reports
that account for clients that are more than 24 hours behind -- happen
to be within 6-7 days.</t>
</section> <t>In order to avoid these spurious warnings about a not yet valid
</section> server certificate, site owners could use the auto-renewal
</section> lifetime-adjust attribute to control the effective lifetime of their
<section anchor="operational-considerations" title="Operational Considerations"> Web-facing certificates. The exact number depends on the percentage
of the "clock-skewed" population that the site owner expects to
<section anchor="operational-cons-clocks" title="The Meaning of “Short Term” and protect -- 5 days cover 97.3%, 7 days cover 99.6% -- as well as the
the Impact of Skewed Clocks"> nominal auto-renewal lifetime of the STAR Order. Note that exact
choice is also likely to depend on the kinds of client that are
<t>“Short Term” is a relative concept, therefore trying to define a cut-off poin prevalent for a given site or app -- for example, Android and Mac OS
t that works in all cases would be a useless exercise. In practice, the expecte clients are known to behave better than Windows clients. These
d lifetime of a STAR certificate will be counted in minutes, hours or days, depe considerations are clearly out of scope of this document.</t>
nding 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"/> find that one of the main causes of “HTTPS
error” warnings in browsers is misconfigured client clocks. In particular, they
observe that roughly 95% of the “severe” clock skews – the 6.7% of clock-relate
d breakage reports which 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) valid server cert
ificate, site owners could use the auto-renewal lifetime-adjust attribute to con
trol the effective lifetime of their Web facing certificates. The exact number
depends on the percentage of the “clock-skewed” population that the site owner e
xpects to protect – 5 days cover 97.3%, 7 days cover 99.6% – as well as the nomi
nal auto-renewal lifetime of the STAR Order. Note that exact choice is also lik
ely to depend on the kinds of client that is 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 document
.</t>
<t>In terms of security, STAR certificates and certificates with OCSP must-stapl
e <xref target="RFC7633"/> can be considered roughly equivalent if the STAR cert
ificate’s and the OCSP response’s lifetimes are the same. Given OCSP responses
can be cached on average for 4 days <xref target="Stark"/>, it is RECOMMENDED th
at a STAR certificate that is used on the Web has an “effective” lifetime (exclu
ding any adjustment to account for clock skews) no longer than 4 days.</t>
</section>
<section anchor="impact-on-certificate-transparency-ct-logs" title="Impact on Ce
rtificate Transparency (CT) Logs">
<t>Even in the highly unlikely case STAR becomes the only certificate issuance m
odel,
discussion with the IETF TRANS Working Group and Certificate Transparency (CT)
logs implementers suggests that existing CT Log Server implementations
are capable of sustaining the resulting 100-fold increase in ingestion
rate.  Additionally, such a future, higher load could be managed with a variety
of techniques (e.g., sharding by modulo of certificate hash, using “smart”
load-balancing CT proxies, etc.).  With regards to the increase in the log
size, current CT log growth is already being managed with schemes like Chrome’s
Log Policy <xref target="OBrien"/> which allow Operators to define their log lif
e-cycle; and
allowing the CAs, User Agents, Monitors, and any other interested entities to
build-in support for that life-cycle ahead of time.</t>
</section>
<section anchor="dependability" title="HTTP Caching and Dependability">
<t>When using authenticated POST-as-GET, the HTTPS endpoint from where the STAR
certificate is fetched 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
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"/> to mitigate the risk.</t>
<t>When using unauthenticated GET to fetch the STAR certificate, the server SHAL <t>In terms of security, STAR certificates and certificates with the
L Online Certificate Status Protocol (OCSP) "must-staple" flag asserted <x
ref
target="RFC7633" format="default"/> can be considered roughly
equivalent if the STAR certificate's and the OCSP 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, on averag
e, for 4
days <xref target="STARK" format="default"/>, it is
<bcp14>RECOMMENDED</bcp14> that a STAR certificate that is used on the
Web has an "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" numbered="tru
e" toc="default">
<name>Impact on Certificate Transparency (CT) 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 suggests that existin
g
CT Log server implementations are capable of sustaining the resulting
100-fold increase in ingestion rate. Additionally, such a future
higher load could be managed with a variety of techniques (e.g.,
sharding by modulo of certificate hash, using "smart" load-balancing
CT proxies, etc.). With regards to the increase in the log size,
current CT log growth is already being managed with schemes like
Chrome's Log Policy <xref target="OBRIEN" format="default"/>, which
allow Operators to define their log life cycle, as well as allowing the
CAs,
User Agents, Monitors, and any other interested entities to build in
support for that life cycle ahead of time.</t>
</section>
<section anchor="dependability" numbered="true" toc="default">
<name>HTTP Caching and Dependability</name>
<t>When using authenticated POST-as-GET, the HTTPS endpoint from where
the STAR certificate is fetched 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, 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"
format="default"/> to mitigate the risk.</t>
<t>When using unauthenticated GET to fetch the STAR certificate, the ser
ver <bcp14>SHALL</bcp14>
use the appropriate cache directives to set the freshness lifetime of the use the appropriate cache directives to set the freshness lifetime of the
response (Section 5.2 of <xref target="RFC7234"/>) such that on-path caches will consider response (<xref target="RFC7234" sectionFormat="of" section="5.2"/>) such that o n-path caches will consider
it stale before or at the time its effective lifetime is due to expire.</t> it stale before or at the time its effective lifetime is due to expire.</t>
</section>
</section>
</section> <section anchor="iana-considerations" numbered="true" toc="default">
</section> <name>IANA Considerations</name>
<section anchor="implementation-status" title="Implementation Status">
<t>Note to RFC Editor: please remove this section before publication,
including the reference to <xref target="RFC7942"/> and <xref target="I-D.sheffe
r-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 a proposal described in
<xref target="RFC7942"/>. The description of implementations in this section is
intended to assist the IETF in its decision processes in
progressing drafts to RFCs. Please note that the listing of any
individual implementation here does not imply endorsement by the
IETF. Furthermore, no effort has been spent to verify the
information presented here that was supplied by IETF contributors.
This is not intended as, and must not be construed to be, a
catalog of 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 the
benefit of running code, which may serve as evidence of valuable
experimentation and feedback that have made the implemented
protocols more mature. It is up to the individual working groups
to use this information as they see fit”.</t>
<section anchor="overview" title="Overview">
<t>The implementation is constructed around 3 elements: STAR Client for the Name
Delegation Client (NDC),
STAR Proxy for IdO and ACME Server for CA. The communication between
them is over an IP network and the HTTPS protocol.</t>
<t>The software of the implementation is available at: https://github.com/mami-p
roject/lurk</t>
<t>The following subsections offer a basic description, detailed information
is available in https://github.com/mami-project/lurk/blob/master/proxySTAR_v2/RE
ADME.md</t>
<section anchor="acme-server-with-star-extension" title="ACME Server with STAR e
xtension">
<t>This is a fork of the Let’s Encrypt Boulder project that implements an ACME c
ompliant CA.
It includes modifications to extend the ACME protocol as it is specified in this
draft,
to support recurrent Orders and cancelling Orders.</t>
<t>The implementation understands the new “recurrent” attributes as part of the
Certificate
issuance in the POST request for a new resource.
An additional process “renewalManager.go” has been included in parallel that rea
ds
the details of each recurrent request, automatically produces a “cron” Linux bas
ed task
that issues the recurrent certificates, until the lifetime ends or the Order is
canceled.
This process is also in charge of maintaining a fixed URI to enable the NDC to d
ownload 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 i
s a fork of the EFF
Certbot project that implements an ACME compliant client with the STAR extension
.
The latter is a basic HTTP REST API server.</t>
<t>The STAR Proxy understands the basic API request with a server. The current i
mplementation
of the API is defined in draft-ietf-acme-star-01. Registration or Order cancella
tion
triggers the modified Certbot client that requests, or cancels, the recurrent ge
neration
of certificates using the STAR extension over ACME protocol.
The URI with the location of the recurrent certificate is delivered to the STAR
client as a response.</t>
</section>
</section>
<section anchor="level-of-maturity" title="Level of Maturity">
<t>This is a prototype.</t>
</section>
<section anchor="coverage" title="Coverage">
<t>A STAR Client is not included in this implementation, but done by direct HTTP
request with any open HTTP REST API tool.
This is expected to be covered as part of the <xref target="I-D.sheffer-acme-sta
r-request"/> implementation.</t>
<t>This implementation completely covers STAR Proxy and ACME Server with STAR ex
tension.</t>
</section>
<section anchor="version-compatibility" title="Version Compatibility">
<t>The implementation is compatible with version draft-ietf-acme-star-01.
The implementation is based on the Boulder and Certbot code release from 7-Aug-2
017.</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 the concept all the implementation has been done with a self-signed
CA,
to avoid impact on real domains. To be able to do it we use the FAKE_DNS propert
y
of Boulder and static /etc/hosts entries with domains names.
Nonetheless this implementation should run with real domains.</t>
<t>Most of the implementation has been made to avoid deep changes inside of Boul
der
or Certbot, for example, the recurrent certificates issuance by the CA is based
on an external process that auto-configures the standard Linux “cron” daemon in
the ACME CA server.</t>
<t>The reference setup recommended is one physical host with 3 virtual machines,
one for each of the 3 components (client, proxy and server) and the connectivity
based on host bridge.</t>
<t>Network security is not enabled (iptables default policies are “accept” and a
ll rules removed)
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 that IANA create the following new registries:</t>
<t><list style="symbols">
<t>ACME Order Auto Renewal Fields (<xref target="iana-order-auto-renewal-regis
try"/>)</t>
<t>ACME Directory Metadata Auto Renewal Fields (<xref target="iana-metadata-au
to-renewal-registry"/>)</t>
</list></t>
<t>All of these registries are administered under a Specification Required polic
y
<xref target="RFC8126"/>.</t>
</section>
<section anchor="new-error-types" title="New Error Types">
<t>This document adds the following entries 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-rene
wal Order has been explicitly canceled by the IdO</c>
<c>RFC XXXX</c>
<c>autoRenewalExpired</c>
<c>The short-term certificate is no longer available because the auto-rene
wal Order has expired</c>
<c>RFC XXXX</c>
<c>autoRenewalCancellationInvalid</c>
<c>A request to cancel a auto-renewal Order that is not in state “valid” h
as 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 in Order Objects
">
<t>This document adds the following entries to the ACME Order Object Fields regi
stry:</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 in the “auto-re
newal” Object within an Order Object">
<t>The “ACME Order Auto Renewal Fields” registry lists field names that are <section anchor="new-registries" numbered="true" toc="default">
defined for use in the JSON object included in the “auto-renewal” field of an <name>New Registries</name>
<t>Per this document, IANA has created the following new registries:</t>
<ul spacing="compact">
<li>ACME Order Auto-Renewal Fields (<xref target="iana-order-auto-rene
wal-registry" format="default"/>)</li>
<li>ACME Directory Metadata Auto-Renewal Fields (<xref target="iana-me
tadata-auto-renewal-registry" format="default"/>)</li>
</ul>
<t>These registries are administered under a Specification Required poli
cy
<xref target="RFC8126" format="default"/>.</t>
</section>
<section anchor="new-error-types" numbered="true" toc="default">
<name>New Error Types</name>
<t>Per this document, IANA has added the following entries to the "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 longer available
because the auto-renewal Order has been explicitly canceled by the IdO</td>
<td align="left">RFC 8739</td>
</tr>
<tr>
<td align="left">autoRenewalExpired</td>
<td align="left">The short-term certificate is no longer available
because the 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 is
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 bee
n 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 following entries to 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="iana-order-auto-renewal-registry" numbered="true" toc="de
fault">
<name>Fields in the "auto-renewal" Object within an Order Object</name>
<t>The "ACME Order Auto-Renewal Fields" registry lists field names that
are
defined for use in the JSON object included in the "auto-renewal" field of an
ACME order object.</t> ACME order object.</t>
<t>Template:</t>
<ul spacing="compact">
<li>Field name: The string to be used as a field name in the JSON obje
ct</li>
<li>Field type: The type of value to be provided, e.g., string, boolea
n, array of
string</li>
<li>Configurable: Boolean indicating whether the 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 "meta" Object within a Directory Object</name>
<t>Per this document, IANA has added the following entry to the "ACME Di
rectory 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 the "auto-renewal" Object within a Directory Metadata Ob
ject</name>
<t>The "ACME Directory Metadata Auto-Renewal Fields" registry lists fiel
d names
that are defined for use in the JSON object included in the "auto-renewal"
field of an ACME directory "meta" object.</t>
<t>Template:</t>
<ul spacing="compact">
<li>Field name: The string to be used as a field name in the JSON obje
ct</li>
<li>Field type: The type of value to be provided, e.g., string, boolea
n, array of
string</li>
<li>Reference: Where this field is defined</li>
</ul>
<t>Initial contents: The fields and descriptions defined in <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 following ad
ditional 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" fo
rmat="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" fo
rmat="default"/></td>
</tr>
</tbody>
</table>
</section>
</section>
<section anchor="security-considerations" numbered="true" toc="default">
<name>Security Considerations</name>
<section anchor="no-revocation" numbered="true" toc="default">
<name>No Revocation</name>
<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"
format="default"/>.</t>
<t>It should be noted that revocation also has timeliness issues
because both Certificate Revocation Lists (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 a
start-date of 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"
format="default"/>). So, if an attacker manages to get hold of the
private key as well as 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
<bcp14>RECOMMENDED</bcp14> 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" format="default"/>.</t>
</section>
<section anchor="denial-of-service-considerations" numbered="true" toc="de
fault">
<name>Denial-of-Service Considerations</name>
<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 second) jointly with other ACME
attack vectors identified in <xref target="RFC8555"
sectionFormat="of" section="10"/>. 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>Template:</t> <t>Mitigation recommendations from ACME still apply, but some of them
need to be adjusted. For example, applying rate limiting to the
<t><list style="symbols"> initial request, due to the nature of the auto-renewal behavior,
<t>Field name: The string to be used as a field name in the JSON object</t> cannot solve the above problem. The CA server needs complementary
<t>Field type: The type of value to be provided, e.g., string, boolean, array mitigation, and specifically, it <bcp14>SHOULD</bcp14> enforce a
of minimum value on auto-renewal "lifetime". Alternatively, the CA can
string</t> set a rate limit for internal certificate generation processes. Note
<t>Configurable: Boolean indicating whether the server should accept values that this limit has to take account of already scheduled renewal
provided by the client</t> issuances as well as new incoming requests.</t>
<t>Reference: Where this field is defined</t> </section>
</list></t>
<t>Initial contents: The fields and descriptions defined in <xref target="star-o
rder-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 the “meta” Object within a Directory Object">
<t>This document adds the following entry to the 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 in 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 the JSON object included in the “auto-renewal”
field of an ACME directory “meta” object.</t>
<t>Template:</t>
<t><list style="symbols">
<t>Field name: The string to be used as a field name in the JSON object</t>
<t>Field type: The type of value to be provided, e.g., string, boolean, array
of
string</t>
<t>Reference: Where this field is defined</t>
</list></t>
<t>Initial contents: The fields and descriptions defined in <xref target="capabi
lity-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>
</section>
<section anchor="iana-http-headers" title="Cert-Not-Before and Cert-Not-After HT
TP Headers">
<t>The “Message Headers” registry should be updated with the following additiona
l 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 (R
Ps) 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 Cons
iderations">
<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 coll
ateral 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> <section anchor="privacy-considerations" numbered="true" toc="default">
<name>Privacy Considerations</name>
<t>In order to avoid correlation of certificates by account, if
unauthenticated GET is negotiated (<xref target="certificate-get-nego"
format="default"/>), the recommendation in <xref target="RFC8555"
sectionFormat="of" section="10.5"/> regarding the choice of URL
structure applies, i.e., servers <bcp14>SHOULD</bcp14> choose URLs of
certificate resources in a non-guessable way, for example, using
capability URLs <xref target="W3C.CAPABILITY-URLS"
format="default"/>.</t>
</section>
</section>
</middle> </middle>
<back> <back>
<references title='Normative References'> <displayreference target="I-D.ietf-acme-star-delegation" to="STAR-DELEGATION"/>
<displayreference target="I-D.nir-saag-star" to="SHORT-TERM-CERTS"/>
<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 Comm
unity, 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 /></auth
or>
<author initials='C.' surname='Newman' fullname='C. Newman'><organization /></au
thor>
<date year='2002' month='July' />
<abstract><t>This document defines a date and time format for use in Internet pr
otocols that is a profile of the ISO 8601 standard for representation of dates a
nd 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'><o
rganization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><org
anization /></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 reque
st methods, request header fields, response status codes, and response header fi
elds, along with the payload of messages (metadata and body content) and mechani
sms 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'><organizatio
n /></author>
<author initials='E.' surname='Wilde' fullname='E. Wilde'><organization /></auth
or>
<date year='2016' month='March' />
<abstract><t>This document defines a &quot;problem detail&quot; as a way to carr
y machine- readable details of errors in a HTTP response to avoid the need to de
fine 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 /></au
thor>
<author initials='J.' surname='Hoffman-Andrews' fullname='J. Hoffman-Andrews'><o
rganization /></author>
<author initials='D.' surname='McCarney' fullname='D. McCarney'><organization />
</author>
<author initials='J.' surname='Kasten' fullname='J. Kasten'><organization /></au
thor>
<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 domai
n name(s) in the certificate. As of this writing, this verification is done thr
ough 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 certi
ficate issuance. The protocol also provides facilities for other certificate ma
nagement 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 /></auth
or>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s
pecifications. This document aims to reduce the ambiguity by clarifying that on
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs
tract>
</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'><o
rganization /></author>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham' role='editor
'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><org
anization /></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 /></au
thor>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></auth
or>
<author initials='T.' surname='Narten' fullname='T. Narten'><organization /></au
thor>
<date year='2017' month='June' />
<abstract><t>Many protocols make use of points of extensibility that use constan
ts to identify various protocol parameters. To ensure that the values in these
fields do not have conflicting uses and to promote interoperability, their alloc
ations are often coordinated by a central record keeper. For IETF protocols, th
at role is filled by the Internet Assigned Numbers Authority (IANA).</t><t>To ma
ke assignments in a given registry prudently, guidance describing the conditions
under which new values should be assigned, as well as when and how modification
s 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 addre
sses the various issues that are likely in the operation of a registry.</t><t>Th
is 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</t
itle>
<author initials='Y.' surname='Sheffer' fullname='Y. Sheffer'><organization /></
author>
<author initials='A.' surname='Farrel' fullname='A. Farrel'><organization /></au
thor>
<date year='2016' month='July' />
<abstract><t>This document describes a simple process that allows authors of Int
ernet-Drafts to record the status of known implementations by including an Imple
mentation Status section. This will allow reviewers and working groups to assig
n due consideration to documents that have the benefit of running code, which ma
y 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 docum
ents, and working groups are invited to think about applying the process to all
of their protocol specifications. This document obsoletes RFC 6982, advancing i
t 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'><organiz
ation /></author>
<date year='2015' month='October' />
<abstract><t>The purpose of the TLS feature extension is to prevent downgrade at
tacks that are not otherwise prevented by the TLS protocol. In particular, the
TLS feature extension may be used to mandate support for revocation checking fea
tures in the TLS protocol such as Online Certificate Status Protocol (OCSP) stap
ling. Informing clients that an OCSP status response will always be stapled per
mits 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 (ST
AR) 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 de
legate to a third party (such as a CDN) control over a certificate that bears on
e or more names in that domain. Specifically the third party creates a Certific
ate Signing Request for the domain, which can then be used by the domain owner t
o 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 sess
ions 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 to rely on certific
ate 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-requ
est-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 of the ACME protocol that allows the o
wner 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 provide
r (the owner of a domain name). The presented mechanism allows the owner of the
identifier to retain control over the delegation and revoke it at any time by c
ancelling the associated STAR certificate renewal with the ACME CA. Another key
property of this mechanism is it does not require any modification to the deploy
ed 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-delegat
ion-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 in an old idea: Issue cert <references>
ificates with short validity periods and forego revocation processing, reasoning <name>References</name>
that expiration is a sufficient replacement for revocation as long as that expi <references>
ration is not too far off. This document covers considerations, both security a <name>Normative References</name>
nd operational, for using such Short Term Auto Renewed (STAR) certificates for v <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
arious scenarios where Using a revocation protocol is considered inappropriate.< FC.2119.xml"/>
/t></abstract> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3339.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7231.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7807.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8555.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7234.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8126.xml"/>
</references>
<references>
<name>Informative References</name>
</front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7633.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6066.xml"/>
<seriesInfo name='Internet-Draft' value='draft-nir-saag-star-01' /> <!--I-D.draft-ietf-acme-star-delegation-01; IESG state I-D Exists -->
<format type='TXT' <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.
target='http://www.ietf.org/internet-drafts/draft-nir-saag-star-01.txt' I-D.ietf-acme-star-delegation.xml"/>
/>
</reference>
<reference anchor="Stark" target="http://crypto.stanford.edu/~dabo/pubs/abstract <!--I-D.draft-nir-saag-star; IESG state Expired -->
s/ssl-prefetch.html"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.
<front> I-D.nir-saag-star.xml"/>
<title>The case for prefetching and prevalidating TLS server certificates</t
itle>
<author initials="E." surname="Stark" fullname="Emily Stark">
<organization>Google</organization>
</author>
<author initials="L." 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 year="2012"/>
</front>
</reference>
<reference 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>
<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 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">
<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." 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" 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 year="2017"/>
</front>
</reference>
<reference anchor="W3C.WD-capability-urls-20140218" <reference anchor="STARK" target="https://crypto.stanford.edu/~dabo/pubs
target='http://www.w3.org/TR/2014/WD-capability-urls-20140218'> /abstracts/ssl-prefetch.html">
<front> <front>
<title>Good Practices for Capability URLs</title> <title>The case for prefetching and prevalidating TLS server certifi
cates</title>
<author initials="E." surname="Stark" fullname="Emily Stark">
<organization>Google</organization>
</author>
<author 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>
<author initials='J.' surname='Tennison' fullname='Jeni Tennison'> <reference anchor="ACER" target="https://acmccs.github.io/papers/p1407-a
<organization /> cerA.pdf">
</author> <front>
<title>Where the Wild Warnings Are: Root Causes of Chrome HTTPS Cert
ificate 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 Fel
t">
<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 Hy
derabad</organization>
</author>
<author initials="M." surname="Braithwaite" fullname="Matt Braithwai
te">
<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>
</reference>
<date month='February' day='18' year='2014' /> <reference anchor="TOPALOVIC" target="https://www.ieee-security.org/TC/W
</front> 2SP/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.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>
<seriesInfo name='World Wide Web Consortium WD' value='WD-capability-urls-201402 <reference anchor="OBRIEN" target="https://github.com/chromium/ct-policy
18' /> ">
<format type='HTML' target='http://www.w3.org/TR/2014/WD-capability-urls-2014021 <front>
8' /> <title>Chromium Certificate Transparency Policy</title>
</reference> <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.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/>
</author>
<date month="February" year="2014"/>
</front>
<refcontent>W3C First Public Working Draft</refcontent>
<refcontent>Latest version available at &lt;https://www.w3.org/TR/capability-url
s/&gt;
</refcontent>
</reference>
</references>
</references> </references>
<section anchor="document-history" title="Document History"> <section anchor="acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>[[Note to RFC Editor: please remove before publication.]]</t> <t>This work is partially supported by the European Commission under
Horizon 2020 grant agreement no. 688421 Measurement and Architecture for
<section anchor="draft-ietf-acme-star-11" title="draft-ietf-acme-star-11"> a Middleboxed Internet (MAMI). This support does not imply
endorsement.</t>
<t><list style="symbols"> <t>Thanks to <contact fullname="Ben Kaduk"/>, <contact fullname="Richard
<t>One more nit re: random URL</t> Barnes"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Jon
</list></t> Peterson"/>, <contact fullname="Eric Rescorla"/>, <contact
fullname="Ryan Sleevi"/>, <contact fullname="Sean Turner"/>, <contact
</section> fullname="Alexey Melnikov"/>, <contact fullname="Adam Roach"/>, <contact
<section anchor="draft-ietf-acme-star-10" title="draft-ietf-acme-star-10"> fullname="Martin Thomson"/>, and <contact fullname="Mehmet Ersue"/> for he
lpful comments and
<t>IESG processing:</t> discussions that have shaped this document.</t>
</section>
<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 the following updates:</t>
<t><list style="symbols">
<t>STAR Order and Directory Meta attributes renamed slightly and grouped under
two brand new “auto-renewal” objects;</t>
<t>IANA registration updated accordingly (note that two new registries have be
en added as a consequence);</t>
<t>Unbounded pre-dating of certificates removed so that STAR certs are never i
ssued 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 rev
iew.</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, followi
ng 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 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 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 Own
er (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 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 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 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>
</section>
</back> </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> </rfc>
 End of changes. 70 change blocks. 
1971 lines changed or deleted 1073 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/