Re: [lamps] WG Last call: draft-ietf-lamps-hash-of-root-key-cert-extn

Russ Housley <housley@vigilsec.com> Tue, 06 November 2018 11:07 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1D8130DC3 for <spasm@ietfa.amsl.com>; Tue, 6 Nov 2018 03:07:33 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 t8Xhw5vrx3Jw for <spasm@ietfa.amsl.com>; Tue, 6 Nov 2018 03:07:31 -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 9BE73130DCE for <spasm@ietf.org>; Tue, 6 Nov 2018 03:07:30 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2B84A300AA6 for <spasm@ietf.org>; Tue, 6 Nov 2018 06:07:28 -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 vLIs9Og4XRG8 for <spasm@ietf.org>; Tue, 6 Nov 2018 06:07:26 -0500 (EST)
Received: from dhcp-9bbe.meeting.ietf.org (dhcp-9bbe.meeting.ietf.org [31.133.155.190]) by mail.smeinc.net (Postfix) with ESMTPSA id BDDC4300435; Tue, 6 Nov 2018 06:07:25 -0500 (EST)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <E77C61DD-E953-438A-A020-319F74C656BD@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_5A47D980-724C-49FD-B536-E35135998C29"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Tue, 6 Nov 2018 06:06:33 -0500
In-Reply-To: <019601d475b9$578c9ea0$06a5dbe0$@augustcellars.com>
Cc: SPASM <spasm@ietf.org>
To: Jim Schaad <ietf@augustcellars.com>
References: <BN6PR14MB1106CF89BEC31A9D837A3A5383F30@BN6PR14MB1106.namprd14.prod.outlook.com> <014401d47581$5fe919d0$1fbb4d70$@augustcellars.com> <7104A92B-DC98-4E58-A50A-D470E8E4A0B9@vigilsec.com> <016001d4758c$67daa2c0$378fe840$@augustcellars.com> <0871B813-F7BE-470D-AE97-6F5B62CDA7C3@vigilsec.com> <019601d475b9$578c9ea0$06a5dbe0$@augustcellars.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/_XMwXyQHGwoU8uoo7J_rBuBpaUo>
Subject: Re: [lamps] WG Last call: draft-ietf-lamps-hash-of-root-key-cert-extn
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2018 11:07:33 -0000

Jim:
> 
>>>>> * Section 2 - What operational considerations are there for when to
>>>>> retire the old Root CA certificate when a new one has been
>>>>> discovered and is to be used?
>>>> 
>>>> I'm not sure what you are requesting.  Install the new one, and
>>>> remove the old one?
>>> 
>>> When you install the new one, I don't believe that you are going to
>>> remove the old one.  There are still going to be valid certificates
>>> running around that will chain to the old root until you have done all
>>> of the issuing of certificates to the new root.  This is going to take
>>> time.  Additionally, if you are looking at something like the mail
>>> case you want to keep the old root but mark it as being "expired" so
>>> that you can validate the chain of certificates.
>> 
>> If one follows the old-with-new and new-with-old advice in RFC 2510, then
>> the replacement should not cause any disruption.  If you think it is useful, an
>> operational consideration about this can be added.
>> 
>>> This means that it might be some time before the old one is removed.
>> 
>> It should not need to linger...
> 
> Since it was not obvious to me, then yes the hint should be included.

Does this text address your concern:

5.  Operational Considerations

   Guidance on the transition from one trust anchor to another is
   available in [RFC2510].  In particular, the oldWithNew and newWithOld
   advice ensures that relying parties are able to validate certificates
   issued under the current Root CA certificate and the next generation
   Root CA certificate throughout the transition. Further, this
   technique ovoids the need for all relying parties to make the
   transition at the same time.

Russ