A while ago I promised a Tucows response regarding QuickSSL. Here goes, this is as interactive one. I am currently working to streamline our web-certificate offering and the existence of QuickSSL gives me some pause to question how I should go forward. I would love to hear your thoughts on the matter.
First up 1) Browser Recognition: Pulled from the QuickSSL Web-Site: "QuickSSL is compatible with Microsoft Internet Explorer� 5.01 and higher and Netscape/AOL Web browsers version 4.51 and higher, comprising an estimated 90% or more of all Web browsers in use today." Our Stats from July (not a trick-- just the latest I have): IE 5.5 -- 31.62% IE 5.01 -- 10.32% IE 5.01(msn) -- 0.70% IE 5.01 (aol) -- 0.43% NS 4.76 -- .96% NS 4.75 -- 1.05% NS 4.74 --0.24% NS 4.73 -- .99% NS 4.72 -- 0.61% NS 4.7 -- 1.83% NS 4.51-NS 4.7 -- 1.8% Total: 50.55% I don't want to generate a huge discussion about the validity of the browser recognition claims but I do find the 90%+ a little difficult to swallow. I would however like to know if that's important to you or not. 2) More importantly I would like to discuss the meaning of SSL: QuickSSL certificates do not verify identity. The fine print on the QuickSSL certificate acknowledges that this is the case (Organizational Unit not Validated -- or some such language appears) Present situation is this: Microsoft has adopted the WebTrust standards for the purpose of getting recognition in the browser. All new CA's will have to go through a WebTrust Audit and all existing CA's have a year to show that they comply. There is nothing 'prescriptive' in the standard at this time. The standard just uses 'reasonable' language of the sort - the CA will use measures appropriate for the intended use of the certificate to reasonably assure the identity of the holder (paraphrase). Since there is no bright line in the standard QuickSSL is not presently in violation. However, I have been speaking with a member of the WebTrust standards making body. He (and assures me others on the body) are very disturbed by the QuickSSL offering and (I quote) will work 'quickly and forcefully' to stop it. This will be accomplished by insertion of minimum verification requirements in the WebTrust Standard. Their concern (and my concern too) is that the industry has been working to explain the meaning of web certificates and that little lock in the browser to the public. A big portion of that message is that end-user identity is established. QuickSSL is offering a new type of lock that does not certify identity. Already, most of the internovices , have no clue what the lock signifies (one person i was talking with thought it was a purse indicating "buy-time") and, if they participate in e-commerce at all, will do so based on trust in the brand of the web-site not in the existence of a lock. For these types the benefit right now is just avoiding the scary security messages that come up if the certificate is not blessed by an authorized CA and not in the underlying securities that certificates provide. Herein lies what i would really like to hear your opinions on. I believe there is value in the securities that properly authenticated web certificates provide (namely security of identity and non-interception). The fact that these securities are not presently widely perceived should not be used as an excuse to diminish or remove them. The fact that, to date, there have been few instances where communicated data are attacked (as compared with stored data) should also not be used as evidence that these securities are not required (99.9% of the time I don't need to lock my apartment door either). In short, I presently support Web-Trust's efforts and am therefore looking for ways to streamline our existing certificate offering in a way that preserves certainty of identity and non-interception. Please comment.... Darryl Green [EMAIL PROTECTED] Product Manager Web Certificates Tucows Inc. Phone:(416)538-5461 Fax: (416) 531-5584 96 Mowat Avenue Toronto Ontario M6K 3M1
