On Wed, 28 Jul 2010 09:57:21 -0500 Nicolas Williams <nicolas.willi...@oracle.com> wrote: > OCSP Responses are much like a PKI equivalent of Kerberos tickets. > All you need to do to revoke a principal with OCSP is to remove it > from the Responder's database or mark it revoked.
Actually, that's untrue in one very important respect. In a Kerberos style system, you actively ask for credentials to do things at frequent intervals, and if the KDCs refuse to talk to you, you get no credentials. In OCSP, we've inverted that. You have the credentials, for years in most cases, and someone else has to actively check that they're okay -- and in most instances, if they fail to get through to an OCSP server, they will simply accept the credentials. OCSP is hung on to the side of X.509 as an afterthought, so it cannot be enforced as part of the system. In Kerberos, the online aspect is burned into the protocol and cannot be avoided. There is no such thing as a Kerberos installation that chooses not to use KDCs. > > SSH does appear to have got away without revocation, though the > > nature of the system is s.t. if I really wanted to revoke I could > > almost always contact the users and tell them in person. This > > doesn't scale very well to SSL-style systems. > > The SSH ad-hoc pubkey model is a public key pre-sharing (for user > keys) and pre-sharing and/or leap-of-faith (for host keys) model. > It doesn't scale without infrastructure. Add infrastructure and > you're back to a PKI-like model (maybe with no hierarchy, but > still). There are two parts to the SSH model that should be segregated in discussions. One part is the "I've seen this one before" key validation model. I think there is merit in parts of that for many sorts of systems (say, secure email), and it is also worth discussing, but there is a second thing here which is usually ignored that I would prefer to concentrate on for now. The other part, which is very important, is the "we authorize keys by storing them in a database, we de-authorize them by removing them" model. This is typically used by Kerberized apps as well, though Kerberos doesn't generally impose a particular authorization model. Now, to some people, the "the key is in the database" model might seem trivial, or obvious, or otherwise insignificant. I think that's a mistake -- it is a critical part of what makes SSH work so well. The system is not relying on an old signature on a data structure around the key to say that the key is authorized. The system relies on something much simpler: keeping an up to date database of what keys are allowed. We can change that database at will, in real time. In this model, some external protocol might or might not be available to automate maintenance of that database, and the database might or might not be local to the host, but that part is conceptually entirely separate. The important part is that we are not relying on cryptography to handle the authorization -- we are not going to let someone in because a third party signed something last year. Cryptography handles only proving that someone holds a particular private key -- it isn't even handling authentication of a party per se. We decide to give privileges to the holder of that private key because a database check performed right now showed the particular key was in the database as authorized. I believe this way of doing things deserves much closer scrutiny. It is far simpler. It is far easier to understand the security properties of such a system. There are far fewer systems whose compromise will compromise the authorization decision. These are under-appreciated features. Perry -- Perry E. Metzger pe...@piermont.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com