Re: [Acme] case in point of usability

Rob Stradling <rob.stradling@comodo.com> Wed, 01 April 2015 09:44 UTC

Return-Path: <rob.stradling@comodo.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 10AA31A0111 for <acme@ietfa.amsl.com>; Wed, 1 Apr 2015 02:44:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 bBSYOb1z9OgX for <acme@ietfa.amsl.com>; Wed, 1 Apr 2015 02:44:15 -0700 (PDT)
Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A7FF1A00B8 for <acme@ietf.org>; Wed, 1 Apr 2015 02:44:15 -0700 (PDT)
Received: (qmail 26094 invoked by uid 1004); 1 Apr 2015 09:44:14 -0000
Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Wed, 01 Apr 2015 10:44:14 +0100
Received: (qmail 32462 invoked by uid 1000); 1 Apr 2015 09:44:13 -0000
Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Wed, 01 Apr 2015 10:44:13 +0100
Message-ID: <551BBDED.8050908@comodo.com>
Date: Wed, 01 Apr 2015 10:44:13 +0100
From: Rob Stradling <rob.stradling@comodo.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Carl Mehner <c@cem.me>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
References: <551AB92F.6080004@cs.tcd.ie> <CAEa9xj7YUyQW5xzmXWC5Cj9undu3U+GEZqTgxnf5igBMF=39Sw@mail.gmail.com>
In-Reply-To: <CAEa9xj7YUyQW5xzmXWC5Cj9undu3U+GEZqTgxnf5igBMF=39Sw@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/ikSw80Rd6gmGGK8ydoUe9ClFYq8>
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 09:44:18 -0000

On 01/04/15 06:16, Carl Mehner wrote:
<snip>
> 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.

The CA's OCSP infrastructure might consist of many servers that are not 
necessarily perfectly synchronized.  So the ACME client may be able to 
obtain a "good" OCSP response for a recently issued certificate, but 
some other clients may get a different response.

Only the ACME server (the CA) could possibly know for certain that all 
of the servers in its OCSP infrastructure have become aware of the 
recently issued certificate.

Perhaps an ACME client should be able to ask an ACME server "Is your 
OCSP infrastructure fully aware of this cert yet?"

Or perhaps the ACME draft should simply say that TLS servers SHOULD 
enable OCSP Stapling, so that TLS clients are less likely to encounter a 
"requested too early" OCSP response.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online