Re: [lamps] rollover of CA

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 03 September 2021 18:08 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 F3F7F3A2761 for <spasm@ietfa.amsl.com>; Fri, 3 Sep 2021 11:08:36 -0700 (PDT)
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 wzJeHXi3Rrve for <spasm@ietfa.amsl.com>; Fri, 3 Sep 2021 11:08:31 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC9DA3A2760 for <spasm@ietf.org>; Fri, 3 Sep 2021 11:08:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id DDCA83958C; Fri, 3 Sep 2021 14:14:34 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id oBMzijnl_zpG; Fri, 3 Sep 2021 14:14:29 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D651139588; Fri, 3 Sep 2021 14:14:28 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 69E51AC; Fri, 3 Sep 2021 14:08:22 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Tomas Gustavsson <tomas.gustavsson@primekey.com>, Deb Cooley <debcooley1@gmail.com>, Ryan Sleevi <ryan-ietf@sleevi.com>, SPASM <spasm@ietf.org>
In-Reply-To: <SJ0PR22MB25424D58B3069358F1984B3EE8CF9@SJ0PR22MB2542.namprd22.prod.outlook.com>
References: <17240.1630591789@localhost> <CAErg=HH9o8wXgo9RS0GDrn6ZgL7TD3TF25PiUNW7XePML7252w@mail.gmail.com> <CAGgd1Odk-xVmYb8-i-1pCv-n=oeFCnjt-xsCC9mqvGowaLpeZg@mail.gmail.com> <SJ0PR22MB25424D58B3069358F1984B3EE8CF9@SJ0PR22MB2542.namprd22.prod.outlook.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Fri, 03 Sep 2021 14:08:22 -0400
Message-ID: <18772.1630692502@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/sDG5Ksmt1zp2FvwsjGWWyPvIhFY>
Subject: Re: [lamps] rollover of CA
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: Fri, 03 Sep 2021 18:08:37 -0000

Tomas Gustavsson <tomas.gustavsson@primekey.com> wrote:
    > I remember being part of that discussion Michael.

    > RFC4210 describes it in section 4.2.
    > https://datatracker.ietf.org/doc/html/rfc4210#section-4.4

    > In reality I have only seen rollover using newWithOld, for example in
    > ICAO 9303 part 12 (there called Link Certificate). The purpose being to
    > be able to automatically update trust anchor with a new Root if you
    > already trust the old Root.
    > https://www.icao.int/publications/Documents/9303_p12_cons_en.pdf

    > I have never understood the purpose of, or seen a practical use, of
    > OldWithNew.

OldWithNew allows a device with an OldCert to be trusted by a device that
has the NewCert.   If the device would simply retain the OldCA, then it's not
needed.

However a device which has been recently commissioned might have never seen
the oldCA.   If it has to validate a connection from a device which has been offline for
awhile, it would an issue.
In practice, how would the old device ever get the OldWithNew Link Certificate?
That implies that the OldWithNew Link Certificate would never get sent
inband, but rather needs to be provided to new devices when they enroll.

For a practical explanation of this, and the risks of it, I refer you to:
  https://www.youtube.com/watch?v=4HJ-Y8YTo8Q   :-)


--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide