|
1050 | 1050 | </tr></thead> |
1051 | 1051 | <tfoot><tr> |
1052 | 1052 | <td class="left">Benjamin, et al.</td> |
1053 | | -<td class="center">Expires 9 May 2026</td> |
| 1053 | +<td class="center">Expires 10 May 2026</td> |
1054 | 1054 | <td class="right">[Page]</td> |
1055 | 1055 | </tr></tfoot> |
1056 | 1056 | </table> |
|
1063 | 1063 | <dd class="internet-draft">draft-davidben-tls-merkle-tree-certs-latest</dd> |
1064 | 1064 | <dt class="label-published">Published:</dt> |
1065 | 1065 | <dd class="published"> |
1066 | | -<time datetime="2025-11-05" class="published">5 November 2025</time> |
| 1066 | +<time datetime="2025-11-06" class="published">6 November 2025</time> |
1067 | 1067 | </dd> |
1068 | 1068 | <dt class="label-intended-status">Intended Status:</dt> |
1069 | 1069 | <dd class="intended-status">Experimental</dd> |
1070 | 1070 | <dt class="label-expires">Expires:</dt> |
1071 | | -<dd class="expires"><time datetime="2026-05-09">9 May 2026</time></dd> |
| 1071 | +<dd class="expires"><time datetime="2026-05-10">10 May 2026</time></dd> |
1072 | 1072 | <dt class="label-authors">Authors:</dt> |
1073 | 1073 | <dd class="authors"> |
1074 | 1074 | <div class="author"> |
@@ -1128,7 +1128,7 @@ <h2 id="name-status-of-this-memo"> |
1128 | 1128 | time. It is inappropriate to use Internet-Drafts as reference |
1129 | 1129 | material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p> |
1130 | 1130 | <p id="section-boilerplate.1-4"> |
1131 | | - This Internet-Draft will expire on 9 May 2026.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p> |
| 1131 | + This Internet-Draft will expire on 10 May 2026.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p> |
1132 | 1132 | </section> |
1133 | 1133 | </div> |
1134 | 1134 | <div id="copyright"> |
@@ -4413,7 +4413,7 @@ <h3 id="name-size-estimates"> |
4413 | 4413 | <p id="section-6.4-4">The current issuance rate across the Web PKI may not necessarily be representative of the Web PKI after a transition to short-lived certificates. Assuming a certificate lifetime of 7 days, and that subscribers will update their certificates 75% of the way through their lifetime (see <a href="#certificate-renewal" class="auto internal xref">Section 10.4</a>), every certificate will be reissued every 126 hours. This gives issuance rate estimates of around 4,400,000 certificates per hour and 17,000,000 certificates per hour, for the first two values above. Note the larger estimate is across all CAs, while subtrees would only span one CA.<a href="#section-6.4-4" class="pilcrow">¶</a></p> |
4414 | 4414 | <p id="section-6.4-5">Using the per-CA short lifetime estimate, if the CA mints a checkpoint every 2 seconds, full certificate subtrees will span around 2,500 certificates, leading to 12 hashes in the inclusion proof, or 384 bytes. Full certificates additionally must carry a sufficient set of signatures to meet relying party requirements.<a href="#section-6.4-5" class="pilcrow">¶</a></p> |
4415 | 4415 | <p id="section-6.4-6">If a new landmark is allocated every hour, signatureless certificate subtrees will span around 4,400,000 certificates, leading to 23 hashes in the inclusion proof, giving an inclusion proof size of 736 bytes, with no signatures. This is significantly smaller than a single ML-DSA-44 signature, 2,420 bytes, and almost ten times smaller than the three ML-DSA-44 signatures necessary to include post-quantum SCTs.<a href="#section-6.4-6" class="pilcrow">¶</a></p> |
4416 | | -<p id="section-6.4-7">The proof sizes grow logarithmically, so 32 hashes, or 1024 bytes, is sufficient for subtrees of up to 2^32 (4,294,967,296) certificates.<a href="#section-6.4-7" class="pilcrow">¶</a></p> |
| 4416 | +<p id="section-6.4-7">The proof sizes grow logarithmically, so 32 hashes, or 1024 bytes, is sufficient for subtrees of up to 2<sup>32</sup> (4,294,967,296) certificates.<a href="#section-6.4-7" class="pilcrow">¶</a></p> |
4417 | 4417 | </section> |
4418 | 4418 | </div> |
4419 | 4419 | </section> |
|
0 commit comments