- From: Eliot Lear <lear@cisco.com>
- Date: Wed, 14 Nov 2012 20:09:20 +0100
- To: Martin Thomson <martin.thomson@gmail.com>
- CC: "Adrien W. de Croy" <adrien@qbik.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On 11/14/12 7:59 PM, Martin Thomson wrote: > Just on this, it seems reasonable that the only necessary axis here is > version. Thank you for answering the question. > Having multiple records of the same type at the same node is > already possible for SRV for load balancing and failover reasons; this > would add one more reason: versioning. Two axes is already a lot, a > third is bad enough. That's a fair point. Question: how would you handle SRV with http://www.example.com:49080? Eliot > >> Use of SRV of any form with regard to TLS would require a substantial change >> in how we clients validate hostnames. I tell you from personal experience >> that having a new SAN "Other" type is not an easy thing to ask of CAs. > I don't see how you would conclude that. If you are seeking > 'example.com', then that is what you should look for in the > certificate. It doesn't matter what you had to query the DNS for to > get an IP and port to get there. > > This happens all the time already with CNAME records - the browser > still uses the *input* name to validate the certificate, not some > intermediate gunk. > I'm saying that TLS processing of hosts with SRV records works *sometimes* using other protocols, but at least in this circumstance in thinking about it there is no need for SAN Others. Eliot
Received on Wednesday, 14 November 2012 19:09:49 UTC