Sounds interesting, thank you!
I suppose if we have the ACME "application objects" and they support
renewal/reissuance, that would also apply to my Option 2, i.e. the TLS
server accessing ACME directly. Of course Option 2 would still require
an extension of the ACME protocol.
Thanks,
Yaron
On 20/07/16 17:43, Andrew Ayer wrote:
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
