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.

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

Incorporate exported authenticator requests #481

Merged
merged 5 commits into from Feb 6, 2018
Merged
Changes from 1 commit
Commits
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
21 changes: 11 additions & 10 deletions draft-ietf-httpbis-http2-secondary-certs.md
Expand Up @@ -66,7 +66,7 @@ scenarios.

--- note_Note_to_Readers

Discussion of this draft takes place on the HTTP working group mailing list
Discussion of this draft takes place on the HTTP working group mailing list
(ietf-http-wg@w3.org), which is archived at <https://lists.w3.org/Archives/Public/ietf-http-wg/>.

Working Group information can be found at <http://httpwg.github.io/>; source
Expand Down Expand Up @@ -566,9 +566,10 @@ Request:

The Exported Authenticator `request` API defined in
[I-D.ietf-tls-exported-authenticator] takes as input a set of desired
certificate characteristics and a `certificate_request_context`. When generating
exported authenticators for use with this extension, the
`certificate_request_context` MUST be the two-octet Request-ID.
certificate characteristics and a `certificate_request_context`, which needs to
be unpredictable. When generating exported authenticators for use with this
extension, the `certificate_request_context` MUST be the two-octet Request-ID,
followed by at least six random octets.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think that we need to stipulate order. Can we say that it contains both the two-octet Request-ID and at least 96 bits of additional entropy. (64-bits total isn't enough to avoid the problem I was talking about, especially when you consider that there is a good reason to choose a sequential Request-ID, which reduces that to 48 bits).

BTW, those extra bits can be constructed using HMAC(secret, Request-ID), rather than randomness.


The TLS library on the authenticating peer will provide mechanisms to select an
appropriate certificate to respond to the transported request. TLS libraries on
Expand Down Expand Up @@ -637,15 +638,15 @@ received on any other stream MUST be rejected with a stream error of type

The Exported Authenticator API defined in [I-D.ietf-tls-exported-authenticator]
takes as input a request, a set of certificates, and supporting information
about the certificate (OCSP, SCT, etc.).
about the certificate (OCSP, SCT, etc.). The result is an opaque token which is
used when generating the `CERTIFICATE` frame.

Upon receipt of a completed authenticator, an endpoint MUST perform the
following steps:
Upon receipt of a `CERTIFICATE` frame, an endpoint MUST perform the following
steps to validate the token it contains:
- Using the `get context` API, retrieve the `certificate_request_context` used
to generate the authenticator, if any.
- Verify that the `certificate_request_context` is the Request-ID of a
previously-sent `CERTIFICATE_REQUEST` frame. Alternatively, on clients the
`certificate_request_context` MAY also be empty.
- Verify that the `certificate_request_context` is either empty (clients only)
or the Request-ID of a previously-sent `CERTIFICATE_REQUEST` frame.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or contains the Request-ID.

- Use the `validate` API to confirm the validity of the authenticator with
regard to the generated request (if any).

Expand Down