Hello hggdh, Monday, October 25, 2004, 12:46:31 AM, you wrote:
h> Secondly, the security/privacy attained by the use of encryption is h> also dependent on guaranteeing the integrity of the certificate (and, h> by extension, of the public/private key pair it uses). Agreed, however integrity also must include physical security, in this context a CA is irrelevant. A past employer MD had his CA cert in a dummy name on his own locked private directline server in his office, you would need private trust that using the server implied that even his PA had no access. If I send Redleg a post at work dozens of people may have access to the message - via CA cert. Then I send to his home fixed IP, I only need worry about his family or his laxness in preventing them getting to his mail - self cert and fingerprint. In practice I am happy to trust the IP, but encryption gives us privacy. h> On a production environment, the risks of using a rootless public h> certificate are unacceptable. The reason here is you cannot distinghish h> a 100% real-honest-I-swear-over-whichever-grave-you-want-me-to-use BUT h> rootless from a counterfeit, identical in the identification data, one. Right, if you rely on the cert alone. Other methods can be used to validate a cert, as per my earlier post - provided that you can safely check fingerprint the cert every use. What I am asking for is notionaly the same as two PGP users each self signing their own key and not each others in a private web of two. h> Encryption has many issues, but one of them, a very important one, is: h> *Key managament & distribution* This is the part of "using h> encryption" that worries about storing encryption keys, and h> safely distributing them. This is not an issue when people already know each other. 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. I request the option to be the "known" authority myself and do the external validation myself. AR>> This is not *always* so. If I was concerned with the entire PKI or AR>> hierarchy of it- then yes. If all I want to do is communicate via secure AR>> transport with a mail service and can verify the "servers" cert, as well AR>> other factors like the IP of the server, published info about the cert AR>> on the website, etc then I can be satisfied. My personal standard has AR>> been met in this case- and it may not always *require* having placed my AR>> trust completely in the CA or Intermediaries. Why must I trust them AR>> anyways? OK, this is what I mean also but I've been more verbose! h> Also, I fail to understand a site that publishes it's public h> certificate, but does not provide pointers to the roots (i.e., to h> where you can get the roots, and it better be a completely different h> place!). A spammer/bad guy connects to my private server and can get my name/company or other private details from the cert. AR>> My trust is in the server. The certificate is there to afford me the AR>> opportunity to establish the security and privacy provided by an AR>> encrypted transport with this trusted server... h> As shown above, you cannot trust your "server". And... you cannot h> trust a rootless certificate. You can swallow it, but not trust. I disagree, I control my local server and DNS, Redleg controls his local server and DNS. We could happily exchange messages in clear but for privacy would like the option to choose to validate each others certs by external methods. h> The whole idea of root certificates on TLS/SSL is to allow you to h> *confirm* that a public certificate received has been verified by h> someone. For private use, personal private verification works fine. Browsers happily let you import a non-CA cert and allow a user an option to do their own choice of verification first. h> The idea here is similar to the web of trust in PGP/GNUPG. You do not h> know me, but you know someone that signed my PGP key stating I am who h> I say I am. However this arguement assumes that I have not met my brother or friend and do not have another method of validation such as voice p2p. Also another thought, I may want to exchange mails with someone I do not trust - however I'd prefer the option to reduce the chance of someone else listening in at least for most of the journey. AR>> As you mention below, self signed certs will always be a factor. Simply AR>> due to the cost associated with the mainstream CA's, especially with AR>> those roots included in OS and browsers. Once my standards heve been AR>> met then I should be the decision maker, imnsho, not TB!. h> OK. OK. I accept it. The *final* user should have a *final* say on h> whether the rootless certificate will be accepted or not. On further h> thinking, I consider your approach valid, albeit the result is a h> potentially compromised session. h> But, the user assumes all risks. Caveat emptor. Thank you! AR>> Thanks for the feedback, looking forward to more- and hopefully AR>> (eventually) even get entertained by the development powers that be. h> Indeed, this is fun. I suggest you to open a formal wish (I do not h> know how to do it, but certainly someone in here will). h> I will sign down on it (given that a stern warning is issued prior to h> acceptance of the rootless public certificate). Excellent... h> On using a hash, or equivalent, to verify if the newly received h> certificate is identical to one stored: this is already available. All h> TLS/SSL public certificates have such a hash. So, what would be needed h> is to warn the user that the just-received certificate does *NOT* h> match the one stored. Yes, thank you for the info , I agree this looks exactly what is needed. -- Best regards, James ________________________________________________________ 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/
