On Wed, Jul 28, 2010 at 03:16:32PM +0100, Ben Laurie wrote: > Maybe it doesn't, but no revocation mechanism at all makes me nervous. > > I don't know Kerberos well enough to comment. > > DNSSEC doesn't have revocation but replaces it with very short > signature lifetimes (i.e. you don't revoke, you time out).
Kerberos too lacks revocation, and it also makes up for it with short ticket lifetimes. 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. To revoke an individual certificate you need only mark a date for the given subject such that no cert issued prior to it will be considered valid. An OCSP Responder implementation could be based on checking a real CRL or checking a database of known subjects (principals). Whichever is likely to be smaller over time is best, though the latter is just simpler to administer (since you don't need to know the subject public key nor the issuer&serial, nor the actual TBSCertificate in order to revoke, just the subject name and current date and time). > 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). Nico -- --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com