A mighty fortress is our PKI, Part II

[Nicolas Williams]

On Wed, Jul 28, 2010 at 11:38:28AM -0400, Perry E. Metzger wrote:
> On Wed, 28 Jul 2010 09:57:21 -0500 Nicolas Williams
> <Nicolas.Williams at 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.

No, they really are semantically equivalent.  In Kerberos (traditional,
pre-PKINIT Kerberos) the long-term credential is {principal name,
long-term secret key} or {principal name, password}, and the temporary
credential is the Kerberos Ticket.  In PKI+OCSP the long-term credential
is {certificate, private key}, and the temporary credentials is
{certificate, private key, fresh OCSP Response}.

Both, Kerberos and PKI+OCSP replace a long-term credential with a
short-lived, temporary credential authenticating the same principal.

> OCSP is hung on to the side of X.509 as an afterthought, so it cannot
> [...]

Yes, but it's still "morally equivalent" to Kerberos as described above,
but with PK instead of KDCs and shared secret keys.

Also, PKI+OCSP is somewhat less dependent on online infrastructure than
Kerberos because: a) just one OCSP Response will do[*], vs. a multitude
of service Tickets, b) OCSP Responders don't need access to the CA's
private key, whereas the KDCs do need access to the TGS keys.  Also,
OCSP Responses can be cached by the network, whereas Kerberos Tickets
cannot be (since they are useless[**] without the corresponding session
key).

[*]  It helps to have protocols where subjects can send OCSP responses
     for their own certs to their peers.  It also helps to have
     protocols where client subjects can get OCSP Responses for their
     own certs from their peers and then re-use those Responses later.

[**] I'm ignoring user-to-user authentication here.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com