> I think one would also have to include the endorsed EESPKI (End-Entity > SubjectPublicKeyInfo, a.k.a. the server public key) too (or at least > collision-resistant hash of it)? > > That should rarely change, so it should be quasi-constant.
That works, but I'm not convinced it's necessary. Firstly, doing that means it would be necessary to change the authorization model so that an authorization can be valid for only some CSRs, namely CSRs with a certain subject public key. There could be some advantages to doing that. For example it would also make it easier to model the automatic conversion of DANE records into authorizations, as I wrote previously regarding DNSSEC. But the current authorization model is that if you can provision DNS records, you can get a certificate without any particular restrictions on the subject public key. I don't see how moving to a deterministic DNS response weakens this? Binding to the public key would prevent the regular changing of keys. As it is there's little reason not to generate a new key for each renewed certificate request unless you're doing end-key pinning. Hugo Landau _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
