Hi Yaron, Thanks for keeping the ball rolling.
It looks like the prominent operational difference between the two proposals is who has the onus for the functionality. In (1) the content owner is responsible for the proxying machinery that does the mediation between LURK and ACME. In (2) the onus is on the CA/RA that has to implement the new ACME interface. >From the perspective of (what LURK calls the) "TLS server", the difference in complexity and security is minimal: both require a new simple client API and a private key to authenticate to the server side. User-wise there is no difference at all, AFAICT. (In both cases a "delegated-by" non-critical extension as proposed by Carl could go in to the issued certificate -- if the content owner wishes so && the CA supports it.) Speaking as a CDN provider, I tend to like (2) better. Apart form aesthetic considerations, I think it's easier to persuade content owners to adopt it. What they need to provide is the bootstrapping (and termination) operations, which are trivial. Viceversa, (1) would require the content owner to operate a (highly available) LURK-ACME proxy. However, I am concerned about what are the incentives for a CA to implement this new ACME interface? Cheers, t _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
