Nico Williams <[email protected]> wrote: > On Thu, Mar 18, 2021 at 05:54:55PM +0100, Toerless Eckert wrote: >> On Thu, Mar 18, 2021 at 08:57:04AM -0400, Michael Richardson wrote: >> > It seems that a CA ought to be able to express some other kind of renewal >> > period directly. Is there any work in this area?
> Well, it's a simple certificate extension to do that. But do RPs need
> to see it? It seems like the enrolment protocol should tell the holder
> when to come back. Still, it's simplest to stick it in the certificate
> as an extension. No idea if there's any work going on around that.
Yes, I agree, the RP doesn't need to know.
It could well be state somewhere during the enrollment protocol.
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".
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: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
