On Wed, Jul 01, 2020 at 08:30:36PM -0400, Michael Richardson wrote: > > Toerless Eckert <[email protected]> wrote: > > The need to diligently document support for CRL/OCSP was done on > > behalf of securiy reviews. It is not meant to be a recommendation. > > There is mentioning of short-lived certificates in a few places in the > > doc. > > I didn't see an RFC8739 reference. Oh. It's I-D.ietf-acme-star. > Your section 6.1.5.4 suggests CRLs are unnecessary when the lifetime is on > the order of hours, while RFC8739 is less specific about what is short.
2.3 days is one number i found in the RFC. IMHO RFC8739 is not a relevant comparison for ACP (and i am not only saying this because otherName killed our ability to use ACME CA with RFC822 names ;-): Unless i am missing something, ACP/EST renewal of certs is already the same "lightweight" renewal that RFC8739 introduces for ACME. In addition for ANI nodes, we always have re-enrollment via BRSKI/MASA. Aka: ultimately, the question is whether/how we should deal with expired certs under incomplete reachability. Max already said that it should be perfectly fine for EST to accept expired certs as a valid credential for renewal, that was just never top of mind when EST was developed, and it certainly would cause hesitation at first by IETF security review should that be added. I for once had to regularily re-activate enterprise WFH VPN clients that where switched off for months, then users sent me email, and i had to go to the VPN server and configure "ignore lifetime for this cert", so the VPN client would renew its cert. > I think that a certificate lifetime on the order of a week would probably be > workable. I think that if you want to get rid of CRL/OCSP then you need to get down to reaction time at the order of revocation, which i think can be as little as 30 minutes. I think its not a problem to do that, its just far off the beaten track people feel offended to think about it. There are a lot of network operations aliveness operations at a 30 seconds interval for every node (aliveness ping). Doing a simple cert re-signing once every 30 minutes isn't worse IMHO. > But, I think think we should get implementation experience. Sure, but there are a lot long-term issues that can happen, sometimes folks take yeas in deployments to figure out probems with cert lifetime management, hence the theoretical discussion is useful here too. > >> I think that CRLs are not useful, and we should not use them. > > > I think we agree. > > Good. > > >> 6.1.3 is clear that OCSP/CRLs may not be available when connecting! > >> > >> I think that use of STAR (https://datatracker.ietf.org/doc/rfc8739/ ) > >> Short-Term, Automatically Renewed is the best recommendation! > > > In general yes, but the STAR use cases typically do not take into > > account connectivity problems that are longer than the lifetime of > > a cert, whereas for the ACP this might be a problem. > > yes, but the solution is to find a Join Proxy, reach out to the Registrar and > renew the certificate using the LDevID one has. > STAR even went into some detail about how one could renew expired > certificates, I think. (I recall a discussion, but I'd have to check the > document again) Exactly, but that i think was also why the general purpose STAR document didn't progress in LAMPS. But i forgot all the generic issues there, i think to remember they are not an issue for ANI/ACP though, but obviously that would have to be probed by going to LAMPS with a more constrained EST renewal with expired certs discussion. > >> If we have to do OCSP (via https://datatracker.ietf.org/doc/rfc4806/ ) > >> then we nodes can download their staple and provide it when connecting. > >> New nodes can get this using the Join Proxy. > >> > >> Perhaps this needs to be in a new document at this point. > > > Yepp. I think to remember that MaxP was thinking of suggesting to > > talk about dealing with expired certs for our cases in i think LAMPS too > > but longer ago... > > yes, the document wound up in ACME, and I think they did a good job, although > it is proscriptive for ACME only, while our end-client interface is assumed > to be EST. Yepp. The comparison is probably that doing in ACME the revalidation of ownership of (domain/email) name is as complex as going through BRSKI/MASA, whereas doing just EST renewal, worst case via join-proxy (if cert is expired) is exactly what RFC8739 does for ACME. Cheers Toerless > -- > Michael Richardson <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > -- --- [email protected] _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
