IETF Logo Mail Archive

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

Nico Williams <nico@cryptonector.com> Mon, 28 April 2014 19:40 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 D5DD41A6F9E for <tls@ietfa.amsl.com>; Mon, 28 Apr 2014 12:40:27 -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 J5uxRqVd9ajw for <tls@ietfa.amsl.com>; Mon, 28 Apr 2014 12:40:27 -0700 (PDT)
Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 57E991A6F42 for <tls@ietf.org>; Mon, 28 Apr 2014 12:40:27 -0700 (PDT)
Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id B1136202038 for <tls@ietf.org>; Mon, 28 Apr 2014 12:40:26 -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=AO44zSNYQxogNocPOEzk g0CwebE=; b=ZbXsgczrVpQFU0tnc2OiGBlGePdJcTGXI8znSaOWWepBonor14Jk V3/4Ghizs9Fv//jxvK/tugxig2hfSzcvLVsucjaaWSxeXN/HE2aOAlxcbjp6qiK+ XC4nB6jFYEOe01vzhjcUGAmVeqeKPThxo5/aJbkX8h9S4eESefWgApA=
Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 5434D202022 for <tls@ietf.org>; Mon, 28 Apr 2014 12:40:26 -0700 (PDT)
Received: by mail-wi0-f180.google.com with SMTP id hi2so128168wib.7 for <tls@ietf.org>; Mon, 28 Apr 2014 12:40:24 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.109.227 with SMTP id hv3mr21128840wjb.10.1398714024920; Mon, 28 Apr 2014 12:40:24 -0700 (PDT)
Received: by 10.216.29.200 with HTTP; Mon, 28 Apr 2014 12:40:24 -0700 (PDT)
In-Reply-To: <20140428174240.E04D21ACE1@ld9781.wdf.sap.corp>
References: <20140428162459.GZ27883@mournblade.imrryr.org> <20140428174240.E04D21ACE1@ld9781.wdf.sap.corp>
Date: Mon, 28 Apr 2014 14:40:24 -0500
Message-ID: <CAK3OfOjCCnty0rA_QTYF5VHMZ4NPkKe-DviZHSKDPcoVkx3eXg@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: "mrex@sap.com" <mrex@sap.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sEaxmnrTOsJ5NKDg9XC_WSmtZ5U
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 19:40:28 -0000

On Mon, Apr 28, 2014 at 12:42 PM, Martin Rex <mrex@sap.com> wrote:
> It is difficult to define a global/universal guaranteed service
> quality for the OCSP responder service of the CA, and it is
> difficult to define a minimum service quality for the server,
> in which time an admin will notice and fix a problem with the
> OCSP response refreshing of his server.

The server basically needs a "cron" job to fetch fresh OCSP responses
regularly.  A sufficiently long failure to get fresh responses should
trigger alerts to get admin attention.

Let's say the server's admins commit to 24 hour freshness (no response
will be older than 24hrs), with a cron job / daemon fetching new
responses every 8 hours.  A first failure to get a response might not
elicit any alerts, but a second should.  (A first failure might lead
to retrying sooner than the otherwise next-scheduled attempt in 8
hours.)

Nico
--

v2.23.0 | Report a Bug | By Email