Script updating gh-pages from 9671033. [ci skip]

Author: ID Bot

link-rel-bikeshed/draft-ietf-plants-merkle-tree-certs.html

@@ -5124,8 +5124,9 @@ <h3 id="name-optional-certificates">
 <a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-optional-certificates" class="section-name selfRef">Optional Certificates</a>
         </h3>
 <p id="section-9.1-1"><span><a href="https://rfc-editor.org/rfc/rfc8555#section-7.4.2" class="relref">Section 7.4.2</a> of [<a href="#RFC8555" class="cite xref">RFC8555</a>]</span> describes how an ACME server uses the "alternate" link relation <span>[<a href="#RFC8288" class="cite xref">RFC8288</a>]</span> to serve multiple certificate chains for an ACME order. An ACME client might fetch all of them and deploy them in the authenticating party. Different relying parties need different chains, so the ACME client might reasonably treat any unavailable alternate as an error.<a href="#section-9.1-1" class="pilcrow">¶</a></p>
-<p id="section-9.1-2">This behavior is not ideal for landmark-relative certificates, which are available asynchronously and should not block deployment of their corresponding standalone certificate. This section defines the "acme-optional-alternate" link relation. When serving a certificate, an ACME server MAY provide one or more link relation header fields of type "acme-optional-alternate". "acme-optional-alternate" identifies an alternate certificate chain, but one that is optional. Relying parties that accept the optional alternate are expected to also accept either the original certificate chain or chains served under the "alternate" link relation.  If the certificate chain is not yet available, the "acme-optional-alternate" URL MAY serve an HTTP 202 (Accepted) response, with a Retry-After header (<span><a href="https://rfc-editor.org/rfc/rfc9110#section-10.2.3" class="relref">Section 10.2.3</a> of [<a href="#RFC9110" class="cite xref">RFC9110</a>]</span>) estimating when it will become available.<a href="#section-9.1-2" class="pilcrow">¶</a></p>
-<p id="section-9.1-3">An ACME client MAY fetch these URLs to collect additional alternate certificate chains. If the resource is unavailable, the ACME client SHOULD NOT fail the overall transaction. If the resource returns an HTTP 202 (Accepted) response, the ACME client SHOULD retry the request later, incorporating any Retry-After header, but it SHOULD NOT block deployment of other chains on this process.<a href="#section-9.1-3" class="pilcrow">¶</a></p>
+<p id="section-9.1-2">This behavior is not ideal for a landmark-relative certificate, which is available asynchronously and is not intended to delay the corresponding standalone certificate. This section defines the "acme-optional-alternate" link relation. When serving a certificate, an ACME server MAY provide one or more link relation header fields of type "acme-optional-alternate". "acme-optional-alternate" identifies an alternate certificate chain, but one that is optional. Relying parties that accept the optional alternate are expected to also accept either the original certificate chain or chains served under the "alternate" link relation. If the certificate chain is not yet available, the "acme-optional-alternate" URL MAY serve an HTTP 202 (Accepted) response, with a Retry-After header (<span><a href="https://rfc-editor.org/rfc/rfc9110#section-10.2.3" class="relref">Section 10.2.3</a> of [<a href="#RFC9110" class="cite xref">RFC9110</a>]</span>) estimating when it will become available.<a href="#section-9.1-2" class="pilcrow">¶</a></p>
+<p id="section-9.1-3">An ACME client MAY fetch these URLs to collect additional alternate certificate chains. If the resource is unavailable, the ACME client SHOULD NOT fail the overall transaction. If the resource returns an HTTP 202 (Accepted) response, the ACME client SHOULD retry the request later, incorporating any Retry-After header, but this process SHOULD be independent of deploying other chains in the ACME order. In particular, if deploying a new service, the ACME client SHOULD NOT block deployment on optional alternates.<a href="#section-9.1-3" class="pilcrow">¶</a></p>
+<p id="section-9.1-4">If renewing certificates, the ACME client MAY opt to wait for optional alternates to simplify certificate replacement, but only while the previous certificates remain valid.<a href="#section-9.1-4" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="using-acme-with-merkle-tree-certificates">

link-rel-bikeshed/draft-ietf-plants-merkle-tree-certs.txt

@@ -2688,8 +2688,8 @@ Table of Contents
    need different chains, so the ACME client might reasonably treat any
    unavailable alternate as an error.
 
-   This behavior is not ideal for landmark-relative certificates, which
-   are available asynchronously and should not block deployment of their
+   This behavior is not ideal for a landmark-relative certificate, which
+   is available asynchronously and is not intended to delay the
    corresponding standalone certificate.  This section defines the
    "acme-optional-alternate" link relation.  When serving a certificate,
    an ACME server MAY provide one or more link relation header fields of
@@ -2706,8 +2706,14 @@ Table of Contents
    certificate chains.  If the resource is unavailable, the ACME client
    SHOULD NOT fail the overall transaction.  If the resource returns an
    HTTP 202 (Accepted) response, the ACME client SHOULD retry the
-   request later, incorporating any Retry-After header, but it SHOULD
-   NOT block deployment of other chains on this process.
+   request later, incorporating any Retry-After header, but this process
+   SHOULD be independent of deploying other chains in the ACME order.
+   In particular, if deploying a new service, the ACME client SHOULD NOT
+   block deployment on optional alternates.
+
+   If renewing certificates, the ACME client MAY opt to wait for
+   optional alternates to simplify certificate replacement, but only
+   while the previous certificates remain valid.
 
 9.2.  Using ACME with Merkle Tree Certificates