Re: [Acme] case in point of usability

Carl Mehner <> Wed, 01 April 2015 05:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E9AE01A8884 for <>; Tue, 31 Mar 2015 22:16:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.169
X-Spam-Status: No, score=-1.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id n7UZv3y8vGDh for <>; Tue, 31 Mar 2015 22:16:34 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A0E0E1A8880 for <>; Tue, 31 Mar 2015 22:16:33 -0700 (PDT)
Received: by lbbzk7 with SMTP id zk7so11612331lbb.0 for <>; Tue, 31 Mar 2015 22:16:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=cem; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bVV5xxVmTGJgyHItX1paad7VgNuHfeIHTVF1zxJPTnM=; b=l+kYNdavqLF69jIh2zUL6O68WFWO/p1Ei27VgrZQ98dEIL7qBefxiXAsRdZpedtyzt gymfc2Oq5RDls0x4NCIzIrioSvIJopoVtE/tvkX54rY1tvCsXbMHjV72P6OuQIKY2RNg +jrvsBHANU54ILm+RFhu+CXlCa/KDLe/Oa0jg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bVV5xxVmTGJgyHItX1paad7VgNuHfeIHTVF1zxJPTnM=; b=X2cZ2xbefmBd7bAxZeAmrtWvWENsey3SAHij6dLoiG1YyFgdQqmBBcdjTjl/ZK4nZ6 C3Nd9aA2gFvmlMuee/HBQC3XLiyKT0sxnn+BcIMW+cJfi6/YkUW7hxygdVl51oj+I/WM HmBUVFSe5hnAFleNaxWRcEA1jqZetVsJmf/oqSjT41iZ6+VK/eTY4uJEf/nNz1a6hkOJ XTBI7X2x4/J7W1pGAsh/ab5XZMcw7S1B+SBUnxDaeETIeGajQoh1cus9qwW16oauOCpS KHBbnyaXxmABa5B9I18jOuVMwmJz7CbEafkFRsCer6KYhN4tVmtC1SC7UHykQ5eMx74b OPXA==
X-Gm-Message-State: ALoCoQlexbYC80Xp/EQG0VE+KZ5q1WDqEIS9iw1hp5iBeL5G8eTpLaVGTdtQqpMoTLcd+v1ku9jo
MIME-Version: 1.0
X-Received: by with SMTP id pf1mr34188945lbb.33.1427865392041; Tue, 31 Mar 2015 22:16:32 -0700 (PDT)
Received: by with HTTP; Tue, 31 Mar 2015 22:16:31 -0700 (PDT)
X-Originating-IP: [2602:306:8bf0:4130:b5b0:920b:6c8a:41c7]
In-Reply-To: <>
References: <>
Date: Wed, 1 Apr 2015 00:16:31 -0500
Message-ID: <>
From: Carl Mehner <>
To: Stephen Farrell <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "" <>
Subject: Re: [Acme] case in point of usability
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Automated Certificate Management Environment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Apr 2015 05:16:35 -0000

On Tue, Mar 31, 2015 at 10:11 AM, Stephen Farrell
<> 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.