Some of the trademark messaging of the policy are typically found in terms like "backup", "need for mobility" etc. You can always tell an indoctrinated vendor, by analysing the messaging and the mental model. It often jars with what the average person actually does. (Do you backup your files?! never mind you keys!?)
For background terms, we can note that the US spends about 200M on a special program to "convince" commodity vendors to adopt the current key escrow policy. Most of it goes on indoctrination, and monitoring of the commodity art. The rest goes on finding deception tactics that work in 80% of the platforms that most folks use, so false assurance is a workable attack vector. (Its unclear the degree to which NIST is complicit its FIPS 140-2 program in this deception capability, note. The NSA/NIST agreement may have been secretly modified, since 9/11, and NIST may not be so placable, as before).
Whilst we convinced Clinton in 1997 that key escrow enforcement via cert issuing was the WRONG thing to do (against $50M of FBI lobbying effort the other way (well meaning policywise,. but just stupid technique in effect, with the usual personal attacks against dissenters!)), the political compromise was a creation of a center with a 200M annual budget whose ongoing mission is to "study" "key escrow equivalents". In practice, this means indoctrination, vendor coercian, penetration analysis, and continuual improvement of deception schemes. In reality, the policy shift merely shifted funds that DoD was spending anyways on deception and false assurance messaging - it simply transferred miliary tactical planning, into a civilian center run by the same contractor (MITRE)!.
For my part, I was happy with the compromise, in 1998. Mandatory Key escrow itself is a debatable issue, for which I have mixed feelings. Key escrow enforcement via cert issuing was just wrong (even though they already had VeriSign/Thawte-based enforcement on board and ready to go, at that point!). Maintaining existing deception capabiities seemed like a reasonable concession, for avoidance of cert-based enforcement. CAs must not be key escrow authorities. Period. This is not to say that others cannot play that role...
I think my bottom line on this, as a modernised political stand, is this: surveillance per se is a fact of life, and "overt acceptance is necessary extant, sociopolitical reality" - as a give and take for increased personal privacy technology availa bility. If we can agree on the this policy middle ground , I would particularly want the arch-conservatives (i.e. most folk over 50) to personally feel the effect, however, of its extreme nature - e.g. be auto-fined, harshly, every time they drive at 31 mph/kmh.) I want such radical policies and practices in place, we can ensure there are swings in the accepted surveillance policy definition over the next 50 years, so we achieve an equilibrium which is tolerable, for the totally connected word in which we all live, now.
Whilst the UK is backwards on technology deployment, its advanced in its survieillance policy formulation - something we can learn from, perhaps. UK now has the capability to detect speed violations between 2 given points, analysing average speed, but chooses NOT to deploy the capability when enforcing speed controls, using automatic fines and citations etc. This is what we need to do - limit the degree to which an accepted surveillance capability is deployed - ensuring natural convervatism per se doesnt automtically lead to ever increasing surveillance.
An interesting topic, that boils down to on one minor technical issue! ARE keys are exportable, or not, by API DESIGN!
Peter.
From: Tommaso Cucinotta <[EMAIL PROTECTED]> Reply-To: MUSCLE <[email protected]> To: MUSCLE <[email protected]> Subject: Re: [Muscle] Certificate generation Date: Thu, 12 May 2005 19:31:20 +0200
David Corcoran ha scritto:Hi,
The method described there generates the keypair in your browser and sends the certificate off to the CA to be signed. This is then encrypted into a file (PKCS#12) that you can backup. You then can import this PKCS#12 file (by providing the encryption password) onto the token. So the security of this method is really based upon on secure your desktop is ....
Security of *any* method is somewhat based on the security of the terminal on which you're operating while you generate your keypair. This becomes absolutely true with MuscleCard, as a feature that is missing since a too long time is distinguishing between a key that has been imported from the outside, and one that has been generated on the card, thus you would never understand if your terminal transmitted a copy of your key to anyone else..... the terminal is *supposed* to be trusted, when you format a card :-)
Even if we add such a feature, you would hardly distinguish if your terminal just replaced the MuscleCard Applet with a different one that claims your keys are NEVER_EXPORTABLE/EXTRACTABLE whereas they were imported from the outside, again, the trusted terminal is an assumption in the process.
Bye,
Tommaso. _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
