-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/31/2010 12:32 PM, Perry E. Metzger wrote: > 1 If you can do an online check for the validity of a key, there is > no need for a long-lived signed certificate, since you could > simply ask a database in real time whether the holder of the key > is authorized to perform some action. The signed certificate is > completely superfluous. > > If you can't do an online check, you have no practical form of > revocation, so a long-lived signed certificate is unacceptable > anyway.
In general I agree with you, in particular when the task at hand is authenticating individuals (or more to the point, Joe Sixpack). However the use case of certificates for websites has worked out pretty well (from a purely practical standpoint). The site owner has to protect their key, because as you say, revocation is pretty much non-existent. > 2 A third party attestation, e.g. any certificate issued by any > modern CA, is worth exactly as much as the maximum liability of > the third party for mistakes. If the third party has no liability > for mistakes, the certification is worth exactly nothing. All > commercial CAs disclaim all liability. > > An organization needs to authenticate and authorize its own users; > it cannot ask some other organization with no actual liability to > perform this function on its behalf. A bank has to know its own > customers, the customers have to know their own bank. A company > needs to know on its own that someone is allowed to reboot a > machine or access a database. This is one of the issues driving "Federated Authentication." The idea being that each organization authenticates its own users (however it deems appropriate) and the federation technology permits this authentication to be used transitively. I view federation as still in its infancy, so there are plenty of growing pains ahead of us. As an aside... a number of years ago I was speaking with the security folks at a large financial organization which does business with MIT. Their authentication approach was pretty lame. I asked them if they could instead accept MIT client certificates. They had a simple question for me. They asked me if MIT would make good if a transaction went bad and the "badness" could be attributed to us mis-authenticating someone. I said "No". They said, well, our authentication may be lame, but we stand behind it. If someone loses money as a result, we will make them whole. And there you have it. > 3 Any security system that demands that users be "educated", > i.e. which requires that users make complicated security decisions > during the course of routine work, is doomed to fail. > > For example, any system which requires that users actively make > sure throughout a transaction that they are giving their > credentials to the correct counterparty and not to a thief who > could reuse them cannot be relied on. > > A perfect system is one in which no user can perform an action > that gives away their own credentials, and in which no user can > authorizes an action without their participation and knowledge. No > system can be perfect, but that is the ideal to be sought after. Completely agree. One of the appeals of public key credentials, notice that I didn't say "certificate" here, is that you can prove your identity without permitting the relying party to turn around and use your credentials. I call this class of system "non-disclosing" because you do not disclose sufficient information to permit the relying party to impersonate you. Passwords are "disclosing"! We do not require drivers of automobiles to be auto mechanics. We shouldn't require internet users to be security technologists. > 4 As a partial corollary to 3, but which requires saying on its own: > If "false alarms" are routine, all alarms, including real ones, > will be ignored. Any security system that produces warnings that > need to be routinely ignored during the course of everyday work, > and which can then be ignored by simple user action, has trained > its users to be victims. > > For example, the failure of a cryptographic authentication check > should be rare, and should nearly always actually mean that > something bad has happened, like an attempt to compromise > security, and should never, ever, ever result in a user being told > "oh, ignore that warning", and should not even provide a simple UI > that permits the warning to be ignored should someone advise the > user to do so. > > If a system produces too many false alarms to permit routine work > to happen without an "ignore warning" button, the system is > worthless anyway. I learned about this from a story when I was a kid. I believe it was called "The Boy who Cried Wolf." > 5 Also related to 3, but important in its own right: to quote Ian > Grigg: > > *** There should be one mode, and it should be secure. *** > > There must not be a confusing combination of secure and insecure > modes, requiring the user to actively pay attention to whether the > system is secure, and to make constant active configuration > choices to enforce security. There should be only one, secure > mode. > > The more knobs a system has, the less secure it is. It is trivial > to design a system sufficiently complicated that even experts, let > alone naive users, cannot figure out what the configuration > means. The best systems should have virtually no knobs at all. > > In the real world, bugs will be discovered in protocols, hash > functions and crypto algorithms will be broken, etc., and it will > be necessary to design protocols so that, subject to avoiding > downgrade attacks, newer and more secure modes can and will be > used as they are deployed to fix such problems. Even then, > however, the user should not have to make a decision to use the > newer more secure mode, it should simply happen. Yep. -Jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFMVMG18CBzV/QUlSsRAjB/AKDlTsLgnEa0A9ahKiGtFBCBIQncowCg3/pI WXegkQraFeSAmv9BiOgKZhE= =4mAS -----END PGP SIGNATURE----- --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com