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

[Eliot Lear <[e-mail]>]

Hiya,

> On 18 Mar 2021, at 19:58, Michael Richardson <[e-mail]> wrote:
> 
> A pity that EST (and I think SCEP, but I haven't read it all), just returns
> the resulting certificate, and not something more useful, like a JSON dict
> that includes the certificate.
> 
> RFC7030 has a 202, Retry-After, which could be used to tell the holder to
> go away and come back later, but the intended use is not to say not now,
> but rather, "I'm working on it".

This is definitely a problem in a number of deployments.  One aspect that people have to deal with is not so much the gross expiry time, but when it is convenient to take a risk of moving to a new cert.  Of course you’re going to want to make that operation as bullet-proof as possible, but in some environments they want multiple levels of resilience.  So scheduling does become an issue.

The big question is- who does the scheduling?  Is it the end system?  Is it the EST server?  Who knows when “convenient” is?  Probably the answer is “both”.

Eliot

> 
> If the whole thing was more RESTful, then holders could be told to GET their
> certificate from some place, and we could use ETag, and Expiry headers to
> tell the holder that it hasn't changed, and isn't expected to change for
> awhile, so piss off and come back then.
> 
> In the full ACP situation, then we might expect holders to have active
> RESTCONF management, and then we can renew certificates in a push scenario
> using draft-ietf-netconf-sztp-csr-01, which I note is now past WGLC.
> 
>> A related idea is that an RP can want certificates to be "fresh" enough
>> regardless of when their notAfters are, and again, there's no signaling
>> that via the supplicant's certificate unless somehow the issuer is
>> expected to know a policy all RPs want.
> 
> I'm much less concerned about the RP here.
> The reason to issue long lifetime certificates is that things don't break
> just because some less critical infrastructure is not alive, or not reachable.
> 
> Our reference example/use case in brski-async-enroll is communication between
> thermostats and furnaces in a (newly built) residence.
> The furnace needs to heat keep the home above zero even when the house is not
> occupied, and possibly has not yet been occupied.
> 
> Maybe abuse of the certificate renewal process is the wrong way to accomplish
> transfers of ownership.
> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
> 
>