Incorporate exported authenticator requests #481
Conversation
MikeBishop
force-pushed
the
exported_requests
branch
from
95a9174
to
42f69c8
Compare
| [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. |
There was a problem hiding this comment.
Exported authenticators require that the certificate_request_context be unpredictable. I think that we can address this by prefixing a random sequence with the two-octet Request-ID. Then we can ensure that we have a mapping key, but also enough entropy to avoid guessing.
There was a problem hiding this comment.
Should we specify the length?
There was a problem hiding this comment.
We probably need a minimum size to stop someone from inducing lots of requests until the right number comes up (for the stolen credentials they have).
| 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. |
There was a problem hiding this comment.
Verify that the authenticator has either an empty certificate_request_context (for clients only), or contains a Request-ID from a previously-sent CERTIFICATE_REQUEST frame.
| - the `certificate_request_context` matches the Cert-ID of the frame(s) in | ||
| which it was received | ||
| takes as input a request, a set of certificates, and supporting information | ||
| about the certificate (OCSP, SCT, etc.). |
There was a problem hiding this comment.
This statement applies to the creation of an authenticator. But the following paragraph talks about validation of one. I think that you need to make that distinction a lot clearer.
| the `CERTIFICATE_REQUEST` contained a non-empty `Cert-Extensions` element, the | ||
| end-entity certificate MUST match with regard to the extensions recognized by | ||
| the sender. | ||
| the `CERTIFICATE_REQUEST` to the best of the sender's ability. |
There was a problem hiding this comment.
This is really a requirement on exported authenticators. Can we turn this into a statement of truth instead? Or remove it entirely.
There was a problem hiding this comment.
I'm not sure that's true -- the exported authenticator functionality is responsible for communicating the requirements and the certificate, but it's not responsible for selecting the certificate to respond with. I think it's a requirement on whomever does certificate selection, which I believe is the HTTP layer (or some library invoked by it, anyway).
There was a problem hiding this comment.
It's not really actionable though. If your intent is to state an interoperability requirement (why else do you use MUST), what do we lose if someone violates that? I mean, I know that NSS could try harder to comply, but we do have better things to do than add full support for oid_filter (just for example, which is really hard to implement in practice).
| the `CERTIFICATE_REQUEST` contained a non-empty `Cert-Extensions` element, the | ||
| end-entity certificate MUST match with regard to the extensions recognized by | ||
| the sender. | ||
| the `CERTIFICATE_REQUEST` to the best of the sender's ability. |
There was a problem hiding this comment.
I'm not sure that's true -- the exported authenticator functionality is responsible for communicating the requirements and the certificate, but it's not responsible for selecting the certificate to respond with. I think it's a requirement on whomever does certificate selection, which I believe is the HTTP layer (or some library invoked by it, anyway).
| [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. |
There was a problem hiding this comment.
Should we specify the length?
| 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. |
There was a problem hiding this comment.
Or contains the 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. |
There was a problem hiding this comment.
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.
Tracking changes from tlswg/tls-exported-authenticator#9 to create an exported authenticator request message at the TLS layer as well.
This is a straight port of MikeBishop/http2-certs#18; feedback there has already been addressed, modulo one issue I'll be adding to this repo.