A mighty fortress is our PKI, Part II

[Nicolas Williams]

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 majordomo at metzdowd.com