Ian G wrote: > Oh... so it's written in the standard. Are you > saying that the standard defines no way to revoke > a lost CA root? Or that it is impossible to revoke > a CA root? They are two entirely different things. > > OpenPGP does it, the keys can revoke themselves, > and indeed the early docs used to exhort you to > create a revocation certificate for emergency use. > > I don't know what SPKI does - do roots in that system > revoke themselves? In my own designs, we would > just go the manual route and alert everyone. > > No financial system permits such trust to be placed > in a single point of failure; Most of the finance > systems I have seen have defence in depth and > layered "meltdown" plans. For example, there was > Mondex's famous plan to distro new code into the > cards if the crypto got cracked, and all of the > cards schemes operated secret shadow accounting > systems for meltdown motives (originally).
i think there was a discussion 8-9 years ago ... root can sign a CRL revoking itself. the issue was what can a bad guy do with a stolen root private key. they can sign fraudulent certificates and they can sign revokations. however, supposedly revokation was only a one-way operation .... either the bad guys or the good guys might sign a revokation of the root key ... but it was not possible for anybody to sign anything that could unrevoke a revoked root key. The idea was once somebody put the revokation of a root key in play (whether it was the good guys or the bad guys) nobody would be able to reverse the operation. there were numerous statements by major financial transaction operations over the past ten years that they would never convert to a conventional PKI system because they would never deploy any kind of infrastructure that had single points of failures (or even small number points of failure) .... the compromise of a root key (no matter how unlikely) was viewed as traditional single point of failure scenario. there was some study that major financial operations could be out of commission for 4-8 weeks assuming a traditional PKI-based operation and a compromise of root private key. such positions were frequently mentioned in conjunction with "systemic risk" and the preoccupation of major financial operations with "systemic risk" vulnerabilities. The basic motivation for mondex was the float that mondex international got when the next lower level business unit bought one of their "superbricks". Anybody lower than mondex international in the chain were just replacing float lost to the next higher level in the chain. This issue might be considered the primary financial driving force behind the whole mondex movement. It was so significant that mondex internatioinal began offering to split the float with as an inducement for institutions to signup (i.e. the organizations that would purchase a superbrick from them). A spectre hanging over the whole operation was some statement by the EU central banks that basically said that mondex would be given a two year grace period to become profitable, but after that they would have to start paying interest on customer balances held in mondex cards (effectively float disappears from the operation ... and with it much of the interest in institutions participating in the effort). mondex international did do some other things ... they sponsored a series of meetings (starting in san francisco) on internet standard work ... which eventually morphed into IOTP. from my rfc index: http://www.garlic.com/~lynn/rfcietff.htm select "Term (term->RFC#)" in "RFCs listed by" section and then scroll down to Internet Open Trading Protocol 3867 3506 3505 3504 3354 Clicking on the individual RFC numbers fetches the RFC summary for that RFC. Clicking on the "txt=nnn" field, retrieves the actual RFC. various past posts mentioning systemic risk: http://www.garlic.com/~lynn/98.html#41 AADS, X9.59, & privacy http://www.garlic.com/~lynn/99.html#156 checks (was S/390 on PowerPC?) http://www.garlic.com/~lynn/99.html#238 Attacks on a PKI http://www.garlic.com/~lynn/99.html#240 Attacks on a PKI http://www.garlic.com/~lynn/aepay2.htm#fed Federal CP model and financial transactions http://www.garlic.com/~lynn/aepay2.htm#cadis disaster recovery cross-posting http://www.garlic.com/~lynn/aepay2.htm#aadspriv Account Authority Digital Signatures ... in support of x9.59 http://www.garlic.com/~lynn/aadsm2.htm#risk another characteristic of online validation. http://www.garlic.com/~lynn/aadsm2.htm#straw AADS Strawman http://www.garlic.com/~lynn/aadsm2.htm#strawm3 AADS Strawman http://www.garlic.com/~lynn/aadsm3.htm#cstech7 cardtech/securetech & CA PKI http://www.garlic.com/~lynn/aadsmail.htm#variations variations on your account-authority model (small clarification) http://www.garlic.com/~lynn/aadsmail.htm#complex AADS/CADS complexity issue http://www.garlic.com/~lynn/aadsmail.htm#parsim parsimonious http://www.garlic.com/~lynn/aadsmail.htm#mfraud AADS, X9.59, security, flaws, privacy http://www.garlic.com/~lynn/aadsmail.htm#vbank Statistical Attack Against Virtual Banks (fwd) http://www.garlic.com/~lynn/aadsm10.htm#smallpay2 Small/Secure Payment Business Models http://www.garlic.com/~lynn/aepay10.htm#13 Smartcard security (& PKI systemic risk) thread in sci.crypt n.g http://www.garlic.com/~lynn/aepay10.htm#19 Misc. payment, security, fraud, & authentication GAO reports (long posting) http://www.garlic.com/~lynn/2000.html#36 "Trusted" CA - Oxymoron? http://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation practicalities http://www.garlic.com/~lynn/2001c.html#45 PKI and Non-repudiation practicalities http://www.garlic.com/~lynn/2001f.html#35 Security Concerns in the Financial Services Industry http://www.garlic.com/~lynn/2001n.html#54 The demise of compaq http://www.garlic.com/~lynn/2002c.html#7 Opinion on smartcard security requested http://www.garlic.com/~lynn/2002c.html#31 You think? TOM http://www.garlic.com/~lynn/2002l.html#5 What good is RSA when using passwords ? http://www.garlic.com/~lynn/2003l.html#64 Can you use ECC to produce digital signatures? It doesn't see http://www.garlic.com/~lynn/2003m.html#11 AES-128 good enough for medical data? http://www.garlic.com/~lynn/2004j.html#2 Authenticated Public Key Exchange without Digital Certificates? http://www.garlic.com/~lynn/2004j.html#5 Authenticated Public Key Exchange without Digital Certificates? http://www.garlic.com/~lynn/2004j.html#14 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento _______________________________________________ Mozilla-security mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-security
