Re: [netconf] [lamps] Long-lived certificates, but frequently renewed certificates

Michael Richardson <> Sat, 20 March 2021 17:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6229B3A26E9; Sat, 20 Mar 2021 10:32:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lov2v-d93I40; Sat, 20 Mar 2021 10:32:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DA9C43A26E7; Sat, 20 Mar 2021 10:32:07 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 74D6C389AA; Sat, 20 Mar 2021 13:37:48 -0400 (EDT)
Received: from ([]) by localhost (localhost []) (amavisd-new, port 10024) with LMTP id pOCgstnlnbkW; Sat, 20 Mar 2021 13:37:47 -0400 (EDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 6313D389A1; Sat, 20 Mar 2021 13:37:47 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 4BC84240; Sat, 20 Mar 2021 13:32:05 -0400 (EDT)
From: Michael Richardson <>
To: Tomas Gustavsson <>,,,
In-Reply-To: <>
References: <> <22886.1616091336@localhost> <> <> <>
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: Sat, 20 Mar 2021 13:32:05 -0400
Message-ID: <29802.1616261525@localhost>
Archived-At: <>
Subject: Re: [netconf] [lamps] Long-lived certificates, but frequently renewed certificates
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 20 Mar 2021 17:32:11 -0000

Tomas Gustavsson <> wrote:
    >>> It's common in eID/ePassport, such as ICAO 9303, to sign "new with
    >>> old". That way, if trusting the old trust anchor, you can automatically
    >>> trust the new. The other way (old-with-new) I have not seen any use of
    >>> in practice.

    >> The old-with-new and new-with-old practice is described in RFC 2510.

I wandered through the document, it does not have a ToC.
I think section 2.4 _Root CA key update_ ?
The terminology OldWithNew explained in 2.4.1 but not directly.
In RFC2510, it doesn't matter, since we do all four combinations.

    > I know that. I'm merely pointing out that I have not seen anyone actually use
    > new-with-old in real life. I put a question to the list some time ago (during
    > CMP update discussion) and no-one (that answered) remembered ever seeing it
    > in real use.

I see.

    > Old-with-new is fairly trivial, both technically and
    > organizationally. New-with-old puts completely different requirements on a CA
    > rollover procedure, for in most cases no reason. Anything new designed I
    > would rather see analyze the usage and need instead of simply copying the
    > notation from RFC2510.

Let me expand the terms:
  old-with-new  -> old public key signed with new anchor
  new-with-old  -> new public key signed with old anchor

There is an existing old-with-old, which is the old anchor.
There will be a new-with-new, which is the new anchor.

I guess I can see how one can run with just old-with-new.

Both situations insert an additional subordinate CA between the trust anchor
and the EE.    The process described in RFC2510 essentially assumes that all
devices are online and can always query the directory.

The first devices that come back to the Registrar to renew will get a
certificate signed with the new-anchor, and will be provided with a
certificate that includes the chain [old-signs-new, EE], which it is to use
for whatever peer to peer communications it does {(D)TLS, EDHOC, IKEv2, 802.15.9...}

The device will have to keep the old anchor, and get the new anchor.
It feels like this means transfering the old anchor again.
(Esko: this argues for the ability to return multiple items, one at a time
via CoAP.  Somehow ETAG to avoid redundant transfers?)

This works with peer devices which have not updated yet, as they will just
see a longer chain.  Devices with the new anchor will skip verification of
the "old-signs-new" in the chain, as they will immediately be able to verify
with new.
When all devices have a new certificate, then we would ideally like a second
round of renewals where the old-signs-new is removed, and the old anchor is
removed.  That doesn't actually have to replace or update the EE, I think.

We just need to remove the old anchor, and delete all entries where old signs
something from the chain.  Has this been signaled in some way?
We certificate renewal done relatively soon accomplishes it, at the cost of
more bytes transfered and some needless writes to flash.

This doubly motivates either making all renewals driven by the Registrar
(reaching out via RESTCONF, CORECONF)!  Or to having a clear signal that
despite the notAfter being in some distant reliable future, that a higher
frequency of renewal attempts is desired.

These seem like things we should have put into draft-ietf-ace-est-coaps!
Some of this is also already worked out for symmetric network keys in

Michael Richardson <>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide