[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:-)
- [Acme] case in point of usability Stephen Farrell
- Re: [Acme] case in point of usability Carl Mehner
- Re: [Acme] case in point of usability Stephen Farrell
- Re: [Acme] case in point of usability Rob Stradling
- Re: [Acme] case in point of usability Stephen Farrell
- Re: [Acme] case in point of usability Ben Laurie
- Re: [Acme] case in point of usability Stephen Farrell
- Re: [Acme] case in point of usability Warren Kumari
- Re: [Acme] case in point of usability Phillip Hallam-Baker
- Re: [Acme] case in point of usability Nico Williams