From owner-freebsd-security Wed May 17 14:42:21 2000 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 8DB1D37BCBB; Wed, 17 May 2000 14:42:14 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id RAA25744; Wed, 17 May 2000 17:42:05 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Wed, 17 May 2000 17:42:05 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Kris Kennaway Cc: Garrett Wollman , security@FreeBSD.org, Darren Reed , Peter Wemm Subject: Re: HEADS UP: New host key for freefall! In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 17 May 2000, Kris Kennaway wrote: > On Wed, 17 May 2000, Garrett Wollman wrote: > > > organizations which use X.509 for internal authentication purposes > > run their own CAs and deploy customized Web-browser installations > > which come with the appropriate CA certs preinstalled. (My employer, > > which owns tens of thousands of computers and has almost as many > > employees, does this. People who install the ``latest and greatest'' > > browser from wherever don't get support.) > > We could implement this without too much trouble by shipping the root cert > on CD with FreeBSD releases (and having some kind of online distribution > method, perhaps signed by a bunch of PGP keys) and instructing people on > how to load it into netscape (if it were to be used for https purposes). > Perhaps we could even make the netscape port pre-load it - we already have > the infrastructure for customizing netscape prior to use. The typical cheap-skate response to other CA's being expensive is to get an SSL cert from Thawte or Verisign, and distributed your certs via a web ste hosted using that well-known CA. You don't get the automated cert evaluation, but can provide a trusted path for cert retrieval. In a prior e-mail, someone raised that doing a full secure facility is not necessary given the size of the project. It's useful to understand who will be relying on these keys as a means of evaluating the need for doing the "CA" thing properly: 1) Is it just the committers? (small community that can forgive mistakes) 2) Is it committers + developers? (larger and less forgiving community) 3) Is it the general user population? (extrmely large community with their jobs and businesses on the line) In addition, how will the certs be used? 1) For manual verification and retrieval only? 2) For automated installation of security patches? My assertion is that if we begin distributing software in a signed way, we need to do it right. This means signing all release announcements, signing md5 checksum sets over releases, signing security updates that can be installed using a binary installer, etc. We also need to understand that in more and more places, digital signatures now have legal connotations. Are we accepting more responsibility by signing things in these places? Do we become more liable? Hopefully the answer on this front is no, but it is important that we be sure. Similarly, if we start signing things, people will assume they can have greater confidence when installing over the network, et al. Is this true? Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message