IETF Logo Mail Archive

Re: [lamps] Last Call: <draft-ietf-lamps-hash-of-root-key-cert-extn-02.txt> (Hash Of Root Key Certificate Extension) to Informational RFC

Russ Housley <housley@vigilsec.com> Thu, 10 January 2019 19:42 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6C0131239 for <ietf@ietfa.amsl.com>; Thu, 10 Jan 2019 11:42:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=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 yNhQADZQifSI for <ietf@ietfa.amsl.com>; Thu, 10 Jan 2019 11:42:22 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00C82131238 for <ietf@ietf.org>; Thu, 10 Jan 2019 11:42:22 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5100A300AA2 for <ietf@ietf.org>; Thu, 10 Jan 2019 14:24:04 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Do1UOC9UIMSf for <ietf@ietf.org>; Thu, 10 Jan 2019 14:24:02 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id 8CEB330017E; Thu, 10 Jan 2019 14:24:02 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Subject: Re: [lamps] Last Call: <draft-ietf-lamps-hash-of-root-key-cert-extn-02.txt> (Hash Of Root Key Certificate Extension) to Informational RFC
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <771552B4-E30D-4B97-B010-32690A86285F@akamai.com>
Date: Thu, 10 Jan 2019 14:42:19 -0500
Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, LAMPS WG <spasm@ietf.org>, "draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org" <draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org>, IETF <ietf@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <23D681CF-BE8C-43DF-892F-A4E99196D90B@vigilsec.com>
References: <154594881588.11855.12133790922363153381.idtracker@ietfa.amsl.com> <1AB99D11-5B25-4A97-9FFD-17E318ADD739@vpnc.org> <87va35o7pe.fsf@fifthhorseman.net> <38891959-38F6-4FA5-B7B1-ACB50921E300@vigilsec.com> <87k1jlnxnu.fsf@fifthhorseman.net> <2AB77CF4-ADD6-4EE6-ABB2-BCDAC4BF6631@vigilsec.com> <87imyxh8fy.fsf@fifthhorseman.net> <175B8CA7-17E8-48EC-BEFA-9E5D4B685B48@akamai.com> <87y37tf71a.fsf@fifthhorseman.net> <B7E3EAEB-90EE-46D7-9481-ED1234A7424A@akamai.com> <8736q0fqy8.fsf@fifthhorseman.net> <771552B4-E30D-4B97-B010-32690A86285F@akamai.com>
To: Rich Salz <rsalz@akamai.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/YI91a2RYFRrL2KFipwnvLFafb0Q>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Jan 2019 19:42:24 -0000


> On Jan 10, 2019, at 2:15 PM, Salz, Rich <rsalz@akamai.com> wrote:
> 
>> If both checks succeed, then the potential Root CA certificate is
>> added to the trust anchor store and the current Root CA certificate is
>> removed.
> 
> I suggest adding "after an appropriate amount of time (such as no old certificate chains being in use)."
> 
> Does that solve the issue?

There are two cases.  In one case, there is an enterprise directory system, and there is no concern with the discovery of the old-in-new and the new-in-old certificates. The old certificate can be removed without any concerns in this situation.  In the second case, there is no appropriate directory, and keeping the old certificate for some amount of time would prevent the issue raised by DKG.

Russ

v2.23.0 | Report a Bug | By Email