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:25 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 A3111130FEA for <ietf@ietfa.amsl.com>; Thu, 10 Jan 2019 11:25:15 -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 jVvu6HpFLIUc for <ietf@ietfa.amsl.com>; Thu, 10 Jan 2019 11:25:14 -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 0CC8E130FBA for <ietf@ietf.org>; Thu, 10 Jan 2019 11:25:14 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A498B300AA6 for <ietf@ietf.org>; Thu, 10 Jan 2019 13:57:03 -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 m2FG6ufaM6FR for <ietf@ietf.org>; Thu, 10 Jan 2019 13:57:01 -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 8CDE2300064; Thu, 10 Jan 2019 13:57:01 -0500 (EST)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <8FA04872-6DBC-4180-B2FA-517249375B9C@vigilsec.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_682913E7-AD1E-40DC-98A0-3CB81831B550"; protocol="application/pgp-signature"; micalg="pgp-sha1"
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
Date: Thu, 10 Jan 2019 14:15:18 -0500
In-Reply-To: <8736q0fqy8.fsf@fifthhorseman.net>
Cc: Rich Salz <rsalz@akamai.com>, 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>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
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>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/hmSh4w60I5z7-jTUCWQ4_L5oZis>
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:25:16 -0000

DKG:

> On Jan 10, 2019, at 10:54 AM, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
> 
> On Thu 2019-01-10 12:56:27 +0000, Salz, Rich wrote:
>> [ dkg wrote: ]
>>>   What it introduces is the tight coupling of two previously-distinct
>>>    actions for the relying party:
>> 
>> I don't see it that way.  Nobody is forcing relying parties to couple
>> things.
> 
> Earlier in the thread, Russ 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.
> 
> Maybe this isn't *forcing* (in the sense that none of our RFCs can force
> anyone to do anything), but it indicates that relying parties that
> follow this specification will tightly couple these two actions, with
> potentially bad consequences.

Again, by following the new-in-old and old-in-new advice referenced in Section 5, the replacement will not change the validity of any end-entity certificates.  So, I think the "bad consequences" is an overstatement.

Russ

v2.23.0 | Report a Bug | By Email