ACTION-417: investigate completeness of error handling wrt TLS extensions

So, I've taken a look but don't yet have specific text to suggest
for xit. Maybe put this on a call agenda, or consider it at the
f2f.

TLS 1.2 [1] allows for extension handling and defines 1 extension
(signature algs) that I think we can ignore.

TLSEXT [2] is a draft that specifies a bunch of existing extensions,
two of which we might, or might not, want to mention. I've no idea
of how widespread adoption of any of these extensions might
prove to be - but I don't think they're used much (or at all) today.

In general, TLS extension handling is initiated by clients, and
servers are to ignore unknown extensions, so I guess introduction
of new extensions ought be something we can safely ignore in most
cases.

The two extensions we might want to mention are:

- status_request: a client can ask the server to include an OCSP
response for the server's cert as part of the handshake. I guess
we might want to allow for this as an alternative to the status
checking defined in 3280 that we insist upon for AA certs. (*)
[I think this extension may be intended mainly for EAP/TLS so
perhaps we don't need to bother with it?]

- server_name: this allows a client to indicate to the server the
DNS name for which it wants the server to present a certificate
in order to better support virtual servers of various kinds. I
think (not quite sure though) that if the client does use this
extension and the server responds with a cert that doesn't match,
then the client should barf the session, for any type of cert.
We currently say "When the URL corresponding to the transaction at hand
does not match the certificate presented, and a validated certificate
is used, then error signalling of level danger(6.4.4 Danger Messages)
MUST be used."

Be no harm if someone else took a peek at [2] as well to see if
I've missed something.

Cheers,
Stephen.

(*) In passing, I noticed that we say "When certificate status checks
are attempted, but fail due to network errors or related error
conditions,..." I think that'd be clearer as "When certificate status
checks are attempted, but where the check fails, (i.e. does not
produce an answer as to certificate status), due to network errors or
related error conditions,..." The current wording might be mis-read
to say that an actually revoked non-AA cert (check "failed") only leads
to a warning/caution message and not a danger message.


[1] http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4346-bis-10.txt
[2] http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4366-bis-02.txt

Received on Wednesday, 7 May 2008 13:18:48 UTC