though, that being an anti-fan of X.509 the situation would be ironic...

Perry

Speaking of ironic situations, my sister recently mentioned that her fiancee is a good friend of Jim Bidzos and asked me if I wanted a job with RSADSI. If I wasn't planning on leaving the employed-by-others arena I would have seriously considered it. ;-) In terms of being a CA. I have considered making Community COnneXion a CA for its customers, but I haven't done much research into what is involved in doing that. -- sameer Voice: 510-601-9777 Community ConneXion FAX: 510-601-9734 The Internet Privacy Provider Dialin: 510-658-6376 http://www.c2.org/ (or login as "guest") sameer@c2.org

Alas, certain critical social steps have been elided in the proposed protocol. As it happens, I'm working on an article, to be published in the Oregon Law Review next year, on "The Importance of Trusted Third Parties in Electronic Commerce". It's mostly about the care and feeding (and legal liability!) of a CA. Unfortunately for this discussion, I'm only part way through my thinking about what the liability of a CA might be so I don't have carefully considered conclusions to offer you. Try me again in a few weeks. In the absence of legislation... [PLUG: if you haven't already done so, RUSH to my homepage http://www.law.miami.edu/~froomkin and click on the link to the ABA draft of the digital signature guidelines. This mis-named document is actually all about CA liability. Comment period now extended to mid-January.] ...you need to worry about who might *use* the certificates, and what they might to do the CA in the case of mis-certification or other misfortune. At the very least, there is a tort claim for "negligent mis-representation" the first time an inaccurate certificate, or an accurate certificate referencing a compromised key, is used in a transaction that goes sour. I don't give legal advice on line, ever, so I can't tell you how to avoid liability. I'm not even sure that this is possible absent legislation. I can, however, mention techniques that at this writing seem to me to be an essential part of any liability-reduction strategy, without any claim that these alone suffice to protect you to the level that I would want to be protected (I'm a cautious guy). Repeat: I do claim that pending further thought these steps seem necessary, **not** that they are sufficient: A) Establish a clear certification policy document, describing in detail what checks are made before issuing a certificate, how quickly CRLs are posted, and where. This doesn't mean onerous checks are necessary, just that you need to be clear as to what checking a certficiate from you emboidies. Publish this document. B) Reference this policy document in every certificate. C) Don't settle for less than X.509 ver 3, because this allows the certificate to carry within it a reference to the location of the CRL list. Use that feature. D) Establish a very reliable mechanism to ensure CRLs are posted where and when they should be. E) Use a secure, trusted, computer system. Again, I note that this is NOT a complete list of what you need to do. For more inspiration consult the ABA document referenced above. A. Michael Froomkin | +1 (305) 284-4285; +1 (305) 284-6506 (fax) Associate Professor of Law | U. Miami School of Law | froomkin@law.miami.edu P.O. Box 248087 | http://www.law.miami.edu/~froomkin Coral Gables, FL 33124 USA | It's warm here.

| C) Don't settle for less than X.509 ver 3, because this allows the | certificate to carry within it a reference to the location of the CRL | list. Use that feature.

Does X.509 version 3 fix the problem that Ross Anderson points out in his 'Robustness Principles' paper? (Crypto '95 proceedings, or ftp.cl.cam.ac.uk/users/rja14/robustness.ps.Z)

I don't believe that it does. For those who missed it, the problem is that the encryptor in an encrypt-before-signing protocol is able to use his knowledge of the factorization of the encryption modulus to compute a discrete log, and forge another message for which the signature is also valid (after registering the new exponent). - Mark - -- Mark Chen chen@intuit.com 415/329-6913 finger for PGP public key D4 99 54 2A 98 B1 48 0C CF 95 A5 B0 6E E0 1E 1D

Jeff Weinstein writes:

...

Is anyone running an ssl web server that would let us see how this works?

A little bird pointed me toward https://www.secret.org. I have no idea who they are... For those that want to know what's there without wasting their time 'upgrading' to netscape 2.x,etc.... There is (currently?) very little, the only thing interesting I found is that 'they' claim to give away free CA if you mail at <ca@secret.org> (their 'Project7'/'666 Crypto' route...)

Regards dl -- Laurent Demailly * http://hplyot.obspm.fr/~dl/ * Linux|PGP|Gnu|Tcl|... Freedom Prime#1: cent cinq mille cent cinq milliards cent cinq mille cent soixante sept Marxist SEAL Team 6 jihad break mururoa explosion smuggle

Alex Strasheim wrote:

...

Basicly when the browser finds a new CA that it does know about it promts the user and through a series of dialog boxes the user chooses to trust it or not.

Is anyone running an ssl web server that would let us see how this works?

A little bird pointed me toward https://www.secret.org. I have no idea who they are... --Jeff -- Jeff Weinstein - Electronic Munitions Specialist Netscape Communication Corporation jsw@netscape.com - http://home.netscape.com/people/jsw Any opinions expressed above are mine.

On Mon, 27 Nov 1995, Jyri Kaljundi wrote:

What software there is available (preferably non-commercial) to become a CA? Is for example the SSLeay package enough?

I'm just making a quick comment on this point. The current SSLeay setup, I would say no. You can do it but you need to write more stuff to do it correctly. It is a bit of an evil cludge. The next version should be able to do this (I hope, depending on time). The next version has (will have) several different ways to 'retrieve' certificates which can be added via an run time API (the application can 'push' new methods into the library during startup). I will probably not have time to put in a 'socket' based certificate server but it should be simple enough for this to be written by other people. It should also be simple enough for other people to write some routines that conform to the API so that the netscape DB files can be accessed by SSLeay (along with the current SSLeay 'hash directories' and the socket based lookup (if it gets put in)). The most importaint change is that I will support CRL if they are present and probably generate an 'warning' if there is no CRL. I still need to write a simple application to do a basic 'keep track of issued certificates' and generate a CRL if required. The library routines to write a CA are present, they just need to be glued to a simple database (which I will probably do in my demo case via ascii files in directories). This version will also hopefully support the concept of selecting a certificate/private key from a set of certificates, attempting to pick a certificate that is in the same 'tree' as another certificate. This concept of multiple certificates for a person is useful for SSLtelnet, so that each 'host domain' can issue it's own certificates (and keep track of it's own CRL). To let some-one login, just issue them with a 'certificate' for that 'host domain'. eric -- Eric Young | Signature removed since it was generating AARNet: eay@mincom.oz.au | more followups than the message contents :-)