[Acme] case in point of usability

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 31 March 2015 15:11 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C661ACDF3 for <acme@ietfa.amsl.com>; Tue, 31 Mar 2015 08:11:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.311
X-Spam-Level:
X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmmjrcH4RR8c for <acme@ietfa.amsl.com>; Tue, 31 Mar 2015 08:11:49 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8F491ACE01 for <acme@ietf.org>; Tue, 31 Mar 2015 08:11:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CD119BEBB for <acme@ietf.org>; Tue, 31 Mar 2015 16:11:47 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouJS0Ui-CJbQ for <acme@ietf.org>; Tue, 31 Mar 2015 16:11:46 +0100 (IST)
Received: from [10.87.48.73] (unknown [86.46.29.244]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3308CBE8A for <acme@ietf.org>; Tue, 31 Mar 2015 16:11:46 +0100 (IST)
Message-ID: <551AB92F.6080004@cs.tcd.ie>
Date: Tue, 31 Mar 2015 16:11:43 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: "acme@ietf.org" <acme@ietf.org>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/m1dHbbE8GmtfYNOn78RKXwfcD7I>
Subject: [Acme] case in point of usability
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Mar 2015 15:11:52 -0000

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:-)