On Sun, Nov 30, 2008 at 5:38 AM, Michael Ströder <[EMAIL PROTECTED]> wrote: >> Sure there's ultimate trust. > > I disagree. You are making trust decision only in a certain context. > > To avoid getting too philosophical a PKI-related example: You would trust > your employer to issue certs for encrypting corporate business-related > e-mails and even accept that the private keys are subject of key > recovery/escrow within the company's context. You would probably not want to > use these keys for personal communication exchanging intimate details of > your private life. > >> The problem is that there are as many >> points of ultimate trust as there are people. > > I'd argue that there even are many points of trust per person. ;-) > > But the trust model is not the main obstacle.
What I meant by "sure there's ultimate trust" -- each person has exactly one location to look for ensuring that the person's interests are protected, and that's the user him or herself. Each person looks at the context and the content, and decides whether it's okay or not. A person can choose not to be employed by a corporation that wants to use S/MIME and employee certificates. They can choose to be employed somewhere else. Thus, a person does have the ability to exercise that own judgement whether to accept culpability -- be it legal liability or corporate behavior for which one is called up on the carpet for not using the S/MIME tools provided. Every place that the point-of-ultimate-trust decides to place trust is "delegated trust". I call it this because it's entirely possible (in the event that one changes jobs, for example) that one does not have to trust the former job's CA. Now, if you turn it around and look at it from the corporation's viewpoint (since the corporation is a legal entity): its CA is where it places ultimate trust (since it's a CA that theoretically falls under the corporate policy, and the corporation must trust its own policy), which allows it to prove that it has delegated trust to someone to whom it has issued a token. This CA doesn't put all of its trust in any specific individual, it puts its trust in a role defined by its policy -- essentially, it evolved a body part to help it manage trust. The problem with having a single CA (which is probably fine for a corporation unless it's got many many arms) is that it allows one to express trust under only one policy. At this point, "signing a certificate" implies "the sole policy under which a CA can sign a certificate has been satisfied". As an example of an alternative: CA issues a CA certificate to an end entity, with the provision that the end entity will only use it to sign certificates to identify services that the end entity itself wants to create. (This is more for persons, not for webservers, obviously.) User decides to run a peer-to-peer networking system that uses certificates, decides to run a webserver, and decides to open a couple more network ports. Instead of having these ports be unencrypted, he uses his certificate to sign new certificates for the services that the user -- as a sovereign -- has allowed to delegate trust from his credential. Each of these certificates includes the name of the machine, the port it's running on, and the protocol that any client is expected to speak to it (and -- possibly, though I don't like it, due to notebooks traversing network boundaries and thus getting new IPs -- the IP that it's listening on). These are different from "proxy certificates", in that they don't try to state that the user has authorized a third party to operate on his behalf and charge his account. These are much more akin to the "end entity" certificates which are used to identify websites at this time. This means that the issuing certificate must have a CA:true and a depth limit of at least 1 -- which is something which is never done by any of the current CAs. Even though they'd be able to point precisely where any issue started, and act to revoke that certificate if it's being abused. (Really, we should be encouraging end entities to manage their own certificates like CA certificates, generating sub-EE CAs for date ranges and using those. We have the software to do it (or at least the CAs do), now all we need is to change the overarching current paradigm to allow for it.) Not that I expect anyone to do this, I'm just trying to give examples of alternative worldviews which could lead to wider adoption of certificates. -Kyle H _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
