Re: [therightkey] [pkix] Proposal for working on PKIX revocationopen issues

Rob Stradling <rob.stradling@comodo.com> Mon, 17 November 2014 21:52 UTC

Return-Path: <rob.stradling@comodo.com>
X-Original-To: therightkey@ietfa.amsl.com
Delivered-To: therightkey@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F541ACD1F for <therightkey@ietfa.amsl.com>; Mon, 17 Nov 2014 13:52:04 -0800 (PST)
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 VMnTyl_Tf2sy for <therightkey@ietfa.amsl.com>; Mon, 17 Nov 2014 13:52:00 -0800 (PST)
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 5DC0E1ACD14 for <therightkey@ietf.org>; Mon, 17 Nov 2014 13:52:00 -0800 (PST)
Received: (qmail 18588 invoked by uid 1004); 17 Nov 2014 21:51:58 -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; Lu, 17 nov 2014 21:51:58 +0000
Received: (qmail 29795 invoked by uid 1000); 17 Nov 2014 21:51:58 -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; Mon, 17 Nov 2014 21:51:58 +0000
Message-ID: <546A6DFD.1020306@comodo.com>
Date: Mon, 17 Nov 2014 21:51:57 +0000
From: Rob Stradling <rob.stradling@comodo.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Nico Williams <nico@cryptonector.com>, Phillip Hallam-Baker <phill@hallambaker.com>, Ben Laurie <benl@google.com>
References: <5466AF87.2050307@gmail.com><CAMm+Lwg30tb+yFxVMG3qJ=_fjVT=ASqUmaf9gH8wpUhUGxgf6A@mail.gmail.com> <CAK3OfOionKNtMRv+bFqY=yN1x+VQNwzraOBF-NSsdnSu6dOA5w@mail.gmail.com>
In-Reply-To: <CAK3OfOionKNtMRv+bFqY=yN1x+VQNwzraOBF-NSsdnSu6dOA5w@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/therightkey/NAH4OeIFGgk2D3zusG5YuZUsnq4
Cc: "therightkey@ietf.org" <therightkey@ietf.org>
Subject: Re: [therightkey] [pkix] Proposal for working on PKIX revocationopen issues
X-BeenThere: therightkey@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <therightkey.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/therightkey>, <mailto:therightkey-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/therightkey/>
List-Post: <mailto:therightkey@ietf.org>
List-Help: <mailto:therightkey-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/therightkey>, <mailto:therightkey-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Nov 2014 21:52:04 -0000

On 17/11/14 17:47, Nico Williams wrote:
> On Sat, Nov 15, 2014 at 3:56 PM, Phillip Hallam-Baker wrote:
<snip>
>> I have a different set of proposals:
>>
>> 1) Stapled OCSP with MUST-STAPLE OID
>> 2) Short lived Certificates
>>    2a) With the same key
>>    2b) With different keys
>> 3) CRLs with HBS compression.
>
> +1

On 17/11/14 15:52, Ben Laurie wrote:
<snip>
> FWIW, we (Google) are interested in doing the same thing for revocation
> that CT does for certs - i.e. providing a verifiable log/map of
> revocation status.

I'm interested in making revocation checking for the WebPKI actually 
work when it needs to work!  And that means finding a way for browsers 
to be able to hard-fail when revocation status is unobtainable.

TBH, I'm growing weary of OCSP Stapling.  It's still going to be years 
before there's any chance of it being deployed ubiquitously.  And I've 
seen some resistance to having OCSP Stapling enabled by default on the 
server-side.
Must-Staple is selective hard-fail.  It doesn't stop a compromised CA 
from misissuing a cert without Must-Staple for www.domain.com. 
Ultimately, we need browsers to always hard-fail, at which point 
Must-Staple would become redundant.

Short-lived certs are awkward until servers can somehow automate the 
process of requesting and installing new certificates.  And it's a 
problem that browsers don't treat certificate expiration as harshly as 
they treat certificate revocation.

The direction the browsers have been heading in (first Chrome with 
CRLSets, and now Firefox with OneCRL) is for the browser provider to 
construct a curated "global CRL" and push this to users via the 
browser's regular update mechanism.  The biggest problem I've seen with 
these "global CRL" solutions is that they don't cover the majority of 
certs...
...which is why I'm excited about CRLs with HBS compression.  :-)

I'm also excited about Ben's Revocation Transparency proposal.  This 
would be perfect as a trusted source for generating _truly_ "global 
CRLs" with HBS compression.  :-)

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