Julien Pierre wrote: > If you believe that, you should design and propose a standard protocol > that can support KCM and propose it to the IETF . The model of X.509 > certs supported by the SSL protocol and RFC3280 cert path validation as > it exists today is not compatible with KCM . Implementing KCM with X.509 > and SSL (or S/MIME, as in the paper referenced) would be a violation of > the standards, as it would cause the application to produce errors in > cases the standards state are valid . There are very legit reasons for > changing cert and key, such as to increase security if the old key has > been compromised, or if you simply want a larger key size because you > think the key has become crackable. The KCM model breaks apart in those > cases. The X.509 model has revocation to deal with them. > > I browsed through the KCM document and IMO it does not solve the problem > of man-in-the-middle attacks. TTP is not perfect, but has revocation to > recover from mistakes - what does KCM have ?
one could claim that the business process part of KCM is essentially the old business process of registering pin/passwords and then continuing to use them over long periods of time. that is also the PGP model ... of registering public keys in lieu of pin/password ... and doing digital signature verification with the registered public keys; aka the relying party having a set of registered public keys in their trusted repository of public keys. note that, the foundataion for all the PKIs ... are in fact based on using this very business process model for establishing their root trusts. every relying party has to have a trusted repository of registered public keys in order for anything to work (even PKI). frequently, in the case of PKI supported processes ... they attempt to restrict the registration of public keys (in relying party trustued repositories) to just those entities called certification authorities. when relying party trusted repositories are restricted to just the registration of public keys from certification authorities .... then those corresponding public keys are only used to validate digital signatures on special purpose messages called digital certificates. however, as repeatedly pointed out in the past ... the business process of using registered public keys from the relying party's trusted repository of registered public keys to verify digital signatures on messages .... turns out to be the same exact business process that is used whether the digital signatures being verified are applicated to specially formated messages called digital certificates ... or any message ... regarldess of the contents. if the TTP model were to declare that the business process of registerting public keys in the relying party's trusted public key repository was not possible ... then it would also not be possible for the relying party to have certification authority public keys (distributed in self-signed digitgal certificates) available ... and the whole TTP process collapses. note that x.509 identity certificate standards from the early 90s had some interesting standards issues. to glaring issues were 1) the x.509 identity certificate non-repudiation bit ... which somehow conveyed the magical properties that if a relying party could produce a digital certificate that contained the public key and the non-repudiation bit set ... then it prooved that for any document or message digitally signed by the originator ... also carried with it the properties that the signer had read, understood, agrees, approves, and/or authorizes the contents of the signed object. 2) TTPs were somewhat unsure as to what information, furture relying parties, might find of interest. as a result there was some direction to grossly overload x.509 identity certificates with enormous amounts of personal information. by the mid-90s, there was a increasing realization that x.509 identity certificates grossly overloaded with personal information represented significant privacy and liability issues. in the case of #2 and the enormous privacy issues represented by x.509 identity certificates ... you found some number of organizations retrenching to relying-party-only certificates ... some number of past collected postings on relying-party-only certificates http://www.garlic.com/~lynn/subpubkey.html#rpo basically the enormous amounts personal information is moved to some sort of database and replaced in the digital certificate with a database index or lookup value. however, it is trivial to demonstrated that relying-party-only certificates are redundant and superfluous. in the case of #1, there are a variety of issues. a) fundamentally, digital signature verification can be treated as a form of "something you have" authentication ... from the 3-factor authentication model http://www.garlic.com/~lynn/subpubkey.html#3factor * something you have * something you know * something you are there was a direction with x.509 identity certificate standards to mandate that all digitally signed operations required the appending of an x.509 identity certificates. This basically morphed all digital signature authentication operations (even the simplist and most straight-foward authentication) into heavy-weight identification operaton. b) a nominal digital signature authentication even involves the server transmitting some random data as a kind of challenge (as countermeasure to replay attacks). the receiver, digitally signs the data and returns the digital signature for authentication. the contents of the challenge is not normally examined by the person doing the digital signing. the digital certificate non-repudiation bit would imply that if the relying-party could produce any digital certificate with the non-repudiation bit set (for the signer's public key) ... then it was proof that the signer had read, understood, agrees, approves, and/or authorizes what was digitally signed (even if the person had not actually examined what was signed). misc. past posts referencing dual-use attacks (people thinking they are signing random data ... and it turns out to be some valid transaction or contract) and/or non-repudiation attacks (note that the definition of the standards non-repudiation bit has since become significantly depreciated). misc. past posts on dual-use attacks: http://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability http://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability http://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability http://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability http://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability http://www.garlic.com/~lynn/aadsm18.htm#56 two-factor authentication problems http://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor http://www.garlic.com/~lynn/aadsm19.htm#43 massive data theft at MasterCard processor http://www.garlic.com/~lynn/aadsm20.htm#0 the limits of crypto and authentication http://www.garlic.com/~lynn/aadsm21.htm#5 Is there any future for smartcards? http://www.garlic.com/~lynn/aadsm21.htm#13 Contactless payments and the security challenges http://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates http://www.garlic.com/~lynn/2004i.html#21 New Method for Authenticated Public Key Exchange without Digital Certificates http://www.garlic.com/~lynn/2005.html#14 Using smart cards for signing and authorization in applets http://www.garlic.com/~lynn/2005b.html#56 [Lit.] Buffer overruns http://www.garlic.com/~lynn/2005e.html#31 Public/Private key pair protection on Windows http://www.garlic.com/~lynn/2005g.html#46 Maximum RAM and ROM for smartcards http://www.garlic.com/~lynn/2005m.html#1 Creating certs for others (without their private keys) http://www.garlic.com/~lynn/2005m.html#11 Question about authentication protocols http://www.garlic.com/~lynn/2005o.html#3 The Chinese MD5 attack http://www.garlic.com/~lynn/2005q.html#23 Logon with Digital Siganture (PKI/OCES - or what else they're called) _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
