When the server-requested renegotiation is application triggered, as in the Microsoft IIS case, then the server better caches the result along with the SSL session. Microsoft IIS has a silly (performance-wasting) bug, where a client that does either not have a client cert or does not show one (and requiring the application to perform application level client authentication) is continously forced through the renegotiation when the client tries to resume the session from the session cache on a new connection.
This is not a bug. It is an explicitly permitted state within the SSL v3 conformance/state. Upon request, a client MAY send a client cert. What happens if it doesn't, is server policy.
The handshake protocol affects session state. Session resumption (a poorly named procedure) affects connection state, only.
Where a client cert is used for user auth purpose(in e.g. https) we have a situation that is different to a client cert being used to merely authenticate an T-connect peer. Whether the user app intended a previous user auth to be applied to a new connection is not specified in the "designers" rendition of the https protocol. That is, its up to the implementation of https, by intent. The implementation of Netscape-https is very different to that of IE-https (and MSFT's wininet.dll's default https,for wininet consumers that are not IE)
By definition http over SSL is https. Nothing more is stated. each https designer specifies their own "usage profile". Netscape-browsers have their concept for sharing hypermedia-state across TLSconnections, client side, and assured OS have theirs. Its that simple. There is no right or wrong, bug or not-bug.
-Martin _______________________________________________ TLS mailing list TLS@xxxxxxxxxxxxxx https://www1.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@xxxxxxxxxxxxxx https://www1.ietf.org/mailman/listinfo/tls