Re: About that "Mighty Fortress"... What's it look like?
On Fri, 30 Jul 2010 19:40:49 -0700 Ray Dillinger wrote: > Assume, contra facto, that in some future iteration of PKI, it > works, and works very well. > > What the heck does it look like? > > At a guess Anybody can create a key (or key pair). They > get one clearly marked "private", which they're supposed to keep, > and one clearly marked "public", which they can give out to anybody > they want to correspond with. > > Gaurantors and certifying authorities can "endorse" the public key > for specific purposes relating to their particular application. > Your landlord can "endorse" your keycard to allow you to get into > the apartment you rent, the state government can "endorse" your > key when you get a contractor's license or private investigator's > license or register a business to sell to consumers and pay taxes, > etc. You are still following the same model that has failed over and over and over again. "Endorsing" keys is the same "we have no internet, so we rely on having big books to tell us whether a person's credit card was stolen" model. There is no rational reason at all that someone should "endorse" a key when it is possible to simply do a real time check for authorization. There is no reason to sign a key when you can just check if the key is in a database. > And you can revoke your endorsement of any particular key, at any > time, for any reason. How? If you have to do a real time check for every use anyway, the signature on the key is unnecessary as you can just ask "is this user authorized". If you can't do a real time check, then the system fails anyway. Either way, there is no logical or architectural reason for signatures on keys. > I think this model is simple enough to be understood by ordinary > people. I challenge you to explain any such model to my mother successfully. Indeed, I think any model that needs to be explained to anyone has already failed. A good model is one in which if you screw up, nothing bad can happen. For example, if you go to the phisherman's web site instead of your bank's, nothing you can possibly do will endanger your security. The worst that can happen is you end up frustrated and puzzled, but you never can leak information to the phisherman. It may be impossible to achieve this with complete perfection, but if, for example, it would be necessary for someone trying to steal your credentials to social engineer you into get actual physical access to a smart token or some such for a while to get at your bank account, things are now "good enough" for most purposes. Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: About that "Mighty Fortress"... What's it look like?
On Sat, 31 Jul 2010, Perry E. Metzger wrote: > You are still following the same model that has failed over and over > and over again. "Endorsing" keys is the same "we have no internet, > so we rely on having big books to tell us whether a person's credit > card was stolen" model. > > There is no rational reason at all that someone should "endorse" a > key when it is possible to simply do a real time check for > authorization. There is no reason to sign a key when you can just > check if the key is in a database. Each real-time check reveals your interest in the check. What about privacy implications? -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: About that "Mighty Fortress"... What's it look like?
Alexander Klimov writes: >Each real-time check reveals your interest in the check. What about privacy >implications? What about them? (Have you ever seen a PKI or similar key-using design where anyone involved in speccing or deploying it genuinely cares about privacy implications? Not only have I never seen one, I've even been to a talk at a conference where someone was criticised for wasting time on privacy concerns). In any case if it really is a concern, there are any number of ways of blinding or masking what's going on. Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: About that "Mighty Fortress"... What's it look like?
On Tue, 17 Aug 2010 15:04:00 +0300 Alexander Klimov wrote: > On Sat, 31 Jul 2010, Perry E. Metzger wrote: > > There is no rational reason at all that someone should "endorse" a > > key when it is possible to simply do a real time check for > > authorization. There is no reason to sign a key when you can just > > check if the key is in a database. > > Each real-time check reveals your interest in the check. What about > privacy implications? Well, OCSP and such already do online checks in real time, so there is no difference there between my view of the world and what people claim should be done for certificates. The more interesting question is whether the crypto protocols people can come up with ways of doing online checks for information about keys that don't reveal information about what is being asked for. That would help in both the certificate and non-certificate versions of such checks. Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: About that "Mighty Fortress"... What's it look like?
On 18/08/10 3:46 AM, Peter Gutmann wrote: > Alexander Klimov writes: > >> Each real-time check reveals your interest in the check. What about privacy >> implications? > > (Have you ever seen a PKI or similar key-using design where anyone involved in > speccing or deploying it genuinely cares about privacy implications? Not only > have I never seen one, I've even been to a talk at a conference where someone > was criticised for wasting time on privacy concerns). (You may have opened your question too wide). Privacy against whom? There were enough details revealed about the key escrow LEAF in Clipper to see that the operation derived from over the air transfer of keys in Type I applications. The purpose was to keep a back door private for use of the government. The escrow mechanism an involution of PKI. There were of course concerns as evinced in the hearing under the 105th Congress on 'Privacy in the Digital Age: Encryption and Mandatory Access Hearings', before the Subcommittee on the Constitution, Federalism, and Property Rights, of the Committee on The Judiciary, United States Senate in March 1998. These concerns were on the rights of privacy for users. Clipper failed primarily because there wasn't enough trust that the privacy wouldn't be confined to escrow agents authorized by the Judiciary. The Federal government lost credibility through orchestrated actions by those with conscience concerned over personal privacy and potential government abuse. Privacy suffers from lack of legislation and is only taken serious when the threat is pervasive and the voters are up in arms. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: About that "Mighty Fortress"... What's it look like?
On 17/08/2010 16:53, Perry E. Metzger wrote: > On Tue, 17 Aug 2010 15:04:00 +0300 Alexander Klimov > wrote: >> On Sat, 31 Jul 2010, Perry E. Metzger wrote: >>> There is no rational reason at all that someone should "endorse" a >>> key when it is possible to simply do a real time check for >>> authorization. There is no reason to sign a key when you can just >>> check if the key is in a database. >> >> Each real-time check reveals your interest in the check. What about >> privacy implications? > > Well, OCSP and such already do online checks in real time, so there is > no difference there between my view of the world and what people claim > should be done for certificates. > > The more interesting question is whether the crypto protocols people > can come up with ways of doing online checks for information about > keys that don't reveal information about what is being asked for. That > would help in both the certificate and non-certificate versions of > such checks. Selective disclosure allows this kind of thing (e.g. "check that x is not on a blacklist without revealing x"). Not sure it's particularly efficient, though... -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
