On Wed, 20 Jul 2016 11:51:57 +0200 Yaron Sheffer <[email protected]> wrote:
> Second, I would like the group's advice in choosing between two very > different approaches to this problem. I prefer option 1, but with a tweak. I think the server should only be required to generate and register a new CSR if the key changes. Otherwise, the CA should automatically sign new certificates periodically and they should be retrieved from the CA by the TLS server using a simple unauthenticated GET operation. (Since these certs are static, the CA would ideally serve them via a highly-available CDN environment, much like pre-generated OCSP responses.) This would be possible if application objects supported renewals, as I discuss here: https://mailarchive.ietf.org/arch/msg/acme/NFgZShOcKH38QV1hh-fT3Dnp8bs If the domain owner wants to revoke a delegation to terminate TLS, they just have to contact the ACME server and disable the application. This is a simpler architecture and much more reliable since you only need to worry about authenticating and proxying CSRs during key rotation, which presumably doesn't need to happen that often as long as your TLS connections use forward secrecy. The normal day-to-day certificate refreshes wouldn't depend on the domain owner's server being up, and would also be resilient to brief outages of the CA's signing infrastructure. As for swamping CT logs, that's probably a better question for the CT mailing list. I will say that the working group has been trying very hard to minimize the complexity of TLS clients (see redaction). Doing things like logging delegations would necessarily complicate TLS clients (since TLS clients would need to verify the delegations) so I suspect the answer will be to just log the short-lived certs and focus on making logs cope (e.g. log rotation so it's easy to rotate logs when they get too big). Regards, Andrew _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
