- From: Dennis Glatting <dennis.glatting@plaintalk.bellevue.wa.us>
- Date: Fri, 7 Feb 97 10:16:53 -0800
- To: Rodney Thayer <rodney@sabletech.com>
- cc: ietf-tls@w3.org
> Sorry, I missed where we got the assertion that TLS requires a > CA. > > As I understand it TLS requires a ROOT CERTIFICATE and > CERTIFICATES. [Assuming the identity-based case, not the > anonymous case.] Implementations can do whatever they wish to > come up with the root certificate. I might deal with that by > configuring my implementation to use Thawte's root > certificate and use them as a CA. Someone else might set up a CA > for use inside a corporation or other organization. Someome > might even set things up to self-sign or deliver a signature > engine fairly widely. One can look at PGP as an example of this. > > I don't see that there is any technical REQUIREMENT in TLS that I > pay anyone to act as my certificate authority. I myself use it > that way sometimes but that's an implementation and > deployment detail, not a requirement of the protocol. > Deployment is what it is all about, isn't it? What good is a protocol if it can not be deployed? Certainly a company can set up its own root certificate, but what happens when their services access outside services? Does each an every service accessed by the company going to require their certificate or root certificate to be signed by the company? Perhaps the company may think so but that is unrealistic and unmanageable. What is realistic and manageable is a trusted CA. However, considering todays patchwork of CAs the problem is the same. It will be interesting to see the effect when a CA recertifies itself. Perhaps the bank vault where Thwate stores its private key is robbed or obtained by legal means and the key compromised (in the US the result of a discovery is often public). Probable. What then? At least with a CA infrastructure roots can be cross certified (as in the case of PGP) and CRLs published. -dpg
Received on Friday, 7 February 1997 13:17:05 UTC