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

[Michael Richardson <[e-mail]>]

Tomas Gustavsson <tomas.gustavsson=[e-mail]> 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
draft-ietf-6tisch-minimal-security.

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