Subject: [Acme] case in point of usability

From: Stephen Farrell <[email-masked]>
Date: Tue, 31 Mar 2015 16:11:43 +0100

So today I was updating a web server cert as I do a few
times a year. And I have a usability story to tell...

I got the new cert and installed it in apache without any
Cullen-like problems:-) That cost me €0.00 in payment and
about 5-10 minutes. All good so far.

Chrome was happy, but FF/opera/my phone weren't.

I then messed about for 30 minutes checking to see if
a new intermediate cert was needed etc. (i.e. I was back
to Cullen-mode:-)

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.

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.

And one big reason CMP etc don't support that is that we
didn't have that requirement when we had the big fight
that lead to CRMF back nearly 20 years ago. (Since OCSP
didn't exist then and we didn't know how folks would be
updating web servers, and we're much more intolerant of
Cullen-like messing about being needed these days, and
rightly so.)

I would like acme defined so that when I get the cert
back all the PKI stuff has happened already and is
working. I'm sure some other semantics could also work
out, (e.g. if acme had a "ready-yet?" query I could
emit after getting the cert), but those are the kind
of problems we're currently facing that are killers and
that we can address, now that we know the deployment
requirements much better than we did in 1996.

I hope this helps those who are worried that acme is
only about business models. In my head what acme ought
be about is getting rid of that 1 hour of silly sysadmin
time I just spent - the system-automated web server s/w
update should just have done all of this for me without
me even having to know a new cert was needed until I
get the system update email tomorrow.

Cheers,
S.

PS: Apologies, Cullen but it's your own fault:-)

---

From: Carl Mehner <[email-masked]>
Date: Wed, 1 Apr 2015 00:16:31 -0500

> 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.

> 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