IETF Logo Mail Archive

Re: [keyassure] dane-04 trust anchors

Scott Schmit <i.grok@comcast.net> Sun, 20 February 2011 05:34 UTC

Return-Path: <i.grok@comcast.net>
X-Original-To: keyassure@core3.amsl.com
Delivered-To: keyassure@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA7D63A70A3 for <keyassure@core3.amsl.com>; Sat, 19 Feb 2011 21:34:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.997
X-Spam-Level:
X-Spam-Status: No, score=-101.997 tagged_above=-999 required=5 tests=[AWL=0.602, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCNriL97OV+t for <keyassure@core3.amsl.com>; Sat, 19 Feb 2011 21:34:34 -0800 (PST)
Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by core3.amsl.com (Postfix) with ESMTP id D66BC3A70A1 for <keyassure@ietf.org>; Sat, 19 Feb 2011 21:34:33 -0800 (PST)
Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta14.westchester.pa.mail.comcast.net with comcast id A5aq1g0020QuhwU5E5bCQz; Sun, 20 Feb 2011 05:35:12 +0000
Received: from olympia.mars.sol ([68.33.77.0]) by omta02.westchester.pa.mail.comcast.net with comcast id A5bC1g00H00PQ6U3N5bCji; Sun, 20 Feb 2011 05:35:12 +0000
Received: from olympia.mars.sol (localhost [127.0.0.1]) by olympia.mars.sol (8.14.4/8.14.3) with ESMTP id p1K5ZAPp012031 for <keyassure@ietf.org>; Sun, 20 Feb 2011 00:35:10 -0500
Received: (from draco@localhost) by olympia.mars.sol (8.14.4/8.14.4/Submit) id p1K5ZAaI012029 for keyassure@ietf.org; Sun, 20 Feb 2011 00:35:10 -0500
Date: Sun, 20 Feb 2011 00:35:10 -0500
From: Scott Schmit <i.grok@comcast.net>
To: keyassure@ietf.org
Message-ID: <20110220053510.GC7481@odin.mars.sol>
Mail-Followup-To: keyassure@ietf.org
References: <4D54E4A9.1020104@gmail.com> <alpine.LFD.1.10.1102131454150.32601@newtla.xelerance.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.LFD.1.10.1102131454150.32601@newtla.xelerance.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [keyassure] dane-04 trust anchors
X-BeenThere: keyassure@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/keyassure>
List-Post: <mailto:keyassure@ietf.org>
List-Help: <mailto:keyassure-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Feb 2011 05:34:36 -0000

On Sun, Feb 13, 2011 at 02:58:29PM -0500, Paul Wouters wrote:
> On Fri, 11 Feb 2011, Yaron Sheffer wrote:
> >The client MUST obey any constraints included in the trust anchor,
> >including but not limited to:
> >- Validity period.
> 
> What to do if that period does not match the DNS TTL/RRSIG period?

The DNS TTL should be used to determine when the client MUST forget the
certificate association and refetch the TLSA record if it needs it
again.  I think that's the DANE equivalent to revocation (if the TLSA
record is replaced, the old cert was revoked).

The RRSIG period serves a similar role to the Validity period in X.509,
though it'll be much shorter than we're used to for PKIX. I would think
that the most restrictive value wins. The notAfter field can always be
set to be never to avoid needing to regenerate the certificate.

You could probably argue that what I'm saying to use the TTL for is what
the RRSIG period is for, but in my experience with DNSSEC tools, it's a
lot more obvious to me how I'd control (without affecting the period for
other records) the rate a client rechecks the certificate validity via
the TTL.

-- 
Scott Schmit

v2.23.0 | Report a Bug | By Email