Subject: [TLS] ldaps closure alert http://www.ietf.org/rfc/rfc2830.txt

From: Peter Williams <[email-masked]>
Date: Thu, 21 Dec 2006 23:25:38 -0800

http://www.ietf.org/rfc/rfc2830.txt discloses that
 
   After the initiator of a close has sent a closure alert, it MUST   discard any TLS messages until it has received an alert from the   other party.  It will cease to send TLS Record Protocol PDUs, and   following the receipt of the alert, MAY send and receive LDAP PDUs.   The other party, if it receives a closure alert, MUST immediately   transmit a TLS closure alert.  It will subsequently cease to send TLS   Record Protocol PDUs, and MAY send and receive LDAP PDUs.
An initiating party issues a closure_alert, and starts waiting for ANY alert
in response (from the recipient). Thereupon, it MAY starting sending cleartext 
PDUs directly over the underlying TLS transport.
 
A responding party suffering delays on its TLS input qbuf (on a ciphersuite with null
confidentiality in particular) could be sending who knows what warning alerts (std 
and custom), that will arrive after the initiating party sent its closure_alert. 
 
After the first one arrives, it is no longer specified to discard TLS messages, note. Presumably
the TLS protocol engine should now process them. 
 
>From what I read,  the DAP engine is now in a state where it can process any dap 
pdu responses, indicated to it. 

_________________________________________________________________
Type your favorite song.  Get a customized station.  Try MSN Radio powered by Pandora.
http://radio.msn.com

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls