Hiya, > On 18 Mar 2021, at 19:58, Michael Richardson <[email protected]> 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 <[email protected]> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
