On Thu, Mar 18, 2021 at 02:58:08PM -0400, Michael Richardson 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.
But you can always send this kind of metadata in response headers. > 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. Yes, why not. A client that wants a certificate renewed too soon is not really a problem, unless it's abusive. But how would a _stateless_ CA know a client is being abusive other than by how soon the client is back? Still, suppose some supplicant has a valid certificate and some RP balks and says "come back with a fresher certificate"? What if this happens before 50% of the original certificate lifetime is up? I think "too soon" might best be defined as after 25% or less of the original certificate lifetime has passed since issuance. But then, I don't run massively popular public online CAs. > 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. In a small enough network like a home network, I would think that forever credentials + revocation is the best answer. > Maybe abuse of the certificate renewal process is the wrong way to accomplish > transfers of ownership. I think next time I move I'll rip out all the thermostats and replace them with new ones to my preference :) But yes, I suspect there will come a time when there are many computers (and much firmware) in a home just as in motor vehicles, many/most/all not serviceable or replaceable by the "owner". Nico -- _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
