Mozilla CA Certificate Policy - Useful?
http://www.mozilla.org/projects/security/certs/policy From what I have seen on this list there has been a lot of talk about inclusion of various CA root certificates in the Mozilla distributions. IMO, most of these CAs are insignificant except for SSL certs. Why? Because the vast majority of organizations (in the rare situation that they use client-side PKI), actually issue their own client-certificates. BTW, I don't see that other providers of security software are particularly anxious extending their preconfigured trust lists. Some of the CAs like the recently discussed Hungarian CA also seem to be a of local interest in the same way as the 16(!) qualified certificate CAs operating in Italy. Anyway, if the goal is establishing a user/client-level CA trust list, Mozilla is not even close and that IMO makes the whole idea somewhat less powerful. It doesn't matter if it is wrong, stupid, or unsecure, but for consumer authentication local / private PKIs rule, and I don't see that changing due to things like business models, liability concerns, and cultural differences. I do not intend to respond to this posting because I understand that this is a sacred cow, and I do eat meat :-) Anders ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Creating a Global User-level CA/Trust Infrastructure forSecureMessaging
Michael Ströder wrote: Anders Rundgren wrote: Michael Ströder wrote: Ian G wrote: * it has no open + effective key distribution mechanism. (I exclude the LDAP stuff as that is generally for internal / corporates, and is not a general solution for the users.) Just exchanging signed S/MIME e-mails is quite easy for most users. The case that e-mail receivers are completely unknown is fairly seldom. This is a non-issue. The e-mail receivers are seldom unknown but their CAs are. Using Windows Mail most PKIX signed messages give me a black screen telling there is something wrong with this message, while messages asking me to download EXE files pass without warnings. When I'm in a project working for a company which has a S/MIME CA importing the CA cert into my S/MIME-enabled MUA is a no-brainer. What's the issue? I establish trust for a certain purpose: Exchanging secured e-mail with a certain company so nobody can read the documents *they* want to keep confidential. I'm happy to do that once for a CA cert instead of having to initiate a secure key exchange with every employee of the company. OK. I certainly understand the objective and the use-case. I can offer a counterpoint: a recent well-thought-out project to do something similar started out with S/MIME, and concluded that S/MIME should be optional because it is brittle, and all email should go through corporate servers, and TLS should be used for the protection. (In this case, every user was either an experienced security and tech person, or an extremely experienced security and tech person.) The sad thing is: The users, in this case my project colleagues, sometimes do not know how to use the existing S/MIME infrastructure although they enrolled during a user registration process and they already have everything on their desktop. Although I'm not involved personally with the S/MIME infrastructure my attitude is to teach the people how to use it. And they feel better when using it because they know there's a need for e-mail protection. But they were simply not teached. That's a non-technical problem. IMO, the root cause is not training. Nor legal. To blame some other process is what we call shifting the burden, a pattern that allows us to ignore the root causes. The root cause is that the S/MIME security model is inefficient; it doesn't deliver benefits in accordance with the costs imposed. Funnily enough, users are very savvy. They can spot a worthless system much more easily than engineers. What they can't do is explain why it is worthless; they simply bypass it. This is why smart product is always developed in association with lots of user feedback, and paper designs generally don't succeed. In this sense, Mozilla is on the right track with trying to put in place a user security model that doesn't require user intervention. (E.g., the UI hides the CA, from the all CAs are equal assumption.) However, this only works if the result is efficient. As Kyle comments, it isn't, for S/MIME, and the result is that the model experiences low usage rates. And any other signature/encryption/whatever standard will suffer from this. If by standard you mean security model, that's simply not true. Skype delivers the goods and takes only a few minutes of training. There is practically no training required to get users to use Skype in its secure mode, because it nicely follows the idea of there is only one mode, and it is secure. Although it is not likely that we can move email to the same model, it is entirely plausible to adopt 90% of the ease-of-use, without losing any of the CA certificate benefit. Of on the other hand you mean more literally, a standards-based security model, then yes, that's true. Correct me if I'm wrong, but I don't think any standards approach ever came up with a security model that works for users. E.g., after changing laptops recently, I still cannot s/mime to half my counterparties because I don't have their certs. This happens regularly with everyone I know... ??? I've changed my notebook harddisk quite often. I never lost my Seamonkey cert DB containing the key history of the last 10 years since it's part of the Mozilla profile which I have backups of. It is a curious thing: I have been using Tbird for many years, and each time I've never managed to transport more than a portion of the stuff across. I just spent some time looking and couldn't find the magic command, so I always wonder... I know there is a thing called profiles, but where does one import export them? Each time you want to use another computer. Oh, come on! How often do you *really* do this? And how do you move around the rest of your workspace? There are many more things to consider when you want real roaming than just your keys and PKCs of others. Sure. It's a nightmare. I do it around once a year at least -- full migration. This year, three times.
Re: Creating a Global User-level CA/Trust Infrastructure forSecureMessaging
Eddy Nigg wrote: On 11/27/2008 01:22 PM, Ian G: How do we know whether the keys are managed properly? Good question! Well, it's a closed architecture codebase, but it has been audited, so it bears comparison to any CA which operates a closed/audited procedure. Bullshit! That's about the same as CAs keeping copies of the users private keys...such a nonsense! Which they are indeed permitted to do, as long as they state that in their procedures, and their auditor agrees that they have met criteria. Eddy, other than your need to be colourful, what was the point you were trying to make? iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Creating a Global User-level CA/Trust Infrastructure forSecureMessaging
On 11/29/2008 01:23 PM, Ian G: Eddy Nigg wrote: On 11/27/2008 01:22 PM, Ian G: How do we know whether the keys are managed properly? Good question! Well, it's a closed architecture codebase, but it has been audited, so it bears comparison to any CA which operates a closed/audited procedure. Bullshit! That's about the same as CAs keeping copies of the users private keys...such a nonsense! Which they are indeed permitted to do, as long as they state that in their procedures, and their auditor agrees that they have met criteria. Eddy, other than your need to be colourful, what was the point you were trying to make? Well, CAs MUSTN'T have private keys of end user certificates, except in case of a properly implemented key escrow service and with the consent of the user. But if you really have to ask this question I'm afraid that the understandings about this and other subjects are probably too far apart between us in order to have any fruitful discussion. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: WISeKey root inclusion request (re-start public discussion)
On 11/29/2008 06:43 AM, Frank Hecker: On the WISeKey end, they could mandate use of SAN in BlackBox-issued certificates (as opposed to just including it in the default template), and from the NSS end we could disallow use of CN for storing domain names. At least you could have made it a requirement in order for the name constraints to have any effect with NSS. In regards to NSS we don't have to disallow subject CN fields, but have NSS check also for these attributes in addition to the SAN. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Creating a Global User-level CA/Trust Infrastructure forSecureMessaging
On 11/29/2008 02:37 PM, Eddy Nigg: Which they are indeed permitted to do, as long as they state that in their procedures, and their auditor agrees that they have met criteria. Eddy, other than your need to be colourful, what was the point you were trying to make? Well, CAs MUSTN'T have private keys of end user certificates, except in case of a properly implemented key escrow service and with the consent of the user. But if you really have to ask this question I'm afraid that the understandings about this and other subjects are probably too far apart between us in order to have any fruitful discussion. Perhaps I may add, that I'm not aware of any WebTrust, ETSI or similar audit they (Skype) performed. Can you point me to it? Also where is their (CA) policy? I understand your interest in making CAs superfluous, however the CAs perform various services only a third part is supposed to perform (separation of different aspects which makes up good security): - software (cryptography and usability) - issuing and validating instance - user (control over his private keys) In case of Skype they are the software vendor and control the software, the issuing instance and also the user (because they control what apparently seems to be private keys of users?). This is very similar to dictatorship and similar regimes where no separation exists... -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: WISeKey root inclusion request (re-start public discussion)
On 11/29/2008 05:27 PM, Frank Hecker: Made what a requirement? Mandating use of SAN in BlackBox? Yes, that's what I actually meant. But my understanding (based on your hypothetical scenario) is that this would not be sufficient, since someone could remove the key material and try to issue certificates outside the context of the BlackBox product. Which is correct too...at least in the above scenario misusing the system would require a higher effort and can't be performed directly from the system. My impression from Nelson's comments is that checking CN would be subject to potential errors, since there is no well-defined standard for what CN should contain. Thus the only foolproof approach would be to move to a world where we prohibit use of CN in contexts like SSL-enbled servers and force the use of SAN. But that would be a major undertaking and one that would likely take several years in order to coordinate action with other browser vendors and with CAs in general. Prohibiting the subject line would be a tough call - unrealistic in my opinion. But checking for the CN field for SERVER certificate should be entirely possible, because that's what NSS does anyway (for domain match). The bottom line is that I certainly encourage WISeKey to promote correct use of SAN, including consideration of making its use mandatory in the BlackBox templates, investigation of why some customers don't use it, and resolution of any issues relating to use of SAN by BlackBox customers. OK, so I guess there will be no follow up later on ;-) -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Creating a Global User-level CA/Trust Infrastructure forSecureMessaging
Ian G wrote: Michael Ströder wrote: Anders Rundgren wrote: Michael Ströder wrote: I can offer a counterpoint: a recent well-thought-out project to do something similar started out with S/MIME, and concluded that S/MIME should be optional because it is brittle, The phrase because it is brittle does not give any particular reason. So it's impossible to answer in a meaningful way. and all email should go through corporate servers, and TLS should be used for the protection. And how did you ensure that *all* of the relevant communication partner had StartTLS enabled at their MUAs, all MUAs were corporate servers (especially the receiving MX) and how was CA trust handled? Pretty similar problems... (In this case, every user was either an experienced security and tech person, or an extremely experienced security and tech person.) Well, strange... The unexperienced users I've teached to use the existing S/MIME infrastructure were capable of doing so. The sad thing is: The users, in this case my project colleagues, sometimes do not know how to use the existing S/MIME infrastructure although they enrolled during a user registration process and they already have everything on their desktop. Although I'm not involved personally with the S/MIME infrastructure my attitude is to teach the people how to use it. And they feel better when using it because they know there's a need for e-mail protection. But they were simply not teached. That's a non-technical problem. IMO, the root cause is not training. The root cause is that protecting e-mails is not enforced/endorsed within companies even if they have a working infrastructure. The lack of training is the consequence of this. Nor legal. Yes, not a legal issue. The root cause is that the S/MIME security model is inefficient; it doesn't deliver benefits in accordance with the costs imposed. I disagree (see above). Funnily enough, users are very savvy. I agree (see above ;-). They can spot a worthless system much more easily than engineers. What they can't do is explain why it is worthless; they simply bypass it. This is why smart product is always developed in association with lots of user feedback, and paper designs generally don't succeed. As I wrote the users themselves felt better after protecting e-mails with encryption. They are savvy. They know that it's bad not to encrypt e-mails. In another project my task was to explicitly support external partners of a company with a S/MIME infrastructure to get S/MIME-enabled. A normal user from within that company had triggered this support request. I tried to contact the admins of several external partners to help them but they just ignored it. = the lack of security requirements in the contracts were the root cause for failure. This has to be enhanced. In this sense, Mozilla is on the right track with trying to put in place a user security model that doesn't require user intervention. (E.g., the UI hides the CA, from the all CAs are equal assumption.) However, this only works if the result is efficient. As Kyle comments, it isn't, for S/MIME, and the result is that the model experiences low usage rates. In any case the sender *and* the receiver has to enabled for e-mail protection = the very same problems will arise. And any other signature/encryption/whatever standard will suffer from this. If by standard you mean security model, that's simply not true. Yes, IMO the security model is part of a standard (cryptographic protocol). Skype delivers the goods and takes only a few minutes of training. I don't trust Skype! AFAIK the protocol and security model was never publicly reviewed. And it only works with access to a central infrastructure. I'd never accept such a thing. Correct me if I'm wrong, but I don't think any standards approach ever came up with a security model that works for users. A pretty broad statement... E.g., after changing laptops recently, I still cannot s/mime to half my counterparties because I don't have their certs. This happens regularly with everyone I know... ??? I've changed my notebook harddisk quite often. I never lost my Seamonkey cert DB containing the key history of the last 10 years since it's part of the Mozilla profile which I have backups of. It is a curious thing: I have been using Tbird for many years, and each time I've never managed to transport more than a portion of the stuff across. I just spent some time looking and couldn't find the magic command, so I always wonder... I know there is a thing called profiles, but where does one import export them? By simply copying files? That's how I'm doing it. Each time you want to use another computer. Oh, come on! How often do you *really* do this? And how do you move around the rest of your workspace? There are many more things to consider when you want real roaming than just your keys and PKCs of others. Sure. It's a nightmare. I
Re: Creating a Global User-level CA/Trust Infrastructure forSecureMessaging
On Sat, Nov 29, 2008 at 3:20 AM, Ian G [EMAIL PROTECTED] wrote: The sad thing is: The users, in this case my project colleagues, sometimes do not know how to use the existing S/MIME infrastructure although they enrolled during a user registration process and they already have everything on their desktop. Although I'm not involved personally with the S/MIME infrastructure my attitude is to teach the people how to use it. And they feel better when using it because they know there's a need for e-mail protection. But they were simply not teached. That's a non-technical problem. IMO, the root cause is not training. Nor legal. To blame some other process is what we call shifting the burden, a pattern that allows us to ignore the root causes. The root cause is that the S/MIME security model is inefficient; it doesn't deliver benefits in accordance with the costs imposed. Funnily enough, users are very savvy. They can spot a worthless system much more easily than engineers. What they can't do is explain why it is worthless; they simply bypass it. This is why smart product is always developed in association with lots of user feedback, and paper designs generally don't succeed. In this sense, Mozilla is on the right track with trying to put in place a user security model that doesn't require user intervention. (E.g., the UI hides the CA, from the all CAs are equal assumption.) However, this only works if the result is efficient. As Kyle comments, it isn't, for S/MIME, and the result is that the model experiences low usage rates. First off: User training is arguably more technical than computer infrastructure. You can't simply say they were simply not teached [sic] and that's a non-technical problem, because computers need to be taught exactly one thing: how to perform a series of complex tasks. Users need to be taught that (perhaps not to the specific granularity of the operations that computers need to be taught, but they do need to know how to do a series of complex things) as well as something, perhaps more important: WHY to perform a series of complex tasks. (Why should someone change the oil in their car? Because it helps the car's engine last longer. Why should someone go through the additional mess and morass of using S/MIME? To let themselves in for more user-interface headache and annoyance?) The root cause is not training. There are actually two root causes of the failure of cryptography to make sizeable inroads into everyday non-commercial life. First is that the UI designers and programmers have violated the contract and interface to which the users have been trained. In other words, WE BROKE THE INTERFACE. Second is that the threat model currently used for commerce and government is NOT appropriate for non-commercial and non-governmental social interaction. In other words, for the general user, WE DIDN'T HAVE A GOOD REASON TO BREAK THE INTERFACE. As cryptographers, we can know -- and show, to a certainty far beyond any other data-transformation discipline -- several aspects of the metadata of properly-formatted messages. In our zeal to try to explain what we can know, and how we can know it, and why we can know it, we've overwhelmed the coders, the UI designers, the UI experts, the people who are supposed to distill complex operations, notices, and warnings to individually-understandable pieces. I like the idea of putting in a user security model that doesn't require user intervention -- but only to a point. I /don't/ like the idea of trying to make the system make all of its security decisions in a vacuum, especially in areas where the user has historically been the master (for me, that includes anything which can be covered under the Electronic Communication Privacy Act of 1986). The problem is this: the system is not intelligent. Only the user is intelligent. This means that data which would otherwise not be acceptable under the system's rules might be acceptable under the user's rules. This is why I've been in favor of unobtrusive pop-ups (rather like Growl notifications on the Mac). There are only a couple of pieces of information truly necessary for any security UI... who it's from, who says it's from the person it's from, who (ultimately) has been deemed acceptable to provide that kind of information, and whether it's been modified in transit. i.e., certificate subject, certificate issuer, issuer's root authority, and hash-match. I've also been putting energy toward making it possible for those interactions that don't require positive legal identification to be able to use certificates with the identities that others interact with. As I wrote elsewhere, it's entirely possible for two people to use the same login name or nickname -- but I've not seen any system where it is possible for two people to use the same login name within the same authentication/authorization boundary. What X.509 needs to be viewed as is not
Re: WISeKey root inclusion request (re-start public discussion)
OMG, maybe just maybe the OpenSSL folks should perhaps be told of this issue and concept so they can update! -Kyle H On Mon, Nov 24, 2008 at 11:35 AM, Eddy Nigg [EMAIL PROTECTED] wrote: On 11/24/2008 07:33 PM, Nelson B Bolyard: The only solution to this that is apparent to me is for the web to evolve to the point where browsers no longer accept DNS names in non-standard locations in the cert, such as in the Subject Common Name. Which in itself might create quite some problems. I guess we don't need any more problems right now when considering the current UI implementation and complaints coming in... Just imagine CN fields wouldn't be checked anymore by NSS: OMG, my openssl cert doesn't work anymore. Firefox is broken! :-) -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Mozilla CA Certificate Policy - Useful?
Anders Rundgren wrote: From what I have seen on this list there has been a lot of talk about inclusion of various CA root certificates in the Mozilla distributions. IMO, most of these CAs are insignificant except for SSL certs. I'm not sure your intended meaning is. There is no significant use of CA-issued certificates on the public Internet other than for enabling SSL/TLS. The primary reason CAs apply to have certificates included into NSS, and the primary reason we have a policy about this, is because CAs want their customers' SSL certificates recognized in Firefox. Why? Because the vast majority of organizations (in the rare situation that they use client-side PKI), actually issue their own client-certificates. Yes, because almost all use of client certificates is in enterprise networks, not on the public Internet. BTW, I don't see that other providers of security software are particularly anxious extending their preconfigured trust lists. To the contrary: Microsoft has an active program evaluating and accepting new root certificates for inclusion into Windows. They do it for the same reason we do: because CAs, web site operators, and users themselves don't want to see errors occur when connecting to SSL-enabled web sites. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Creating a Global User-level CA/Trust Infrastructure for SecureMessaging
Anders Rundgren wrote: Nelson B Bolyard wrote: I have contacts in the former Soviet Union who claim that Russian banks now routinely require PKI hardware for authentication as a condition of online banking. How sad that I live is a nation that is such a technological back-water. :) It sure is. The US is about the only major IT-nation where the government haven't even the slightest embryo to an architecture for secure messaging between agencies, not to mention between agencies and the private sector. So far they have managed keeping this a secret, since nobody has been able to decipher what the gazillion of CIO-documents littered with government buzz-words like FISSMA actually means for an architect. Fortunately, most EU governments have (with the German-speaking regions as the notable exception...), begun to build on architectures based on a paradigm that banks established 3-4 decades before them: http://webpki.org/papers/web/gateway.pdf Another strong reason for that is briefly described in this document: http://webpki.org/papers/web/A.R.AppliedPKI-Lesson-1.pdf It is fascinating meeting the consultants that the US government use, who all claim that this is nonsense; FIPS201/PIV can do it all! But since there is no bluprint supporting that position, progress remains firmly stuck at zero. Hmm, Anders, apologies in advance for the RTFM question, but can you please summarise those two docs, or explain the essential points in more detail? iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Creating a Global User-level CA/Trust Infrastructure forSecureMessaging
Kyle Hamilton wrote: I'd rather ask this question: What do the users need that can have partial or total solutions implemented using the technologies that have been developed? Right, good question. I have three partial answers: * if a standards protocol, Mozilla is interested in implementing it * if it is useful for developers, then that is good * if it delivers some benefit to users, then it may align with mission. iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Creating a Global User-level CA/Trust Infrastructure forSecureMessaging
On 11/30/2008 01:09 AM, Kyle Hamilton: Kyle, I must say that I found this particular message highly interesting! Allow me to respond only on some subjects you've touched which were of particular interest to me... This is why I've been in favor of unobtrusive pop-ups (rather like Growl notifications on the Mac). There are only a couple of pieces of information truly necessary for any security UI... who it's from, who says it's from the person it's from, who (ultimately) has been deemed acceptable to provide that kind of information, and whether it's been modified in transit. i.e., certificate subject, certificate issuer, issuer's root authority, and hash-match. We've been discussing this previously, I just want to point out that for S/MIME the UI can be much less intrusive since S/MIME has been much less misused so far and most users using it have a better knowledge generally. That's the front-side of the coin - the same coin of not having a high adoption rate perhaps. BTW, I wonder if there are any reliable studies concerning that claim anyway. But the threats for web sites are currently different then for email, basically because MITMs (and phishing) of web sites are more attractive right now. Having said that, I believe that many people send routinely high valuable information unsecured via email - much higher in value sometimes than some credit card details or so... ... my personal email PIN is the same as my business email PIN is the same as my business contract-signature PIN. (And if you ask me why I have my business contract-signature key at home... haven't you ever worked from home?) Why don't you simply use different smart cards instead? Since Skype happens to be this big bad confusing pile of steaming crud, and since Eddy's using it to enable a red herring attack, I'm going to ignore it. (Hint: Eddy, just because someone else chooses not to do things that you've done doesn't mean they're automatically useless or harmful. I have not seen evidence of Skype being misused, so I will not raise my voice to decry them -- even though you aren't seeing evidence of Skype having done an audit, and are raising the hue and cry based on that. Also, there is nothing wrong with Skype holding private keys, even if they're not an escrow service. All Skype needs to do is ensure that they're only being used on behalf of the account that they're assigned to. Kyle, I personally also use Skype in addition to Jabber/XMPP and have nothing against it. However I must make a stance if their security model is touted as the solution to all evil, because it's not. First of all Skype is a centralized system compared to decentralized systems like the web, email, Jabber and others. There is an inherent difference between those. Second, one must know the facts and evaluate the risks of Skype having all the control. I don't care if Skype is encrypted or not, because I don't have enough information nor control about any of those aspects. Hence I'm treating it basically as an insecure transport - with some encryption layer put on top. However I wouldn't use Skype for the exchange of critical or confidential messages and files. Nor can this approach be applied to the web or email or any other decentralized network, otherwise you'd need from now on use only ONE email server handling all your mail and that of those who interact with you (e.g. all those who will want to send you email will have to have an account at the one-and-only mail server you are using. In this context, some similar scheme might be applied.) Also: I hereby put forth that Startcom is not free. It derives monetary benefit from the personal information that it demands of anyone before they're ever approved to become users of the system. Kyle, you must be very careful about what you are accusing StartCom of!!! Let me explain to you the following: StartCom provides some certification services for free as in free beer. StartCom isn't a free system and never will be. Because certification authorities have generally not much to do with free, besides the potential fees, but quite the opposite. Actually there is almost nothing free in about anything related to CAs - I'm talking as an operator of a CA and from my point of view. Free you can find outside of the CA framework much easier... Concerning StartCom's requirement for registration: StartCom has NEVER, EVER disclosed to any third party any details about its subscribers, NEVER used or misused subscriber information to promote its own products or that of others. StartCom are such suckers, they never sent out even one email encouraging its own subscribers to buy one of their paid products or upgrade to a paid product or service (I'm certain that CAs like Godaddy do that routinely) [*]. StartCom has a company wide policy and a CA policy regulating the use of all subscriber information clearly We are very well aware of the special
