Re: [Acme] case in point of usability

Ben Laurie <benl@google.com> Wed, 01 April 2015 12:38 UTC

Return-Path: <benl@google.com>
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 F11A61A8AC9 for <acme@ietfa.amsl.com>; Wed, 1 Apr 2015 05:38:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.389
X-Spam-Level:
X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 NJpvp1v_OoSc for <acme@ietfa.amsl.com>; Wed, 1 Apr 2015 05:38:30 -0700 (PDT)
Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B6111A88D0 for <acme@ietf.org>; Wed, 1 Apr 2015 05:38:30 -0700 (PDT)
Received: by qcay5 with SMTP id y5so39144753qca.1 for <acme@ietf.org>; Wed, 01 Apr 2015 05:38:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=RLvmKpRio9ZClTXLPm13B25+a8w8IHhQxotkihVFJck=; b=TRoaZSNjDklmwDm/95fBaBXFhyWKay2zk7IIFvVVcw1M16gwQscFd+bHcQuaaJhOBn lBfbbbcc6jCo5EEd6BUzE92cJHzz5u13A4UJICbWuB21FLWqOcfqghC/gQuMN+iMJQP1 dFoaHOOTETQcVeVxviX1tbrkoR8VMb4cBklZ8nf292Gj0G8WzeLpRugW73nCiggMVgqj pV8FPDQooLF62G/f8yzN8dp2IDZMTGyNlFoPsRw7zDkwKA1TcT9omRFs+3SWEbw8NlHX l0uIuKVgKtj/eT45NdTI+LHr40i1NlXlo0LCNPjj5LyK9StQOCSe/gP1zTKzMgqgJBkQ pKXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RLvmKpRio9ZClTXLPm13B25+a8w8IHhQxotkihVFJck=; b=B9YzrIWvumtzhxIRgVsr2lvdVq51CrwgQuxn9HMI9sNezzvWsSME6jBsD7V/ZjLSul GbUGkrwvBvQPDUrsN57NVUD8UDbb7W+urZKr6kA65GpU8SkuO19WRV2mXZTRdCeDT+C9 +7UV0EP3fI41TkHJjxaQ4K/9J2E1nbsuKvFqSo27ZNY65guOmjyTW7K3v+JQSgtgTSWM CT4o3zMtfpiMpC4Tn5aofJy4xNGPhRfMEO9aq109gTW5ZE09FHA1qyJIac84mQimwlwb qV+5aj4gj5gQYup9u4gzBQSsi8XJ8nNi7AoaRkfq0ehDvRL2ejZZKYoM5nIEXLUxkyQ9 Z4Iw==
X-Gm-Message-State: ALoCoQmftv3AN/a47TmXYGgYz8sHT95Fv+u06c4c1xFJKyeq3krWestgjN9d3d6Am2AGB1c9s29w
MIME-Version: 1.0
X-Received: by 10.140.217.16 with SMTP id n16mr14597597qhb.82.1427891909545; Wed, 01 Apr 2015 05:38:29 -0700 (PDT)
Received: by 10.229.178.135 with HTTP; Wed, 1 Apr 2015 05:38:29 -0700 (PDT)
In-Reply-To: <551BE246.1040603@cs.tcd.ie>
References: <551AB92F.6080004@cs.tcd.ie> <551BE246.1040603@cs.tcd.ie>
Date: Wed, 1 Apr 2015 13:38:29 +0100
Message-ID: <CABrd9SSnVD16USto=wP0EuXma+QcO2cH8AAbGZUymc1VhpC8hQ@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/Ja0dtZqMWbQWOw7p7ikHgRVFrzE>
Cc: "acme@ietf.org" <acme@ietf.org>
Subject: Re: [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: Wed, 01 Apr 2015 12:38:32 -0000

On 1 April 2015 at 13:19, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>
> And in a happy ending for this thread, when I whacked in
> the new cert today it all worked.
>
> Interestingly, there was a point where it was fine in all
> but one browser - that lasted an hour or so before they
> were all ok, not quite sure why, but there's clearly more
> going on with ocsp caching than I know about;-)

Are you sure it wasn't the intermediate problem you were originally
investigating?

>
> S.
>
>
> On 31/03/15 16:11, Stephen Farrell wrote:
>>
>> 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 mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme