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

[Michael Richardson <[e-mail]>]

Nico Williams <[e-mail]> wrote:
    >> The Second case is generally easier, so long as the device is
    >> regularly in service; and it may even be easy when the device is out
    >> of service for extended periods (think years) so long as it is thought
    >> about in advance by both implementor and deployment.

    > End entities send a validation chain for their EE certs, but not the
    > root CA's cert, and anyways, RPs need to know trust anchors a priori.
    > Therefore rolling out new TAs is tricky.

TLS discourages sending the root CA cert.
I prefer to send it for a number of reasons, and this is one of them.

    > TA rollover needs a device update protocol.  Which is a pain in large
    > part because it's completely unstandardized and anyways implies a
    > separate trust structure for update signing (e.g., a package signer
    > PKI).

EST includes includes updating the CA trust anchors as a protocol item.
We don't have to have to replace the firmware.

    > So I think we're talking about the server indicating a refreshAfter time
    > or a doNotRefreshBefore time rather than a refreshAt time.  An
    > informative "you can refresh after this $time" and maybe a normative "do
    > not even think of refreshing before this $time".

Yes, that's exactly what I'm after.
We can, as you suggest, do this as an HTTP header in EST.
It could also go into some new certificate extension, although it's rather
more meta data, and it isn't clear it should get shared with peers.

    > Michael
    > tells me maybe the CA software gets upgraded and other changes sneak in
    > that one did not expect.

So, I was thinking of a hypothetical that could result in a surprising change
in the field during what should be a non-event renewal.

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