Re: [httpwg/http-extensions] Stream-linking frames can reference Stream Zero (#586)

[HTTP issue updates <[e-mail]>]

martinthomson requested changes on this pull request.

This makes me convinced that we probably want to hold exported authenticators for a little while longer.  See the big comment.

>  
-If the server does not have the desired certificate, it MUST \[see issue #564].
-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.
+If the server does not have the desired certificate, it MUST send an empty
+`USE_CERTIFICATE` frame for stream zero.  In this case, or if the server has not

When you say empty, I think that you mean that the server sends an empty CERTIFICATE frame and then references that certificate when it wants to reject a CERTIFICATE_NEEDED request.

That is:

```
Client Sends:
CERTIFICATE_REQUEST (id=N) -->
CERTIFICATE_NEEDED (S=0, R=M) -->
...
Server can't answer, so:
<-- CERTIFICATE (Cert-ID=Q, <empty>)
<-- USE_CERTIFICATE (S=0, R=M)
```

The problem here is that the empty CERTIFICATE frame isn't bound in any way to the CERTIFICATE_REQUEST, unless your definition of "empty" isn't that the authenticator is completely absent, but that it includes a valid authenticator, but no certificate in the TLS Certificate message.  Then the `certificate_request_context` can be used to correlate CERTIFICATE with CERTIFICATE_REQUEST in the usual fashion.  That's how TLS does it - it sends Certificate without the certificate and omits the CertificateVerify message entirely if it doesn't want to authenticate.  (I just realized that I used CERTIFICATE, Certificate and certificate in the same paragraph to mean three different things, which is not at all confusing.)

I just read exported authenticators again and I don't see that use case being addressed at all.  @grittygrease should be aware of that given that TLSEA is in WGLC.  I think that TLSEA needs to address that case one way or other.  If the intent is to have the using application manage rejection, then it needs to be clear where the responsibility lies.  However, I think that having authenticated rejection is superior and that should be expressly included in the draft with a description of how that is done.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/586#pullrequestreview-123206820