|
1051 | 1051 | </tr></thead> |
1052 | 1052 | <tfoot><tr> |
1053 | 1053 | <td class="left">Benjamin, et al.</td> |
1054 | | -<td class="center">Expires 26 December 2026</td> |
| 1054 | +<td class="center">Expires 31 December 2026</td> |
1055 | 1055 | <td class="right">[Page]</td> |
1056 | 1056 | </tr></tfoot> |
1057 | 1057 | </table> |
|
1064 | 1064 | <dd class="internet-draft">draft-ietf-plants-merkle-tree-certs-latest</dd> |
1065 | 1065 | <dt class="label-published">Published:</dt> |
1066 | 1066 | <dd class="published"> |
1067 | | -<time datetime="2026-06-24" class="published">24 June 2026</time> |
| 1067 | +<time datetime="2026-06-29" class="published">29 June 2026</time> |
1068 | 1068 | </dd> |
1069 | 1069 | <dt class="label-intended-status">Intended Status:</dt> |
1070 | 1070 | <dd class="intended-status">Standards Track</dd> |
1071 | 1071 | <dt class="label-expires">Expires:</dt> |
1072 | | -<dd class="expires"><time datetime="2026-12-26">26 December 2026</time></dd> |
| 1072 | +<dd class="expires"><time datetime="2026-12-31">31 December 2026</time></dd> |
1073 | 1073 | <dt class="label-authors">Authors:</dt> |
1074 | 1074 | <dd class="authors"> |
1075 | 1075 | <div class="author"> |
@@ -1135,7 +1135,7 @@ <h2 id="name-status-of-this-memo"> |
1135 | 1135 | time. It is inappropriate to use Internet-Drafts as reference |
1136 | 1136 | material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p> |
1137 | 1137 | <p id="section-boilerplate.1-4"> |
1138 | | - This Internet-Draft will expire on 26 December 2026.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p> |
| 1138 | + This Internet-Draft will expire on 31 December 2026.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p> |
1139 | 1139 | </section> |
1140 | 1140 | </div> |
1141 | 1141 | <div id="copyright"> |
@@ -1342,6 +1342,14 @@ <h2 id="name-copyright-notice"> |
1342 | 1342 | </li> |
1343 | 1343 | <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9"> |
1344 | 1344 | <p id="section-toc.1-1.9.1"><a href="#section-9" class="auto internal xref">9</a>. <a href="#name-acme-extensions" class="internal xref">ACME Extensions</a></p> |
| 1345 | +<ul class="compact toc ulBare ulEmpty"> |
| 1346 | +<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.1"> |
| 1347 | + <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="auto internal xref">9.1</a>. <a href="#name-enhancement-link-relation" class="internal xref">Enhancement Link Relation</a></p> |
| 1348 | +</li> |
| 1349 | + <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.2"> |
| 1350 | + <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="auto internal xref">9.2</a>. <a href="#name-using-acme-with-merkle-tree" class="internal xref">Using ACME with Merkle Tree Certificates</a></p> |
| 1351 | +</li> |
| 1352 | + </ul> |
1345 | 1353 | </li> |
1346 | 1354 | <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10"> |
1347 | 1355 | <p id="section-toc.1-1.10.1"><a href="#section-10" class="auto internal xref">10</a>. <a href="#name-deployment-considerations" class="internal xref">Deployment Considerations</a></p> |
@@ -1428,6 +1436,9 @@ <h2 id="name-copyright-notice"> |
1428 | 1436 | </li> |
1429 | 1437 | <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13.2.4"> |
1430 | 1438 | <p id="section-toc.1-1.13.2.4.1"><a href="#section-13.4" class="auto internal xref">13.4</a>. <a href="#name-relative-distinguished-name" class="internal xref">Relative Distinguished Name Attribute</a></p> |
| 1439 | +</li> |
| 1440 | + <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13.2.5"> |
| 1441 | + <p id="section-toc.1-1.13.2.5.1"><a href="#section-13.5" class="auto internal xref">13.5</a>. <a href="#name-link-relation-type" class="internal xref">Link Relation Type</a></p> |
1431 | 1442 | </li> |
1432 | 1443 | </ul> |
1433 | 1444 | </li> |
@@ -5102,10 +5113,28 @@ <h2 id="name-acme-extensions"> |
5102 | 5113 | <a href="#section-9" class="section-number selfRef">9. </a><a href="#name-acme-extensions" class="section-name selfRef">ACME Extensions</a> |
5103 | 5114 | </h2> |
5104 | 5115 | <p id="section-9-1">This section describes how to issue Merkle Tree certificates using ACME <span>[<a href="#RFC8555" class="cite xref">RFC8555</a>]</span>.<a href="#section-9-1" class="pilcrow">¶</a></p> |
5105 | | -<p id="section-9-2">When downloading the certificate (<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>), ACME clients supporting Merkle Tree certificates SHOULD send "application/pem-certificate-chain-with-properties" in their Accept header (<span><a href="https://rfc-editor.org/rfc/rfc9110#section-12.5.1" class="relref">Section 12.5.1</a> of [<a href="#RFC9110" class="cite xref">RFC9110</a>]</span>). ACME servers issuing Merkle Tree certificates SHOULD then respond with that content type and include trust anchor ID information as described in <span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-tls-trust-anchor-ids-04#section-7" class="relref">Section 7</a> of [<a href="#I-D.ietf-tls-trust-anchor-ids" class="cite xref">I-D.ietf-tls-trust-anchor-ids</a>]</span>. <a href="#use-in-tls" class="auto internal xref">Section 8</a> decribes the trust anchor ID assignments for standalone and landmark-relative certificates.<a href="#section-9-2" class="pilcrow">¶</a></p> |
5106 | | -<p id="section-9-3">When processing an order for a Merkle Tree certificate, the ACME server moves the order to the "valid" state after the corresponding entry is sequenced in the issuance log, cosignatures are collected, and the standalone certificate is available. The order's certificate URL then serves the standalone certificate, constructed as described in <a href="#standalone-certificates" class="auto internal xref">Section 6.3</a>.<a href="#section-9-3" class="pilcrow">¶</a></p> |
5107 | | -<p id="section-9-4">The standalone certificate response SHOULD additionally carry an alternate URL for the landmark-relative certificate, as described <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>. Before the landmark-relative certificate is available, the alternate URL SHOULD return a HTTP 503 (Service Unavailable) 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 the certificate will become available. Once the next landmark is allocated, the ACME server constructs a landmark-relative certificate, as described in <a href="#landmark-relative-certificates" class="auto internal xref">Section 6.4</a> and serves it from the alternate URL.<a href="#section-9-4" class="pilcrow">¶</a></p> |
5108 | | -<p id="section-9-5">ACME clients supporting Merkle Tree certificates SHOULD support fetching alternate chains. If an alternate chain returns an HTTP 503 with a Retry-After header, as described above, the client SHOULD retry the request at the specified time.<a href="#section-9-5" class="pilcrow">¶</a></p> |
| 5116 | +<div id="enhancement-link-relation"> |
| 5117 | +<section id="section-9.1"> |
| 5118 | + <h3 id="name-enhancement-link-relation"> |
| 5119 | +<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-enhancement-link-relation" class="section-name selfRef">Enhancement Link Relation</a> |
| 5120 | + </h3> |
| 5121 | +<p id="section-9.1-1">This section introduces a new link relation <span>[<a href="#RFC8288" class="cite xref">RFC8288</a>]</span>, "enhancement". It identifies an optional substitute for the original context. This substitute may be preferable in some way (e.g. it may be smaller) but is optional. Consumers that accept the substitute are expected to also accept the original context, so it is not an error if the resource is unavailable.<a href="#section-9.1-1" class="pilcrow">¶</a></p> |
| 5122 | +<p id="section-9.1-2">This is similar to the "alternate" link relation, except that it specifies the substitute is optional. In some applications, a client may fetch all alternates, so that it may forward one of the alternates to another party. For example, <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 to serve multiple certificate chains for an ACME order. An ACME client might then fetch all of them and configure them in a TLS server, which presents them to TLS clients. Different TLS clients need different chains, so the ACME client might reasonably treat any unavailable alternate as an error.<a href="#section-9.1-2" class="pilcrow">¶</a></p> |
| 5123 | +<p id="section-9.1-3">This behavior is not ideal for landmark-relative certificates, which are available asynchronously and should not block deployment of their corresponding standalone certificate. The "enhancement" link relation allows an ACME server to specify which chains are necessary to fulfill the ACME order and which are optional additions.<a href="#section-9.1-3" class="pilcrow">¶</a></p> |
| 5124 | +<p id="section-9.1-4">When serving a certificate, an ACME server MAY provide one or more link relation header fields with relation "enhancement". Each such field SHOULD express a certificate chain that the ACME server expects to be redundant with (but potentially preferable to) either the original certificate chain or one of the chains served from an "alternate" relation. If the certificate chain is not yet available, the enhancement 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-4" class="pilcrow">¶</a></p> |
| 5125 | +<p id="section-9.1-5">ACME clients can fetch enhancement 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-5" class="pilcrow">¶</a></p> |
| 5126 | +</section> |
| 5127 | +</div> |
| 5128 | +<div id="using-acme-with-merkle-tree-certificates"> |
| 5129 | +<section id="section-9.2"> |
| 5130 | + <h3 id="name-using-acme-with-merkle-tree"> |
| 5131 | +<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-using-acme-with-merkle-tree" class="section-name selfRef">Using ACME with Merkle Tree Certificates</a> |
| 5132 | + </h3> |
| 5133 | +<p id="section-9.2-1">When downloading the certificate (<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>), ACME clients supporting Merkle Tree certificates SHOULD send "application/pem-certificate-chain-with-properties" in their Accept header (<span><a href="https://rfc-editor.org/rfc/rfc9110#section-12.5.1" class="relref">Section 12.5.1</a> of [<a href="#RFC9110" class="cite xref">RFC9110</a>]</span>). ACME servers issuing Merkle Tree certificates SHOULD then respond with that content type and include trust anchor ID information as described in <span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-tls-trust-anchor-ids-04#section-7" class="relref">Section 7</a> of [<a href="#I-D.ietf-tls-trust-anchor-ids" class="cite xref">I-D.ietf-tls-trust-anchor-ids</a>]</span>. <a href="#use-in-tls" class="auto internal xref">Section 8</a> describes the trust anchor ID assignments for standalone and landmark-relative certificates.<a href="#section-9.2-1" class="pilcrow">¶</a></p> |
| 5134 | +<p id="section-9.2-2">When processing an order for a Merkle Tree certificate, the ACME server moves the order to the "valid" state after the corresponding entry is sequenced in the issuance log, cosignatures are collected, and the standalone certificate is available. The order's certificate URL then serves the standalone certificate, constructed as described in <a href="#standalone-certificates" class="auto internal xref">Section 6.3</a>.<a href="#section-9.2-2" class="pilcrow">¶</a></p> |
| 5135 | +<p id="section-9.2-3">The standalone certificate response SHOULD additionally carry an enhancement URL (<a href="#enhancement-link-relation" class="auto internal xref">Section 9.1</a>) for the landmark-relative certificate, as described in <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>. Before the landmark-relative certificate is available, the enhancement URL SHOULD return an HTTP 202 (Accepted) response. Once the next landmark is allocated, the ACME server constructs a landmark-relative certificate, as described in <a href="#landmark-relative-certificates" class="auto internal xref">Section 6.4</a>, and serves it from the enhancement URL.<a href="#section-9.2-3" class="pilcrow">¶</a></p> |
| 5136 | +</section> |
| 5137 | +</div> |
5109 | 5138 | </section> |
5110 | 5139 | </div> |
5111 | 5140 | <div id="deployment-considerations"> |
@@ -5522,6 +5551,31 @@ <h3 id="name-relative-distinguished-name"> |
5522 | 5551 | </table> |
5523 | 5552 | </section> |
5524 | 5553 | </div> |
| 5554 | +<div id="link-relation-type"> |
| 5555 | +<section id="section-13.5"> |
| 5556 | + <h3 id="name-link-relation-type"> |
| 5557 | +<a href="#section-13.5" class="section-number selfRef">13.5. </a><a href="#name-link-relation-type" class="section-name selfRef">Link Relation Type</a> |
| 5558 | + </h3> |
| 5559 | +<p id="section-13.5-1">IANA is requested to add the following entry to the "Link Relation Types" registry <span>[<a href="#RFC8288" class="cite xref">RFC8288</a>]</span>:<a href="#section-13.5-1" class="pilcrow">¶</a></p> |
| 5560 | +<span class="break"></span><dl class="dlParallel" id="section-13.5-2"> |
| 5561 | + <dt id="section-13.5-2.1">Relation Name:</dt> |
| 5562 | + <dd style="margin-left: 1.5em" id="section-13.5-2.2"> |
| 5563 | + <p id="section-13.5-2.2.1">enhancement<a href="#section-13.5-2.2.1" class="pilcrow">¶</a></p> |
| 5564 | +</dd> |
| 5565 | + <dd class="break"></dd> |
| 5566 | +<dt id="section-13.5-2.3">Description:</dt> |
| 5567 | + <dd style="margin-left: 1.5em" id="section-13.5-2.4"> |
| 5568 | + <p id="section-13.5-2.4.1">Refers to an optional substitute for this context. Consumers that accept the substitute are expected to also accept the original context, so it is not an error if the substitute is unavailable.<a href="#section-13.5-2.4.1" class="pilcrow">¶</a></p> |
| 5569 | +</dd> |
| 5570 | + <dd class="break"></dd> |
| 5571 | +<dt id="section-13.5-2.5">Reference:</dt> |
| 5572 | + <dd style="margin-left: 1.5em" id="section-13.5-2.6"> |
| 5573 | + <p id="section-13.5-2.6.1">[this-RFC], <a href="#enhancement-link-relation" class="auto internal xref">Section 9.1</a><a href="#section-13.5-2.6.1" class="pilcrow">¶</a></p> |
| 5574 | +</dd> |
| 5575 | + <dd class="break"></dd> |
| 5576 | +</dl> |
| 5577 | +</section> |
| 5578 | +</div> |
5525 | 5579 | </section> |
5526 | 5580 | </div> |
5527 | 5581 | <div id="sec-combined-references"> |
@@ -5567,6 +5621,10 @@ <h3 id="name-normative-references"> |
5567 | 5621 | <dd> |
5568 | 5622 | <span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span><<a href="https://www.rfc-editor.org/rfc/rfc8174">https://www.rfc-editor.org/rfc/rfc8174</a>></span>. </dd> |
5569 | 5623 | <dd class="break"></dd> |
| 5624 | +<dt id="RFC8288">[RFC8288]</dt> |
| 5625 | + <dd> |
| 5626 | +<span class="refAuthor">Nottingham, M.</span>, <span class="refTitle">"Web Linking"</span>, <span class="seriesInfo">RFC 8288</span>, <span class="seriesInfo">DOI 10.17487/RFC8288</span>, <time datetime="2017-10" class="refDate">October 2017</time>, <span><<a href="https://www.rfc-editor.org/rfc/rfc8288">https://www.rfc-editor.org/rfc/rfc8288</a>></span>. </dd> |
| 5627 | +<dd class="break"></dd> |
5570 | 5628 | <dt id="RFC8446">[RFC8446]</dt> |
5571 | 5629 | <dd> |
5572 | 5630 | <span class="refAuthor">Rescorla, E.</span>, <span class="refTitle">"The Transport Layer Security (TLS) Protocol Version 1.3"</span>, <span class="seriesInfo">RFC 8446</span>, <span class="seriesInfo">DOI 10.17487/RFC8446</span>, <time datetime="2018-08" class="refDate">August 2018</time>, <span><<a href="https://www.rfc-editor.org/rfc/rfc8446">https://www.rfc-editor.org/rfc/rfc8446</a>></span>. </dd> |
@@ -7289,6 +7347,9 @@ <h3 id="name-since-draft-ietf-plants-merkle-"> |
7289 | 7347 | </li> |
7290 | 7348 | <li class="normal" id="appendix-E.16-1.5"> |
7291 | 7349 | <p id="appendix-E.16-1.5.1">Define a CA's current issuance log and rules around that<a href="#appendix-E.16-1.5.1" class="pilcrow">¶</a></p> |
| 7350 | +</li> |
| 7351 | + <li class="normal" id="appendix-E.16-1.6"> |
| 7352 | + <p id="appendix-E.16-1.6.1">Switch the ACME construction to a new link relation and change the HTTP status code<a href="#appendix-E.16-1.6.1" class="pilcrow">¶</a></p> |
7292 | 7353 | </li> |
7293 | 7354 | </ul> |
7294 | 7355 | </section> |
|
0 commit comments