from: http://cryptome.org/nsakey-ms-dc.htm Click Here: <A HREF="http://cryptome.org/nsakey-ms-dc.htm">Microsoft and Duncan Campbell on NSA_KEY in Mic…</A> ----- 27 April 2000. Thanks to Duncan Campbell. This supercedes a shorter version offered here yesterday. ------------------------------------------------------------------------ Background: Duncan Campbell gave a presentation on Global surveillance and the Echelon network at the Computers, Freedom and Privacy 2000 (CFP2000) conference held in Toronto, Canada from 4-7 May 2000. During the presentation, he instanced the NSA_KEY controversy as one of a number of issues related to security and surveillance. Richard Purcell, Microsoft’s Director of Corporate Privacy, attended the CFP2000 conference. After the presentation, Purcell approached Campbell. He said that he wished to resolved the doubts about NSA_KEY. He would see that this was done. The following correspondence then took place [see parties]: ------------------------------------------------------------------------ 7 April 2000 Hi Duncan - I'm a colleague of Richard Purcell at Microsoft -- I work in the Microsoft Security Response Center, so Richard's path and mine cross quite a bit. Richard mentioned to me that he recently met you, and you had some questions regarding the so-called "NSA key". I was involved in investigating the claims that were made about the key, and I think I should be able to answer your questions. Can you tell me what questions you have? Look forward to talking further with you, Scott Culp Microsoft Security Response Center ------------------------------------------------------------------------ Toronto 8 April 2000 Dear Scott Culp By way of reference, I wrote the European Parliament report on communications surveillance, and am currently preparing a further report for the Electronic Privacy Information Center in Washington DC (EPIC). In both of these connections I will be grateful for your response. Those that I have seen to date have been insufficient. Thank you for offering to remedy this. 1. In relation to the NSA_KEY, Mr Purcell stated that it was included because of NSA requirements. Is this correct? 2. What is the requirement? If so :- 3. When was it communicated to Microsoft? 4. May I please see a copy? If not, why not? 5. Microsoft has stated that it has sole possession of the NSA_KEY. Is this correct? Is it still true? 6. I understand that Microsoft has denied that the purpose of the key is to enable the US government to sign its own CAPI modules without disclosing them or their code to Microsoft. Is this correct? Is it still correct? 7. Irrespective of the answers to the above, what is Microsoft's understanding of why it was require to include these keys. I may have further questions, but these will probably only arise if you are unable to give candid and complete answers to the above. However, in a separate area, I have another question. 8. In IE4 and 5, the export versions are restricted to 40 bit security. My understanding is that in fact the software generates a 128 bit key and encrypts with this; but 88 bits of the session key are broadcast with the message. Is this correct? If not, what is the accurate position? 9. Please describe with precision the form in which the message containing the 88 disclosed bits is sent from the browser when operating an SSL connection. (I am aware that the export position has recently changed.) Duncan Campbell ------------------------------------------------------------------------ Toronto 8 April 2000 Dear Richard Thanks for taking the time to talk to me at the conference. I have responded to Scott Culp, and hope that I will be getting forthright answers. Yours sincerely, Duncan Campbell ------------------------------------------------------------------------ Tue, 11 Apr 2000 Hi Duncan Thanks for your note. The two questions regarding the specific way that we handle 40-bit crypto are a bit out of my usual area -- I'm researching them and will get answers to you shortly. Meantime, I do want to answer the "NSA key" questions right away. Here goes: 1. In relation to the NSA_KEY, Mr Purcell stated that it was included because of NSA requirements. Is this correct? Richard's answer was correct, but I think I may be able to give you a bit more precise answer. To do so, I need to provide a little background. CryptoAPI is an architecture that provides applications with a standard way to request cryptographic functions such as encryption/decryption, digital signing, and so forth. Before CryptoAPI was available, if a software developer was writing an application that needed to use cryptography, he had two choices, both bad. He could write his own cryptographic functions and incorporate them into his code. However, cryptography is a rather specialized science, and it's easy to make a mistake that compromises the security of the cryptography. Alternatively, he could use a third party's pre-written cryptographic software, and call it from his own application. The problem here is portability. Every third-party's cryptographic implementation would likely have a different calling interface, so an application that used such an implementation would be "locked in" to the particular third-party software. CryptoAPI makes developers' lives easier, because it standardizes how cryptographic services are requested. This standardization benefits developers who write general-purpose software, as well as specialists who write cryptographic software. General-purpose developers no longer have to write their own cryptographic code, and they don't have to change their software when they want to change the third-party implementation they use. Cryptographic developers only have to code a single calling interface, rather than potentially having to customize their calling interfaces for different users. More important, CryptoAPI creates new market opportunities for crypto developers by making it easier for general-purpose developers to use cryptography. CryptoAPI ships as part of every Microsoft platform. Several cryptographic modules -- known as Cryptographic Service Providers (CSPs) -- ship by default, and customers can install additional CSPs at will. The fact that third-party cryptographic software can run under our CryptoAPI architecture raises an issue that ultimately touches on the raison d'etre for the so-called "NSA key". As a US company, Microsoft is bound by US export laws. Not only are we required to ensure that all of our products comply with US export laws, we're also required to make reasonable efforts to ensure that technologies like CryptoAPI also support US export law. Specifically, Microsoft has an obligation to make reasonable efforts to ensure that only CSPs that comply with US export law can be used in CryptoAPI. The signing keys in question are a mechanism for doing that. The US Department of Commerce, Bureau of Export Administration (BXA) has oversight authority regarding US export laws. However, they rely on the National Security Agency to perform technical evaluations regarding cryptographic export. NSA doesn't specify how an architecture like CryptoAPI must operate; it only provides a technical opinion regarding whether the architecture meets the export requirements. In short, NSA did not tell Microsoft to build CryptoAPI a certain way, it only evaluated our design and advised the BXA as to whether the design met export law. So the back-up signing key is present because the design that we submitted to the NSA for technical review included a back-up signing key, the NSA opined that this design satisfied US export requirements, and BXA issued the necessary license approvals. 2. What is the requirement? The export regulatations for cryptography are provided in the BXA's Export Administration Regulations (EAR), 15 C.F.R. Parts 730-774. The specific regulations that are of interest regarding CryptoAPI are discussed in Part 740, section 17, paragraph f, "Open Cryptographic Interfaces". 3. When was it communicated to Microsoft? The BXA regulations are a matter of public record. 4. May I please see a copy? All of the EAR documentation is available online. Here are some specific references: * The BXA's web site is http://www.bxa.doc.gov * An overview of the BXA encryption regulations is available at http://www.b xa.doc.gov/Encryption/regs.htm * A complete listing of BXA regulations is available at http://w3.access.gpo .gov/bxa/ * The entire EAR is available at http://w3.access.gpo.gov/bxa/ear/ear_data.h tml * Part 740 of the EAR is available at http://frwebgate.access.gpo.gov/cgi-bi n/getdoc.cgi?dbname=bxa&docid=f:740.pdf (Section 17, paragraph f is on page 38 of the document) 5. Microsoft has stated that it has sole possession of the NSA_KEY. Is this correct? Is it still true? Microsoft does not share any of its private keys with any third party. That includes the CSP signing keys, and the so-called "NSA key" in particular. 6. I understand that Microsoft has denied that the purpose of the key is to enable the US government to sign its own CAPI modules without disclosing them or their code to Microsoft. Is this correct? Is it still correct? We have previously stated, and continue to state, that the purpose of the keys is *not* to enable third parties, including the US Government, to sign their own CSPs. This is in keeping with our historical stance in opposition to proposals such as Government key escrow. 7. Irrespective of the answers to the above, what is Microsoft's understanding of why it was require to include these keys? First, let's discuss the signing keys and the signing process in in more detail. The first thing to note is what the signing means, and more importantly, what it does not mean. When Microsoft signs a CSP, it means only one thing -- that Microsoft has verified that the vendor's export paperwork is in order. It does not mean that we have verified the operation of the CSP. Some CSPs, such as the ones Microsoft provides by default, have been validated by third-party experts, but this is not a requirement for signing a CSP. Likewise, the signing is not intended as a security mechanism to prevent an adminstrator from modifying the CSPs. Some CSPs allow the administrator to supply his own code to perform certain cryptographic functions more efficiently -- this code might, for instance, interface to a hardware accelerator card. As long as these modifications don't affect the export-compliance of the CSP, the signature doesn't have to prevent it. When a third party wants to market a new CSP, they bring it to Microsoft and assert that either of two cases is true: (a) they intend to deploy the CSP only within North America, or (b) they intend to deploy the CSP outside of North America. In the former case, it is the vendor's responsibility to ensure that the CSP isn't exported, and we can immediately sign it. In the latter case, we confirm that the vendor has gotten export approval, then we sign the CSP. The keys in question are the ones used to sign the CSPs. One is a primary and one is a backup. We have been asked frequently why we have two keys. The answer is that it is strictly a disaster-recovery precaution. Suppose we had only one signing key. There's a private and a public half to the key -- the private half is held by Microsoft, and the public half is in every copy of Windows 95, 98, Windows NT and Windows 2000. Now suppose that the building that houses the private key were destroyed by an earthquake (Seattle is in a high-risk area for earthquakes, so this isn't as far-fetched as it might sound). All of the previously-signed CSPs would continue to work, because our customers could still verify the signatures. However, if we wanted to sign additional ones, we would need to create a new signing key and somehow distribute the public half of that key to all of our customers. That would be a mammoth job. That's why we have a primary and a backup key. The private half of the primary key is in one location, and the private half of the second key is in another. Both are under Microsoft's sole control, and we do not share them with anyone. The public half of both keys is included in every copy of Windows95, 98, Windows NT and Windows 2000. If the primary key were to be destroyed, we would simply begin signing new CSPs with the backup key, with no disruption to our customers. However, we have never needed to sign a CSP with the backup key. I'm sure you'll have some additional questions after reading the above. Just let me know what they are, and I'll do my best to answer them. Regards, Scott ------------------------------------------------------------------------ Tue, 11 Apr 2000 Hi Duncan - I was able to get answers for the last two questions on the list. Here they are: 8. In IE4 and 5, the export versions are restricted to 40 bit security. My understanding is that in fact the software generates a 128 bit key and encrypts with this; but 88 bits of the session key are broadcast with the message. Is this correct? If not, what is the accurate position? In some respects, this is a historical question at this point, as the new US export controls published in January of this year allow us to ship 128-bit encryption in our products worldwide. Not only does this mean that we'll be able to distribute future products worldwide with 128-bit crypto, it also means that customers with existing products can upgrade them immediately to 128-bit crypto. So, customers using IE 4.0 and 5.0, the international versions of which were restricted to 40-bit crypto, and IE 5.01, the international version of which was restricted to 56-bit crypto, can apply the IE High Encryption Pack and upgrade to 128-bit crypto. (The High Encryption Pack is available at http://www.microsoft.com/windows/ie/download/128bit/intro .htm). However, when 40- or 56-bit crypto is used in IE, the handling of the keys is done per the standard industry specifications: SSL and its successor, TLS. We must follow these specifications, or our implementation wouldn't be interoperable with other vendors'. SSL/TLS define a negotiation phase, during which the client and the server determine which cryptoalgorithm and key lengths will be used. Once the algorithm and key length have been negotiated, a table indicates exactly how the "effective" key material is expanded into the actual key that's used. For instance, if the client and server agree on 40-bit key, the table tells how to package the 40 key bits within the 128 bit key. The exact packaging varies by cryptoalgorithm and key length, but the main point is that we do it exactly the same way that every other vendor does, according to industry standard specifications. 9. Please describe with precision the form in which the message containing the 88 disclosed bits is sent from the browser when operating an SSL connection. The best references here are the specifications themselves: * SSLv3: http://home.netscape.com/eng/ssl3/ssl-toc.html Appendix C of this document provides the table that I mentioned above. * TLSv1: The TLS Working Group, Charter and related protocol specifications are described at http://www.ietf.org/html.charters/tls-charter.html * See especially the TLS Protocol Version 1, IETF RFC 2246 at http://www.iet f.org/rfc/rfc2246.txt?number=2246 Hope that helps! Please let me know if I can answer any other questions. Regards, Scott ------------------------------------------------------------------------ Washington DC 24 April 2000 Dear Scott MS / NSA_KEY Thank you very much for your detailed reply on 11 April. I have further and supplementary questions. I look forward to your responses. Many thanks Duncan Campbell 1. In relation to the NSA_KEY, Mr Purcell stated that it was included because of NSA requirements. Is this correct? You replied: […] The US Department of Commerce […] rely on the National Security Agency to perform technical evaluations regarding cryptographic export. NSA doesn't specify how an architecture like CryptoAPI must operate; it only provides a technical opinion regarding whether the architecture meets the export requirements. In short, NSA did not tell Microsoft to build CryptoAPI a certain way, it only evaluated our design and advised the BXA as to whether the design met export law. So the back-up signing key is present because the design that we submitted to the NSA for technical review included a back-up signing key, the NSA opined that this design satisfied US export requirements, and BXA issued the necessary license approvals. Q May I please have a copy of the "design that we submitted to the NSA for technical review [which] which included "a back-up signing key", and information as to when it was submitted. 2. When was [the requirement] communicated to Microsoft? You replied: The BXA regulations are a matter of public record. That is with respect, not the answer to the question I asked. I repeat my question. 3. Microsoft has stated that it has sole possession of the NSA_KEY. Is this correct? Is it still true? You replied: Microsoft does not share any of its private keys with any third party. That includes the CSP signing keys, and the so-called "NSA key" in particular. Q Again, with respect, would you for the sake of the avoidance of doubt to please answer these questions directly. I repeat my questions. 4. Irrespective of the answers to the above, what is Microsoft's understanding of why it was require to include these keys? You replied: […] When a third party wants to market a new CSP, they bring it to Microsoft and assert that either of two cases is true: (a) they intend to deploy the CSP only within North America, or (b) they intend to deploy the CSP outside of North America. In the former case, it is the vendor's responsibility to ensure that the CSP isn't exported, and we can immediately sign it. In the latter case, we confirm that the vendor has gotten export approval, then we sign the CSP. The keys in question are the ones used to sign the CSPs. One is a primary and one is a backup. […] it is strictly a disaster-recovery precaution. 5. Has Microsoft to date signed any CSP or any other aplication with the second key? Has it ever been used, for anything? You further replied. […] "Suppose we had only one signing key. There's a private and a public half to the key -- the private half is held by Microsoft, and the public half is in every copy of Windows 95, 98, Windows NT and Windows 2000. Now suppose that the building that houses the private key were destroyed by an earthquake (Seattle is in a high-risk area for earthquakes, so this isn't as far-fetched as it might sound). All of the previously-signed CSPs would continue to work, because our customers could still verify the signatures. However, if we wanted to sign additional ones, we would need to create a new signing key and somehow distribute the public half of that key to all of our customers. That would be a mammoth job That's why we have a primary and a backup key. The private half of the primary key is in one location, and the private half of the second key is in another." 5. Please explain with precision why this is a better security policy than lodging two or more copies of the private key at geographically dispersed, secure locations. More questions. 6. What is the label of the first [primary] key ? Has it always had that name? 7. Has the second key always been present? Was it always labelled NSA_KEY ? If not, when was it first introduced and what was it called? 8. Would it be fair and accurate and complete to summarise Microsoft’s position as follows. "On date XXXX we were advised by BXA of the export regulations that would apply to our export of new products containing cryptographic software. Starting on date YYYY, we then developed. We had no communication of any type with or from NSA about how CAPI should be designed. We then considered, purely internally, the precautions we should take for disaster recovery. We opted to have two keys, stored at separate locations. This was nothing whatsover to do with NSA. We knew that their technical review of the software would arise only when it was completed and submitted. They did not levy any requirements on us in relation to CAPI at this or any other time. Our programmers decided to call the first key ??? and the second key NSA_KEY. This did not relate to anything that NSA had required, because there were no requirements other than to show them the software and obtain their approval. Nor did it relate to any discussions with NSA about the design of CAPI, since there were no such discussions. There was in fact, no reason whatsoever to label the key NSA-KEY, rather than (for example) BAK_KEY or BXA_KEY or KEY_2. Its just a complete mystery to us why the programmer concerned chose that name. On a later date, namely ZZZZZ, we submitted our CAPI design to NSA. There was no discussion and no requirement for changes. They approved it. We then distributed it, starting on day QQQQQQ." If this is not suitable, how would you put it instead? ------------------------------------------------------------------------ Wed, 26 Apr 2000 Hi Duncan - Thanks for your note. I believe I've answered all your questions below, but I'm going to need to draw the line at this round of questions, as it seems to me that we've reached the end of productive exchange with the most recent set of questions. Regards, Scott 1. May I please have a copy of the "design that we submitted to the NSA for technical review [which] which included "a back-up signing key", and information as to when it was submitted? If you're asking to review the design documents, I'm afraid I will have to decline. Like most companies, Microsoft must protect its intellectual property, and we simply don't release internal documents like these. However, we have provided complete design documentation to several governments as part of the various security evaluations we successfully completed. This included full design documentation for CryptoAPI. It seems reasonable to assume that if any of these security experts had any reservations about the adequacy or intent of the design, it would have been reflected in their findings. 2. When was [the requirement] communicated to Microsoft? You replied, "The BXA regulations are a matter of public record." That is with respect, not the answer to the question I asked. I repeat my question. Actually, it is the correct answer. The point is that US export restrictions are public information, and Microsoft followed exactly the same process that any other vendor would have to follow in order to export approval for such a product. The specific sequence of events was as follows: * In the 1980s, a precedent-setting case resulted when a US company was denied the ability to export a telephone design that left an open socket for foreign crypto chips to be plugged in. The State Department ruled that such "crypto with a hole" mechanisms were covered by export controls, and made this view widely known at public conferences, industry discussions, etc. * In 1992-93, Windows NT program management identified a need for a cryptographic API set that would allow third-party cryptographic modules to be installed. Because of the obvious parallels to the "crypto with a hole" case, we went to State Department, who confirmed that they would not grant export approval for our design unless it controlled which third-party cryptographic modules could be installed. * We proposed using a signature mechanism to limit access to only export-approved CSPs (or CSPs that aren't subject to export controls) * State Department, after technical review from NSA, approved our design for export. 3. Microsoft has stated that it has sole possession of the NSA_KEY. Is this correct? Is it still true? You replied, "Microsoft does not share any of its private keys with any third party. That includes the CSP signing keys, and the so-called 'NSA key' in particular." Again, with respect, would you for the sake of the avoidance of doubt to please answer these questions directly. I repeat my questions. We have sole possession of the so-called "NSA key", just as we have sole possession of all our keys. We do not share any of our private keys, including this one. 4. Has Microsoft to date signed any CSP or any other aplication with the second key? Has it ever been used, for anything? Microsoft has never used the backup key to sign any production CSP or application. Please note that I've used the word "production" in the previous sentence. I'm sure that as part of system testing, we have signed test CSPs using this key. 5. Please explain with precision why this is a better security policy than lodging two or more copies of the private key at geographically dispersed, secure locations. The short answer is that creating multiple copies of the same key would be no better or worse security than the method we chose. The two methods basically amount to the same thing. The longer answer is that CryptoAPI was designed under a fairly tight schedule in 1993. We could not create multiple copies of the same key, because the private portion of the key was generated on and lodged in a hardware device. In order to make a second copy of the key, we would have needed to completely replicate the hardware device -- but this is a difficult and time-consuming process and our ship schedule made this infeasible. On the other hand, it is quite easy to simply create a second key on a completely different hardware device. This is what we chose to do, and it is no better or worse security than replicating a single key to multiple locations. It's important to note that this design critique isn't relevant to the question at hand. If we had designed CryptoAPI to use a single signing key, and had made multiple copies of it, we could just as easily have been falsely accused of giving one of the copies to the NSA. This is true of any signing mechanism -- the ultimate security of the system depends on how the key material is controlled. As we've previously noted, Microsoft has sole control of the keys used to sign CSPs. 6. What is the label of the first [primary] key ? Has it always had that name? The variable name for the primary key is KEY. 7. Has the second key always been present? Was it always labelled NSA_KEY ? If not, when was it first introduced and what was it called? The backup key has always been present in CryptoAPI. The variable name for the backup key was NSA_KEY, and it retained this name until Fall of 1999, at which point it was renamed KEY2. 8. If this [summary of Microsoft's postion] is not suitable, how would you out it instead? In 1993, Microsoft developed CryptoAPI. As a cryptographic product, it was subject to the normal cryptographic export control mechanism. At the time, the Department of State exercised overall control of the licensing process, but NSA had the responsibility to perform all technical reviews. (Overall control later transitioned to Department of Commerce). We submitted a design that passed the technical review, and were granted an export approval. Because CryptoAPI is a cryptographic enabling technology, our design was required to ensure that only CSPs that had themselves been granted export licenses or were not subject to US export restrictions could run under it. The design we developed checks for a digital signature on the CSP at execution time, and only allows a CSP to run if it has been signed using either of two signing keys. Microsoft has the responsibility to verify that every new CSP either has an export license or does not need one, after which point it signs the CSP. We chose to implement a design using two keys, a primary and a backup, for disaster recovery purposes. The rationale behind this design was that if the primary key were destroyed, we could sign new CSPs using the backup. There were alternative designs that could also have worked, but this is the design that we submitted and the Department of State approved. We have never needed to use the backup key, which gained noteriety in 1999 when it was learned that the variable name for it was "NSA_KEY". (The name reflects the fact that the key is present in the design to satisfy the NSA technical review per US cryptographic export regulations). As a corporate policy, Microsoft does not share any of its private key material with any third party, and this holds for the specific case of the so-called "NSA key" as well. Microsoft has historically opposed the various government key escrow schemes that have been proposed, and our handling of cryptographic material is consistent with this stance. ------------------------------------------------------------------------ Washington DC 26 April Dear Scott, You have kindly taken the time on two recent occasions to answer at some length the questions that I have put to you about the NSA_KEY affair. Thank you. However, I am saddened and dismayed by the terms in which you began your second reply, namely : "I'm going to need to draw the line at this round of questions, as it seems to me that we've reached the end of productive exchange with the most recent set of questions." My view is different. I believe we are still a long way from any resolution of this issue. I have further questions. However, I would not seek to irritate you by putting questions if you now restate to me that you and Microsoft will refuse to reply further. But I will say this. I was drawn into this correspondence at the specific invitation of a senior Microsoft official attending the Computers, Freedom and Privacy conference in Toronto three weeks ago. My enquiries are not idle; I wrote a report for the European Parliament, which may shortly call for new reports including on this very issue. I am presently preparing a further report on electronic surveillance issues for EPIC, the Electronic Privacy Information Center in Washington DC. The issues are important as they go to the question of what level of trust consumers, especially outside the US, can put in the Windows operating system. We have aired important issues, and I would like to continue doing so. If Microsoft now insists on withdrawing from the dialogue it initiated, I will seek the comments and assistance of the wider cryptographic community to facilitate my understanding and reporting on these issues. To this end, an initial step I propose to take is to publish our exchanges on the web, in the first instance on relevant listservs and at the well-known US site covering these issues, www.crytome.org. This is a debate which belongs on the public record. Others will draw their conclusions from Microsoft's bringing down the curtain (if you do). I will draw my own conclusions when I have heard what they have to say. In closing, I do think that you and your colleagues ought to carry on talking to those concerned about privacy and security, and I urge you to so. I look forward to hearing from you shortly. Yours, Duncan Campbell ------------------------------------------------------------------------ The parties: Richard Purcell Director of Corporate Privacy (US-COO-Division Management) Microsoft One Microsoft Way Redmond WA 98052-63999 [EMAIL PROTECTED] Scott Culp Microsoft Security Response Center Microsoft One Microsoft Way Redmond WA 98052-63999 [EMAIL PROTECTED] Duncan Campbell Senior Research Fellow Electronic Privacy Information Center Suite 200 1718 Connecticut Avenue NW Washington DC 20009 USA [EMAIL PROTECTED] ----- Aloha, He'Ping, Om, Shalom, Salaam. Em Hotep, Peace Be, All My Relations. Omnia Bona Bonis, Adieu, Adios, Aloha. Amen. Roads End <A HREF="http://www.ctrl.org/">www.ctrl.org</A> DECLARATION & DISCLAIMER ========== CTRL is a discussion & informational exchange list. Proselytizing propagandic screeds are unwelcomed. Substance—not soap-boxing—please! These are sordid matters and 'conspiracy theory'—with its many half-truths, misdirections and outright frauds—is used politically by different groups with major and minor effects spread throughout the spectrum of time and thought. That being said, CTRL gives no endorsement to the validity of posts, and always suggests to readers; be wary of what you read. CTRL gives no credence to Holocaust denial and nazi's need not apply. Let us please be civil and as always, Caveat Lector. ======================================================================== Archives Available at: http://home.ease.lsoft.com/archives/CTRL.html <A HREF="http://home.ease.lsoft.com/archives/ctrl.html">Archives of [EMAIL PROTECTED]</A> http:[EMAIL PROTECTED]/ <A HREF="http:[EMAIL PROTECTED]/">ctrl</A> ======================================================================== To subscribe to Conspiracy Theory Research List[CTRL] send email: SUBSCRIBE CTRL [to:] [EMAIL PROTECTED] To UNsubscribe to Conspiracy Theory Research List[CTRL] send email: SIGNOFF CTRL [to:] [EMAIL PROTECTED] Om
