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

On 2007-01-09 06:23:54 -0800, Phillip Hallam-Baker wrote:

> 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://.

Another differentiated use case is lurking its head: User follows
URI and somehow lands on TLS site vs. user types in https or follows
https bookmark.

>  
> 
> > -----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.
> > 
> > 
> 
> 

-- 
Thomas Roessler, W3C  <tlr@w3.org>

Received on Tuesday, 9 January 2007 14:28:30 UTC