On Thu, Nov 12, 2015 at 01:20:01PM +0000, Hugo Landau wrote: > > 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.
Probably not actually necressary, given that one could have domain endorse the account keys and account keys endorse the server 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. Well, either the DANE conversion issuance would have to be anonymous, or one would have DANE just act as restriction on server key. > 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? Oh yes, the "hack A/AAAA and get a cert". > 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. Or it is hard to change the key... -Ilari _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
