Subject: RE: OCSP Responder Status

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 3 Dec 2008 06:59:46 -0800

The trusted responder model makes no sense to me unless you are delegating the complete trust decision to an external resource as in SCVP. Which is of course why some of us suggested SCVP be an OCSP extension.
 
If we were going to do anything more in this area (and I don't think we should), we should implement the only trusted responder delegation that makes any sense to me at all and that is where the trusted responder is responsible for verifying the key in its entirety.
 
If you are doing delegated trust with a PKI capable endpoint device the computational task of path math is a diminishing concer. The problem of management of the trusted certificate base and security policy is the bigger and increasing part of the problem.
 
So if we were to address this point I would suggest doing it through a profile on SCVP, and SCVP-Lite profile, in which the client provides no input into the request other than describing what it wants to DO. That means no talk of trust roots and paths and such. Just 'X wants to do Y with Z, give me the key and the algorithm context to use'

In other words, SCVP-Lite is XKMS but fixing the mistake we made by making XKMS specific to public key. 
 
If XKMS could deliver either a symmetric key OR a public key, then you can have a mode of communication where the XKMS server is also operating as a kerberos key server. 
 
Now that I am interested in devices that cannot support ethernet, cannot support IP and certainly cannot support public key (no not even ECC variants), I am starting to see interesting advantages you can achieve by using a blend of symmetric and public key techniques rather than the traditional approach of letting PKI do al the glamorous trusty stuff and then confining symmetric key to just a bunch of session key stuff.

________________________________

From: [email-masked] on behalf of Timothy J. Miller
Sent: Tue 11/25/2008 12:17 PM
To: Liaquat Khan
Cc: 'Johannes Merkle'; 'Mauricio Balassiano'; [email-masked]
Subject: Re: OCSP Responder Status

Liaquat Khan wrote:
> The problem with your option 3 is that RFC2560 doesn't explain how a client
> can check that the second responder is acting on behalf of the first CA.
> I.e. it may chain to a trust anchor, allowing you to verify the signature on
> the OCSP response, but how do you know that the original CA actually
> authorised this second responder to provide status information on the first
> responder's certificate?

That's what client configuration control is for.  :)  That's the whole
point of the trusted responder model--trust in that responder is
established out-of-band (i.e., not part of the OCSP protocol).

> If you are happy to live without this check then this can work, however I
> have not really seen this method actual used (probably because it introduces
> more complexity than the benefit it offers). 

The DoD OCSP service uses the trusted responder model.  It's a real PITA
to manage; you have to make sure all the RPs are properly configured.
Key changing under this model is even worse; the hoops we had to jump
through were seriously sick.

We're now migrating to the CA designated model.  The CA-issued OCSP
signing certs will be short-lived certs with longer-lived keys (IIRC, 30
day cert life with renewal allowed for some period of time).

-- Tim