On Thu, Nov 13, 2014 at 6:15 PM, Peter Saint-Andre - &yet
<[email protected]> wrote:
> The authors have given this further consideration and we have a question: in
> practice will it be OK to send *both* status_request and status_request_v2
> in the same handshake?

If the client supports both, then it will include both in its ClientHello.

If the server supports both, and and the ClientHello only contains
status_request or status_request_v2 but not both, then obviously it
will just choose whichever one the client supported.

If the server supports both, and the ClientHello includes both, then
the server is free to choose status_request or status_request_v2 or
both. I think the intent of RFC 6961 is that only status_request_v2
would be sent in that case, but this isn't explicitly stated anywhere,
AFAICT. I wouldn't be surprised to find that a server that attempts to
implement RFC 6961 may have to include BOTH status_request and
status_request_v2, because I bet some middleboxes won't expect the
CertificateStatus handshake message unless the original status_request
extension is present. BUT, also, I wouldn't be surprised if some
clients refuse to accept a ServerHello with both status_request and
status_request_v2.

So, I guess now I'm unsure whether RFC 6961 (status_request_v2) is
even deployable. But, I know for a fact that the original RFC 6066
status_request mechanism is deployable, because many implementations
have deployed it. (It usually works without creating problems.
Sometimes it creates problems, but I think the problems are caused
primarily by bugs in servers that would also affect
status_request_v2.)

Note that I wouldn't mind if you removed the suggestion to implement
status_request_v2, given that we don't know much about it. I think
that would be prudent, though I don't care strongly about it. But, it
is really important to recommend the original RFC 6066 status_request
extension.

Cheers,
Brian

_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta

Reply via email to