Hello Marek, On Sun, 24 Feb 2008 05:52:40 +0100 GMT (24/02/2008, 11:52 +0700 GMT), Marek Mikus wrote:
>> Not I "must". I "should". And if I don't do it, I must live with the >> consequences. I "must not" be nannied by my email program - especially >> since other email programs don't nanny the user. They give a pop-up >> warning and then let the user accept the expired certificate if he so >> chooses. Please don't treat me like a child, I know what I'm doing. MM> I am against "such" security, if You accept security, You should accept MM> its policy. Thanks for your opinion. I will assume that you will never accept an expired certificate. That's good for you. I have a different opinion. Why do you want to forbid me to do something? Just because you wouldn't want to do it yourself? How is that not unacceptable nannying? How does it hurt *you* when *I* accept an expired certificate? MM> For example from RFC2246 MM> F.1.1. Authentication and key exchange MM> TLS supports three authentication modes: That's great support, but the RFC doesn't force me make my connection more secure. If I want to have a secure connection, the support is there, and it's appreciated. If the cert is expried and I know that this brainy of a sysad again forgot to renew it before he went on vacation, you cut me completely off from my email. I'd rather take chances with the missing security than missing out on important business opportunities. Let it be up to me to set my own priorities, regardless of whether you would set the priorities differently. MM> authentication of both parties, server authentication with an MM> unauthenticated client, and total anonymity. Whenever the MM> server is authenticated, the channel is secure against MM> man-in-the-middle attacks, but completely anonymous sessions MM> are inherently vulnerable to such attacks. Anonymous servers MM> cannot authenticate clients. If the server is authenticated, MM> its certificate message must provide a valid certificate chain MM> leading to an acceptable certificate authority. Similarly, MM> authenticated clients must supply an acceptable certificate to MM> the server. Each party is responsible for verifying that the MM> other's certificate is valid and has not expired or been MM> revoked. If the server's certificate is expired, the sysad has failed in his reponsibility. True. However, I can accept his shortcoming if I want to - the RFC doesn't forbid me to. I don't know any otehr email client that forbids me to. You are over-interpreting the RFC. It doesn't say that the client has to lock the user out of the email if the server's cert has expired. It only says the server's admin hasn't done his job, which is true. Why do you think this means that the client is not allowed to accept an expried certificate? -- Cheers, Thomas. "Sky-diving Mom Gives Birth During Free-Fall" http://thomas.fernandez.hat-gar-keine-homepage.de/ Message reply created with The Bat! 4.0.14.5 under Windows XP 5.1 Build 2600 Service Pack 2 ________________________________________________________ Current beta is 4.0.14.4 | 'Using TBBETA' information: http://www.silverstones.com/thebat/TBUDLInfo.html
