Date: Wed, 17 May 2000 22:13:44 -0700 (PDT) From: "Duane H. Hesser" <dhh@androcles.com> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: security@FreeBSD.ORG Subject: Re: HEADS UP: New host key for freefall! Message-ID: <XFMail.000517221344.dhh@androcles.com> In-Reply-To: <Pine.NEB.3.96L.1000517173531.25211A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 17-May-00 Robert Watson wrote: > 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. > Browsers are equipped to download new CA certs and install them in the database. Netscape and MS do it differently, of course, so (at least) two formats must be provided. Grabees must be confident of the site from which the cert is obtained, of course. > 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. > Are you talking about a server cert here? That would allow securely distributing your own CA cert (as mentioned above), but doesn't give you any signing capability. I'm not sure what you mean by "automated cert evaluation". > 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? > Those are some good questions; there are lots more. The first step, as you all know, to designing any system is to decide exactly what the system is to do. Will the certs be used for SSL only? Will they be used for signing? How many levels of certificate will you need? You will need some specific policies and a Certificate Practice Statement to go along with them (look at Verisign's CPS some time). Entrust used to have some good white papers describing some of the issues involved in setting up a CA and the responsibilities of a CA--I think the good ones are mostly gone now. You need to think about archiving, possibly for decades. How many people does it take to exercise the signing key? How much confidence can users expect to place in certs you've signed? What will you do if a cert is compromised? What will you do if your signing key is compromised. Do you have a secure vault to lock up the keys and the signing engine (most CAs do just that)? A secure repository for certificates? Will your CA sign the keys of subservient CAs? What about auditing (who, how often)? Certificate revocation? Will your certs support non-repudiation? What process will be used to validate the identity of the applicant (at each level of certificate)? Key management? What happens when a user's cert expires? How easy (hard, reliable) will it be to renew? What key sizes will you support? What key size will you use for your signing key. You can punt many of these issues by becoming a Registration Authority for an existing CA (e.g Verisign's Onsite program). If you do, you relinquish some of the advantages of running your own CA (e.g Quality of Service, Reliability, Control). Either way, you'll pay per certificate, either a one-time per cert royalty or a per-cert fee. Commercial software works that way (and low volume fees aren't cheap, in my estimation). How long will the fight over the use of Java and/or JavaScript in the CA system last, and how many friends will it alienate. You *really* need to have your ducks in a row if you're going to establish an X509 CA. None of this is intended to discourage the effort--I'm a long-time proponent of the use of public/private key cryptography as an aid to authentication. X509 certs are the most likely way to get there at this point (but I've been assming that for 4 years, and *nobody* is signing documents--or even applets-- online yet. How many people do you know who have client certs, even to access their bank acount, or their company 401k? They're still using PIN numbers, for G* sake. There may be better ways for small (say, less than a million participant) open-source groups to do roughly what is implied by the conversation I've seen so far, but X509 will work if you're willing to pay the freight. > 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. ... Digital signature have always had legal implications; it's just that nobody knew just what they were. Check that...nobody *knows* just what they are. It's possible to deduce logically what the implications are, and to prepare elaborate Certificate Practice Statements outlining the responsibility you're willing to accept, but no one has ever accused the US court system of elaborate concern for logic (sorry, I have no data for the rest of the world). To the best of my knowledge (and I've been watching for 3 or 4 years) there has never been a court case regarding certificates which might even *begin* to illuminate the position courts will take on relevant issues (anywhere in the world). The ABA does have guidelines (and some state bars are issuing certs themselves), and several states have CA licensing laws (Utah, California, Washington, that I can think of, and others). Some states have "electronic signature" laws which do little more than confuse the situration. The US Congres is of course bickering slowly over the topic. McBride, Baker and Coles (a law firm) have a page which has been tracking these issues in the US for years: http://www.mbc.com/ecommerce.html There are also links to information for many other countries. > ... 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 > Presumably, they will have as much confidence as the CPS says they can have. You *have* read Verisign's CPS, haven't you? Here's the URL to Entrust's papers on the topic--there are still a few useful ones, if you have time to paw through lots of PDFs: http://www.entrust.com/resourcecenter/whitepapers.htm Here are URLs to some CAs that have sprung up in Utah (and one in Washington) since their Digital Signature laws were passed. They may be informative. (Verisign and Thawte aren't the only games in town.) http://www.arcanvs.com/ http://www.usertrust.com/ http://www.digsigtrust.com/ http://www.caserver.com/ (Houston, we have a CA) http://www.idcertify.com/ (Seattle) http://www.cost.se/ca_int22.htm (ok, this is not Utah...) (I take no responsibility for URLs which point to MicroSoftHeaded servers) Note that some (most?) of these offer links which will allow you to install their CA cert in your browser CA database. IMHO, you're asking the right sort of questions. Ask more of them. -------------- Duane H. Hesser dhh@androcles.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.000517221344.dhh>