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

RE: Uses for self-signed certificates (Was: Browser security warning)

From: Hallam-Baker, Phillip <pbaker@verisign.com>
Date: Tue, 9 Jan 2007 06:23:54 -0800
Message-ID: <198A730C2044DE4A96749D13E167AD370105A116@MOU1WNEXMB04.vcorp.ad.vrsn.com>
To: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>, "W3 Work Group" <public-wsc-wg@w3.org>

I think that this comes down to the poorly considered semantics of the padlock icon. "Its encrypted" vs "It safe". 

I have no problem turning on SSL any time at all provided that the user is not given a false sense of security. Don't show the padlock, maybe warn if the user actually typed in https://.

 

> -----Original Message-----
> From: public-wsc-wg-request@w3.org 
> [mailto:public-wsc-wg-request@w3.org] On Behalf Of Stephen Farrell
> Sent: Tuesday, January 09, 2007 8:30 AM
> To: W3 Work Group
> Subject: Re: Uses for self-signed certificates (Was: Browser 
> security warning)
> 
> 
> 
> A slightly different, but real, self-signed cert use case.
> 
> I help train one of my kid's football teams. We keep various 
> contact information etc on a web server and only share that 
> amongst team mentors. The information includes some sensitive 
> stuff, e.g. kid's phone numbers, some medical info (the 
> number of kids with "slight asthma" these days is amazing!); 
> basically the usual stuff that parents would not want published.
> 
> There is no-one anywhere who wants to have to pay for an 
> SSL-server cert for this purpose. Given the small scale of 
> the use-case, a self-signed cert is perfect for this.
> 
> I guess you could generalise this use-case to be "small 
> informal groups sharing sensitive information" or something 
> like that, and this differs from the furnace in that there's 
> a group of users involved and no devices.
> 
> Note: If I setup my own root CA and got the other team 
> mentors to trust that, then I would be very slightly 
> increasing their exposure, since then compromise of my 
> CA/server would allow the bad guy to introduce new servers to 
> the other team mentors.
> With a self-signed cert, compromise of my server has no 
> effect other than on content (apparently) rx'd from my 
> server. However, were setting up a root CA as easy as 
> generating a self-signed cert, then the difference would be 
> ignorable. However, setting up a root CA is not nearly as easy afaik.
> 
> And while these factoids are probably not relevant, the 
> actual use case also involves the following:-
> 
> 	- sending group SMS messages, but we've not integrated
> 	that into my web server (I guess we could). Were group
> 	SMS integrated then there'd also be a potential cost
> 	issue for whoever's mobile is being billed once the free
> 	messages/month or whatever are used up (they do get used
> 	up)
> 	- the content in question will also tend to migrate from
> 	server to server, roughly in sync, with changes in
> 	employment or ISP or whatever, but that should probably
> 	be ignored
> 	- in our case, we also have a mailing list with an
> 	archive, but that's hosted, so proper certs are fine
> 	there, but I guess a variant might call for using the
> 	same self-signed cert for both web content and mail
> 	archive, in fact, I periodically send out the main
> 	https:// URL and the one and only http-basic username
> 	and password on that mailing list but that's an ok level
> 	of risk IMO (I guess one of the other mentors loses or
> 	forgets the password or changes computer or whatever
> 	every couple of months)
> 
> Stephen.
> 
> 
Received on Tuesday, 9 January 2007 14:24:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 5 February 2008 03:52:45 GMT