MisterSSL, I'm rather appalled that you are ignoring the realities of US government user requirements. I can state with enough knowledge of regulation and policy behind me that I believe that it is primarily due to your lack of acknowledgement of the requirements in-place that Firefox has not enjoyed greater US government agency penetration. These requirements are set not merely in stone but in the Rock of Gibraltar.
You, in your office of NSS component manager, continue to insist that there is no reason to allow any central Administrator-defined policy to make any change whatsoever to: a) the choice of root certificates used b) the choice of PKCS#11 modules used c) the prevention of unapproved PKCS#11 modules from being used d) any cryptographic requirement whatsoever To the US government, users have no privacy, because the computers are never under any circumstances to be used for non-US-government business or for personal use. This goes for civilian agencies as well as for military agencies. Users, when they are on the clock, are agents of the US government, subject to monitoring and auditing of resource usage. For all intents and purposes, what the user "prefers" is irrelevant. Computers are tools, and are provided as such. This is an extreme version of fairly-common requirements of corporate and educational policies. Educational policies are often as difficult to change as governmental policies (since many schools are public institutions and are thus bound by requirements common to all public institutions in the given jurisdiction); corporate policies often appear just as difficult to change to people "in the trenches" who have to make things work in the face of mandates from on high. It must be noted that these mandates often have Governmental origin; for example, Sarbanes-Oxley. In addition, private educational and health-care entities are subject to additional requirements (the Buckley amendment in the former case, and the Health Insurance Portability and Accountability Act in the latter) -- as well as the standard regulations affecting all fiduciary entities including banks, insurance companies, accountancies, lawyers, etc. In all circumstances, there are two conflicting needs: the need to ensure that an approved cryptographic algorithm is used to protect the information to a minimum standard, and the Judiciary's mandate to ensure that any and all electronic communication can be readily and reliably retrieved. Microsoft makes available tools to ensure, for example, that only FIPS-validated cryptography can be used by the CryptoAPI. This is one reason why they have sought FIPS validation for their cryptographic modules so stringently -- among other things, the CSRC lists certificate numbers 1010, 1009, 1008, 1007, 1006, 1005 and 1004 for Windows Server 2008, and certificate numbers 1003, 1002, 1001, and 1000 for Windows Vista. 11 certifications of validity spanning two products. With the administrator-mandated policy available "require FIPS-compliant cryptography", there is little wonder why Windows (for the OS platform), Internet Explorer (for web browsing), and Outlook (for messaging, calendaring, and all other forms of inter-user interaction) are so widely adopted. One of the reasons is that they are so easy to update, at a Domain level. The Domain contains the Policy. The Policy may include a list of certificates to be installed into either the machine's root authority store or the user's root authority store. The Policy may also include a machine-level "require FIPS-compliant cryptography" setting. Upon logon to the Domain, the machine obtains the Policy and applies it -- as well as applying it repeatedly over the course of the logon session. (Among other things, this provides for a means of updating the list of root authorities dynamically.) Such a Policy application cannot be said to exist for Firefox. There is no way, upon logon, to enforce the addition of a FIPS-validated PKCS#11 module. There is no way, upon logon, to enforce the addition of organization-policy mandated certificates. There is no way, upon logon, to remove unapproved PKCS#11 modules. There is no way, upon logon, to prevent the installation of new PKCS#11 modules. There is no configuration file that NSS reads, and there is no enforcement in NSS itself. The commonly-proposed alternative is to use the Client Customization Kit. This is a kit that creates an XUL file to customize the installation of Firefox, and which creates an extension which applies the XUL-formatted policy file. At first glance, this would appear to meet the requirements. However, there are some MAJOR problems which prevent it from being useful. 1) It is only available as source code. 2) The source code is only available from CVS. 3) It apparently requires building a full, customized version of Firefox (which, among other things, requires a full compiler toolchain installation, which is itself by no means a trivial task) 4) There is no version which claims to support Firefox 3. 5) There is no documentation which suggests that it affects Thunderbird or any other Mozilla product. 6) There is no documentation which suggests that it precludes the addition or usage of unapproved PKCS#11 modules. Simply put, the CCK is not an option for people who prefer to use Firefox 3, or for anyone who wishes to use or deploy any other Mozilla product. For most people it has been recommended to, it never truly was an option. I respect your tenacity, MisterSSL, but I sincerely hope that you realize that it is solely YOUR office and YOUR office's mandates -- mandates which you have repeatedly been requested to change, each and every request completely ignored and the requestor directed to something which cannot meet their needs -- which is preventing wider adoption of Firefox, Thunderbird, and all other Mozilla Foundation products. Sincerely, Kyle A Hamilton (For reference: http://www.mozilla.org/projects/cck/ http://www.mozilla.org/projects/cck/firefox/ These are the only pages I could find which came up on a "Client Customization Kit Mozilla" search on google.) _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
