http://www.ietf.org/mail-archive/web/acme/current/msg00203.html Key attestations rocks :-)
On 2015-01-26 19:20, Phillip Hallam-Baker wrote:
What is the attack model here? What form of attack is unacceptable? We have a request for a cert for www.example.com <http://www.example.com> to Alice-Cert. What attacks do we consider problems? 1) The holder of www.example.com <http://www.example.com> did not authorize any cert binding to that private key. 2) The holder of www.example.com <http://www.example.com> authorized a cert for that key but it was for Bob-Cert. 3) The holder of www.example.com <http://www.example.com> thinks they are connecting to Alice-cert but they are actually connecting to Mallet-Cert. (1) is very clear problem but (2) is not unless there is an application that makes use of the certificate without a private key or vice versa. (3) is going to be trivially solved by checking the issued cert chain. TLS does not permit certificate substitution attacks. Binding every communication to a private signing key held by the applicant is a good idea. Requiring that to be the private key in the cert is a very bad one. Not least because once we stop using RSA, encryption keys and signature keys become two different algorithms and there are good privacy reasons to prefer a key agreement based on encryption and an ephemeral rather than signature and an ephemeral. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
