W3C home > Mailing lists > Public > public-wsc-wg@w3.org > March 2007

RE: Produce material on name-based virtual hosting and TLS

From: Mary Ellen Zurko <Mary_Ellen_Zurko@notesdev.ibm.com>
Date: Wed, 7 Mar 2007 07:48:19 -0500
Cc: "EKR" <ekr@networkresonance.com>,public-wsc-wg@w3.org
Message-ID: <OFB56F45A1.E7DDF154-ON85257297.00462F23-85257297.0046578F@LocalDomain>
To: pbaker@verisign.com
Hi Phil (and Eric),

Discussions with non WG members should be conducted on 
public-usable-authentication@w3.org. That's what it's there for, and 
that's why it's called out in the Note. 

If there are WG members not subscribed there, I encourage you to do so. 


Mary Ellen Zurko, STSM, IBM Lotus CTO Office       (t/l 333-6389)
Lotus/WPLC Security Strategy and Patent Innovation Architect

"Hallam-Baker, Phillip" <pbaker@verisign.com> 
Sent by: public-wsc-wg-request@w3.org
03/06/2007 10:41 PM

"EKR" <ekr@networkresonance.com>
RE: Produce material on name-based virtual hosting and TLS

Does the protocol allow the client to state that it supports NBVH? If so 
the transition becomes smooth provided EV capable Web browsers also 
support NBVH as a matter of course. 

> -----Original Message-----
> From: EKR [mailto:ekr@networkresonance.com] 
> Sent: Tuesday, March 06, 2007 6:53 PM
> To: Hallam-Baker, Phillip
> Cc: public-wsc-wg@w3.org
> Subject: Re: Produce material on name-based virtual hosting and TLS 
> Hallam-Baker, Phillip <pbaker@verisign.com> wrote:
> > (cc'd to EKR for comment)
> > 
> > I thinbk we need a section 9.6 as follows
> > 
> > 9.6 Cryptographic protocol limitations
> > 
> > 9.6.1 Layering of HTTP on SSL requires a static IP address 
> per secured 
> > site
> > 
> > IPv4 address space is a finite and increasingly scarce 
> resource. In order to reduce pressure on the IPv4 address 
> space the HTTP/1.1 protocol allows multiple domains to be 
> hosted on a single IP address.
> > 
> > This feature is not fully supported when HTTP is layered on 
> SSL 3.0 or TLS 1.0. The HTTP URI or Host header specifying 
> the virtual domain to connect to is only transmitted after 
> the transport layer security negotiation is complete. This 
> configuration does not allow the server to vary the server 
> certificate presented unless a separate IP address is used per domain.
> > 
> > This restriction is lifted in RFC 4366 S 3.1. Clients that 
> verify that the domain name of the certificate matches the 
> domain name of the site should be encouraged to support this 
> extension.
> This seems pretty correct. It might be nice to mention that 
> servers can't safely use NBVH until client deployment becomes 
> ubiquitous.
> -Ekr
Received on Wednesday, 7 March 2007 12:48:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:14 UTC