IETF Logo Mail Archive

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

Nico Williams <nico@cryptonector.com> Mon, 28 April 2014 17:33 UTC

Return-Path: <nico@cryptonector.com>
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 AB2311A6FE5 for <tls@ietfa.amsl.com>; Mon, 28 Apr 2014 10:33:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Level:
X-Spam-Status: No, score=-1.044 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, IP_NOT_FRIENDLY=0.334] 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 9zQ2EZcIrpd1 for <tls@ietfa.amsl.com>; Mon, 28 Apr 2014 10:33:47 -0700 (PDT)
Received: from homiemail-a25.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id EE5F11A6F39 for <tls@ietf.org>; Mon, 28 Apr 2014 10:33:46 -0700 (PDT)
Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 99943678063 for <tls@ietf.org>; Mon, 28 Apr 2014 10:33:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=sDw2G1RMldZg8TMewK/n LMaRSP8=; b=IYX1UVPvcnWf4pd/AqoCkm0tWCt424pR6wA/PMvMafEATW6MZA2A noPadBDXd06dCZd2F4diDEWVtDYEerYUh8vC3t/l2v8xxz8Ee0v80yw4oqUTLPH+ MoskQqMFJqzPa2W8h7JEvz9WDlIKbbqNgV0kJIhlXeac1L2r3pPv8b4=
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 4E75B678062 for <tls@ietf.org>; Mon, 28 Apr 2014 10:33:45 -0700 (PDT)
Received: by mail-wi0-f172.google.com with SMTP id hi2so6122299wib.5 for <tls@ietf.org>; Mon, 28 Apr 2014 10:33:43 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.181.5.6 with SMTP id ci6mr16435662wid.39.1398706423691; Mon, 28 Apr 2014 10:33:43 -0700 (PDT)
Received: by 10.216.29.200 with HTTP; Mon, 28 Apr 2014 10:33:43 -0700 (PDT)
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F5D0@USMBX1.msg.corp.akamai.com>
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> <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F5D0@USMBX1.msg.corp.akamai.com>
Date: Mon, 28 Apr 2014 12:33:43 -0500
Message-ID: <CAK3OfOiasBfVqgQTp+mGDzfKvnY-k+gavbe5HwpYiOdEciGvJg@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: "Salz, Rich" <rsalz@akamai.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9fw_p-nm4Vbo0bXuJ-Ss2SDM0So
Cc: "tls@ietf.org" <tls@ietf.org>
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 17:33:47 -0000

On Mon, Apr 28, 2014 at 9:57 AM, Salz, Rich <rsalz@akamai.com> wrote:
> Those are all really good questions, but seem to me that they're a matter of local trust policy and not policy that should be nailed down in an RFC.  Do you disagree?

IMO:

 - freshness requirements are indeed ultimately a local policy issue

 - but a server-side freshness commitment is something that can be
pinned to, therefore adding value when local freshness policy is
loose.

The freshness commitment might come from the OCSP responder, but it's
optional.  And the text of the RFC makes it seem very likely that
nextUpdate is all about OCSP responders that poll CRLs, and that OCSP
responders that have direct access to the revocation Truth might well
never include nextUpdate.

The freshness commitment might come from the TLS server -- where?

This might be an item for TACK.

Nico
--

v2.23.0 | Report a Bug | By Email