Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

secondary-certs: type artwork consistently #631

Merged
merged 1 commit into from May 29, 2018
Merged

secondary-certs: type artwork consistently #631

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
28 changes: 14 additions & 14 deletions draft-ietf-httpbis-http2-secondary-certs.md
View file
Open in desktop
Expand Up @@ -152,7 +152,7 @@ request the client's certificate.
{{ex-http11}} shows the server initiating a TLS-layer renegotiation in response
to receiving an HTTP/1.1 request to a protected resource.

~~~
~~~ drawing
Client Server
-- (HTTP) GET /protected -------------------> *1
<---------------------- (TLS) HelloRequest -- *2
Expand Down Expand Up @@ -193,7 +193,7 @@ For the purposes of authenticating an HTTP request, this is functionally
equivalent to renegotiation. {{ex-tls13}} shows the simpler exchange this
enables.

~~~
~~~ drawing
Client Server
-- (HTTP) GET /protected ------------------->
<---------------- (TLS) CertificateRequest --
Expand Down Expand Up @@ -327,7 +327,7 @@ origins which it is prepared to service on the current connection, but MAY use
the ORIGIN frame {{?RFC8336}} to indicate that not all covered origins will be
served.

~~~
~~~ drawing
Client Server
<------------------ (stream 0) CERTIFICATE --
...
Expand All @@ -337,7 +337,7 @@ Client Server
~~~
{: #ex-http2-server-proactive title="Proactive Server Certificate"}

~~~
~~~ drawing
Client Server
-- (stream 0) CERTIFICATE ------------------>
-- (stream 0) USE_CERTIFICATE (S=1) -------->
Expand Down Expand Up @@ -375,7 +375,7 @@ In this case, or if the server has not advertised support for HTTP-layer
certificates, the client MUST NOT send any requests for resources in that origin
on the current connection.

~~~
~~~ drawing
Client Server
<----------------------- (stream 0) ORIGIN --
-- (stream 0) CERTIFICATE_REQUEST ---------->
Expand All @@ -392,7 +392,7 @@ request parameters or the responding certificate are not already available, they
will need to be sent as described in {{cert-available}} as part of this
exchange.

~~~
~~~ drawing
Client Server
<---------- (stream 0) CERTIFICATE_REQUEST --
...
Expand Down Expand Up @@ -455,15 +455,15 @@ be used to correlate the stream with a previous `CERTIFICATE_REQUEST` frame sent
on stream zero. The `CERTIFICATE_REQUEST` describes the certificate the sender
requires to make progress on the stream in question.

~~~~~~~~~~~~~~~
~~~ drawing
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------------------------------------------------------+
|R| Stream ID (31) |
+-------------------------------+-------------------------------+
| Request-ID (16) |
+-------------------------------+
~~~~~~~~~~~~~~~
~~~
{: #fig-cert-needed title="CERTIFICATE_NEEDED frame payload"}

The `CERTIFICATE_NEEDED` frame contains 6 octets. The first four octets
Expand Down Expand Up @@ -505,15 +505,15 @@ UNSOLICITED (0x01):

The payload of the `USE_CERTIFICATE` frame is as follows:

~~~~~~~~~~~~~~~
~~~ drawing
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------------------------------------------------------+
|R| Stream ID (31) |
+-------------------------------+-------------------------------+
| [Cert-ID (16)] |
+-------------------------------+
~~~~~~~~~~~~~~~
~~~
{: #fig-use-cert title="USE_CERTIFICATE frame payload"}

The first four octets indicate the Stream ID of the affected stream. The
Expand Down Expand Up @@ -571,13 +571,13 @@ The `CERTIFICATE_REQUEST` frame MUST be sent on stream zero. A
`CERTIFICATE_REQUEST` frame received on any other stream MUST be rejected with a
stream error of type `PROTOCOL_ERROR`.

~~~~~~~~~~~~~~~
~~~ drawing
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| Request-ID (16) | Request (?) ...
+---------------------------------------------------------------+
~~~~~~~~~~~~~~~
~~~
{: #fig-cert-request title="CERTIFICATE_REQUEST frame payload"}

The frame contains the following fields:
Expand Down Expand Up @@ -619,13 +619,13 @@ The `CERTIFICATE` frame defines two flags:
TO_BE_CONTINUED (0x01):
: Indicates that the exported authenticator spans more than one frame.

~~~~~~~~~~~~
~~~ drawing
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| Cert-ID (16) | Authenticator Fragment (*)...
+---------------------------------------------------------------+
~~~~~~~~~~~~~~~
~~~
{: #fig-proof-frame title="CERTIFICATE frame payload"}

The `Exported Authenticator Fragment` field contains a portion of the opaque
Expand Down