Hello hggdh, Saturday, October 23, 2004, 6:16:44 PM, you wrote:
h> An user should *always* be allowed to "View" a certificate, mostly h> when there is an issue regarding it's validity (like an incomplete h> root chain). If this does not happen nowadays, then it is a bug on TB!. h> No questions about it. absolutely, if it can not be viewed we will never know the details of what was used to establish the SSL/TLS session and whether it should be trusted in the first place. h> One might even go ahead and allow the user to add a certificate with h> an incomplete root chain to the base. No big deal here. Which is what I have done, but it makes no matter as each session/connection must be manually approved still. h> But, here, we must draw the line. If the user succeeds in finding out h> the missing intermediate roots, and adds them to the base, then h> everything is OK, and life goes on. Otherwise -- i.e. there are still h> missing intermediate roots --, then TB! *HAS* to refuse using the h> certificate. If this is not an option for the user, then I humbly h> suggest the user to stop using SSL (or other schema in the same line). Here is where you lose me. You say it's ok to add the incomplete cert to the base earlier then here you say TB! has to refuse using the incomplete cert and even user, such as I, should stop using the security/privacy afforded by an encrypted session to transport email to and from the mail server? h> When you receive a certificate (on SSL negotiation) you do NOT trust h> this certificate. What you "trust", want it or not, is that it's h> signature can be verified by a "known" authority -- known to you, and h> accepted as such by you. This "known" authority is represented by the h> root certificates you accepted to use. Your trust on the certificate h> you received is transitive: you trust it because a know root confirms h> it. And *THIS* root is trusted by you not to mess up. As such, if h> there are missing intermediate root certificates, then there is no h> trust transitivity, and the certificate you received is, by default, h> tainted. This is not *always* so. If I was concerned with the entire PKI or hierarchy of it- then yes. If all I want to do is communicate via secure transport with a mail service and can verify the "servers" cert, as well other factors like the IP of the server, published info about the cert on the website, etc then I can be satisfied. My personal standard has been met in this case- and it may not always *require* having placed my trust completely in the CA or Intermediaries. Why must I trust them anyways? My trust is in the server. The certificate is there to afford me the opportunity to establish the security and privacy provided by an encrypted transport with this trusted server... Nothing can force me to trust the entire chain in a formal PKI and certainly shouldn't be a forced requirement when my trust is established in the server only, in some cases. As you mention below, self signed certs will always be a factor. Simply due to the cost associated with the mainstream CA's, especially with those roots included in OS and browsers. Once my standards heve been met then I should be the decision maker, imnsho, not TB!. h> This is not paranoia (although, I have to say, I *am* paranoid). This h> is simply the rules of the game. I am interested in where you have read these "rules of the game", falling under the broad umbrella of paranoid myself. RFC, FAQ, Internet Draft, Protocol Specification, Standard, other? h> Allie, you are absolutely correct when you wonder about the security h> of this. There is none. I beg to differ. The user, regardless of what any one entity says, is the *final* approving authority on what is acceptable in regards to what level of security and privacy that user desires. There is no security afforded, whatsoever, when TB! refuses to allow me to even view an incomplete certificate chain. All I am permitted to do is say OK or Cancel... I further feel this is a *very* reasonable request, to the point of being a no-brainer- when it comes to giving the user the decision making authority and allowing the user to satisfy his/her own security and/or privacy standards- rather than have them dictated and forced. h> Another option here is that this server is using a self-signed h> certificate. If this is the case, all that is needed to do is add the h> certificate itself to the trsuted root. 0bviously, there is then the h> problem of trust, back to haunt: you *can* trust a self-signed h> certificate, as long as you can positively confirm it. Since you h> cannot use a trusted root anymore, the only way to confirm it is by h> direct contact with the other party. Only after such confirmation h> should you add the certificate to the trusted root. Agreed! TB! allows for no user decision here, which falls back on it doesn't matter if it is a self signed job or not... Simply allow the user to decide when their personal trust standards have been met. Thanks for the feedback, looking forward to more- and hopefully (eventually) even get entertained by the development powers that be. -- Most Sincerely, Mark (Army RedLeg) Enjoying TheBat! Professional Edition v.3.0.2.1 on Win2kSP4/PIII-600/512MB. coming to you "LIVE!, From Albuquerque" <g> Eric Howes' Protecting Your Privacy & Security: https://netfiles.uiuc.edu/ehowes/www/ Good chance you'll find *all* the goodies here: http://lists.gpick.com/ looking for a nice place off the beaten usenet path? join us: nntp://news.securecomp.org ________________________________________________________ Current beta is 3.0.2.1 Beta/1 | 'Using TBBETA' information: http://www.silverstones.com/thebat/TBUDLInfo.html IMPORTANT: To register as a Beta tester, use this link first - http://www.ritlabs.com/en/partners/testers/
