Re: [TLS] Status of X.509v3 TLS Feature Extension?

Geoffrey Keating <geoffk@geoffk.org> Mon, 28 April 2014 19:26 UTC

Return-Path: <geoffk@geoffk.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E861A6FED for <tls@ietfa.amsl.com>; Mon, 28 Apr 2014 12:26:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 RL1scpyxFstg for <tls@ietfa.amsl.com>; Mon, 28 Apr 2014 12:26:39 -0700 (PDT)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1561D1A6FEC for <tls@ietf.org>; Mon, 28 Apr 2014 12:26:39 -0700 (PDT)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 71B9D33CF8A; Mon, 28 Apr 2014 19:26:38 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: tls@ietf.org
References: <CA+aixj_i8XF2buDNMOp2=_Z0XzT3R4uGfxJtjoGt-_PButSggw@mail.gmail.com> <CA+cU71=FtZfzGktLhLz_j99mQ=LVbd0kzz0ZyGbewQUS0ouEGA@mail.gmail.com> <535E353A.9030008@comodo.com> <20140428142029.GT27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F59F@USMBX1.msg.corp.akamai.com> <20140428145250.GU27883@mournblade.imrryr.org>
From: Geoffrey Keating <geoffk@geoffk.org>
Date: Mon, 28 Apr 2014 12:26:38 -0700
In-Reply-To: <20140428145250.GU27883@mournblade.imrryr.org>
Message-ID: <m2wqe9w901.fsf@localhost.localdomain>
Lines: 28
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FMoGkn5H_RveQX3xwQRoLZBeoOk
Subject: Re: [TLS] Status of X.509v3 TLS Feature Extension?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Apr 2014 19:26:42 -0000

Viktor Dukhovni <viktor1dane@dukhovni.org> writes:

> On Mon, Apr 28, 2014 at 10:32:10AM -0400, Salz, Rich wrote:
> 
> > > OCSP stapling gives no indication of when a verifier is to
> > > consider a particular status response to be stale.
> > 
> > Not sure what you mean; thisUpdate, nextUpdate, producedAt aren't sufficient?
> 
> Well, "nextUpdate" is optional per RFC 6960, and even when present
> it is not clear that the frequency of server updates of stapled
> OCSP responses is expected to provide responses whose nextUpdate
> is always in the future.

My understanding is that 'nextUpdate' is essentially the expiry date
for the OCSP response, and that if it's not present, it's considered
to expire immediately (so should never appear in a stapled response?
or have some indeterminate client-determined expiry time that the
server doesn't know about?  or have the nonce matching the one that
the client probably didn't bother to send in the request_extensions
field?  If only there was a RFC that documented how this should
work...).

It is perhaps an unfortunately named field; the naming is based on the
history of OCSP, which was apparently designed to be (basically) CRL
lookup service, so an OCSP responder would just consult its local copy
of the CRL; nextUpdate was when the responder would next fetch a
new copy of the CRL and thisUpdate was the last time it did so.