Stephen Farrell wrote: > > On 04/10/10 15:37, Martin Rex wrote: > > One thing that needs to be addressed/solved is the key/cert rollover > > for any TLS-Server, so that it is possible to list more than one > > server cert as "valid" for a Server through DNS, at least for the > > time of the transition/rollover. > > Maybe a side-issue here, but this came up in the W3C WSC work and > I wrote up an idea for that (not based on DNS) which is RFC 5697. [1] > No idea if anyone is using or would use it, though I did have a student > implement it, so it *could* work. (Note: that's an experimental-track > RFC, as it ought be:-) > > S. > > [1] http://tools.ietf.org/html/rfc5697
I do _not_ like the OtherCertificates extension. If some client would honour this for a "pinned" cert, it would allow an arbitrary CA under any of the trusted roots to completely subvert the clients motivation of pinning the cert. A sensible approach would require a certificate extension in the new cert which provides a proof from the original certificate holder (i.e. signed with the private key of the old cert), that the new cert (the public key and at least some of the certificat attributes, such as subject name, all subjectAltNames, BasicConstraints, keyUsage, ExtendedKeyUsage, maybe more) are a valid replacement for the original server cert. Key continuity without the consent of the original key holder looks dangerous to me. -Martin _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
