Skip to content

Commit

Permalink
Script updating gh-pages from eb9872d. [ci skip]
Browse files Browse the repository at this point in the history
  • Loading branch information
ID Bot committed Oct 12, 2023
1 parent fe0bc59 commit e11af48
Show file tree
Hide file tree
Showing 2 changed files with 28 additions and 23 deletions.
26 changes: 14 additions & 12 deletions caw/ech-config-extensions/draft-ietf-tls-esni.html
Original file line number Diff line number Diff line change
Expand Up @@ -1033,7 +1033,7 @@
</tr></thead>
<tfoot><tr>
<td class="left">Rescorla, et al.</td>
<td class="center">Expires 11 April 2024</td>
<td class="center">Expires 14 April 2024</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
Expand All @@ -1046,12 +1046,12 @@
<dd class="internet-draft">draft-ietf-tls-esni-latest</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2023-10-09" class="published">9 October 2023</time>
<time datetime="2023-10-12" class="published">12 October 2023</time>
</dd>
<dt class="label-intended-status">Intended Status:</dt>
<dd class="intended-status">Standards Track</dd>
<dt class="label-expires">Expires:</dt>
<dd class="expires"><time datetime="2024-04-11">11 April 2024</time></dd>
<dd class="expires"><time datetime="2024-04-14">14 April 2024</time></dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
Expand Down Expand Up @@ -1106,7 +1106,7 @@ <h2 id="name-status-of-this-memo">
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow"></a></p>
<p id="section-boilerplate.1-4">
This Internet-Draft will expire on 11 April 2024.<a href="#section-boilerplate.1-4" class="pilcrow"></a></p>
This Internet-Draft will expire on 14 April 2024.<a href="#section-boilerplate.1-4" class="pilcrow"></a></p>
</section>
</div>
<div id="copyright">
Expand Down Expand Up @@ -1594,8 +1594,8 @@ <h2 id="name-encrypted-clienthello-confi">
} HpkeKeyConfig;

struct {
ECHConfigExtensionType ech_config_extension_type;
opaque extension_data&lt;0..2^16-1&gt;;
ECHConfigExtensionType type;
opaque data&lt;0..2^16-1&gt;;
} ECHConfigExtension;

struct {
Expand Down Expand Up @@ -1685,9 +1685,11 @@ <h2 id="name-encrypted-clienthello-confi">
<dd class="break"></dd>
<dt id="section-4-6.13">extensions</dt>
<dd style="margin-left: 1.5em" id="section-4-6.14">
<p id="section-4-6.14.1">A list of ECH configuration extensions that the client must take into
consideration when generating a ClientHello message. These are described below
(<a href="#config-extensions" class="auto internal xref">Section 4.2</a>).<a href="#section-4-6.14.1" class="pilcrow"></a></p>
<p id="section-4-6.14.1">A list of ECHConfigExtension values that the client must take into
consideration when generating a ClientHello message. Each ECHConfigExtension
has a 2-octet type and opaque data value, where the data value is encoded
with a 2-octet integer representing the length of the data, in network byte
order. ECHConfigExtension values are described below (<a href="#config-extensions" class="auto internal xref">Section 4.2</a>).<a href="#section-4-6.14.1" class="pilcrow"></a></p>
</dd>
<dd class="break"></dd>
</dl>
Expand Down Expand Up @@ -1766,9 +1768,9 @@ <h3 id="name-configuration-extensions">
maintained by IANA as described in <a href="#config-extensions-iana" class="auto internal xref">Section 11.3</a>.
ECH configuration extensions follow the same interpretation rules as TLS
extensions: extensions MAY appear in any order, but there MUST NOT be more
than one extension of the same type in the extensions block. An extension can
be tagged as mandatory by using an extension type codepoint with the high
order bit set to 1.<a href="#section-4.2-2" class="pilcrow"></a></p>
than one extension of the same type in the extensions block. Unlike TLS
extensions, an extension can be tagged as mandatory by using an extension type
codepoint with the high order bit set to 1.<a href="#section-4.2-2" class="pilcrow"></a></p>
<p id="section-4.2-3">Clients MUST parse the extension list and check for unsupported mandatory
extensions. If an unsupported mandatory extension is present, clients MUST
ignore the <code>ECHConfig</code>.<a href="#section-4.2-3" class="pilcrow"></a></p>
Expand Down
25 changes: 14 additions & 11 deletions caw/ech-config-extensions/draft-ietf-tls-esni.txt
Original file line number Diff line number Diff line change
Expand Up @@ -5,11 +5,11 @@
tls E. Rescorla
Internet-Draft RTFM, Inc.
Intended status: Standards Track K. Oku
Expires: 11 April 2024 Fastly
Expires: 14 April 2024 Fastly
N. Sullivan
C. A. Wood
Cloudflare
9 October 2023
12 October 2023


TLS Encrypted Client Hello
Expand Down Expand Up @@ -43,7 +43,7 @@ Status of This Memo
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on 11 April 2024.
This Internet-Draft will expire on 14 April 2024.

Copyright Notice

Expand Down Expand Up @@ -303,8 +303,8 @@ Table of Contents
} HpkeKeyConfig;

struct {
ECHConfigExtensionType ech_config_extension_type;
opaque extension_data<0..2^16-1>;
ECHConfigExtensionType type;
opaque data<0..2^16-1>;
} ECHConfigExtension;

struct {
Expand Down Expand Up @@ -367,9 +367,12 @@ Table of Contents
See Section 6.1.7 for how the client interprets and validates the
public_name.

extensions A list of ECH configuration extensions that the client
must take into consideration when generating a ClientHello
message. These are described below (Section 4.2).
extensions A list of ECHConfigExtension values that the client must
take into consideration when generating a ClientHello message.
Each ECHConfigExtension has a 2-octet type and opaque data value,
where the data value is encoded with a 2-octet integer
representing the length of the data, in network byte order.
ECHConfigExtension values are described below (Section 4.2).

[[OPEN ISSUE: determine if clients should enforce a 63-octet label
limit for public_name]] [[OPEN ISSUE: fix reference to WHATWG-IPV4]]
Expand Down Expand Up @@ -433,9 +436,9 @@ Table of Contents
by IANA as described in Section 11.3. ECH configuration extensions
follow the same interpretation rules as TLS extensions: extensions
MAY appear in any order, but there MUST NOT be more than one
extension of the same type in the extensions block. An extension can
be tagged as mandatory by using an extension type codepoint with the
high order bit set to 1.
extension of the same type in the extensions block. Unlike TLS
extensions, an extension can be tagged as mandatory by using an
extension type codepoint with the high order bit set to 1.

Clients MUST parse the extension list and check for unsupported
mandatory extensions. If an unsupported mandatory extension is
Expand Down

0 comments on commit e11af48

Please sign in to comment.