Re: [Acme] case in point of usability

[Carl Mehner <[e-mail]>]

On Tue, Mar 31, 2015 at 10:11 AM, Stephen Farrell
<[e-mail]> wrote:
> Turns out after a bit of searching, I'd installed the new
> cert too soon, and when I tested it, a "dunno" OCSP
> response was sent before the responder had seen the new
> cert and that OCSP response has now been cached for some
> unknowable (to me) number of hours in who-knows-what
> places. And that caching behaviour has changed since the
> last time I got a cert from the same provider a few months
> ago. So I reverted my apache to the old cert and will
> try install the new cert again tomorrow.

This sounds predominantly like a CA problem of their databases not
syncing up soon enough mixed with a software problem of trying to
staple a 'dunno' ocsp response.

> That's exactly that kind of thing I'd love to see fixed
> with acme and that is not handled by CMP, CMC, PKCS#10,
> EST or SCEP. At least I don't believe there's a standard
> way of getting the right thing to happen with those
> without some proprietary extension/surroundings.

The software can fix this with some sanity checks upon cert install.
(I know IIS doesn't do this either and is happy to staple a revoked
response from the CA)

If we do want to put these type of considerations in the draft,
maybe the security considerations section is the best place.
Something along the lines of:

When preparing to use the new certificate received from a issuance or
refresh, the client software should check that the OCSP response from
the certificate authority is valid before enabling the new certificate
for use in the server system. If the OCSP response is requested too
early by the server system, a 'revoked' or 'unknown' OCSP response may
be cached and cause browsers to fail connection attempts.


-cem