On Wed, Feb 1, 2012 at 12:28 AM, Jon Callas <[email protected]> wrote:
You might trust your mother, but do you trust your mother to set up your VPN?
Finally, someone talking some sense.
And keys are just labels. I'm enough of an SPKI revanchist to say that keys are just names or labels. You can no more determine trustworthiness from a mere name than you can tell a book by its cover. To talk about trust, let alone trust*worththiness*, you're talking reputation.
Keys, or values derived from keys, are the only identities the computer can really comprehend. Everything else, including certifications, is simply metadata. Certifications are statements of reputation. Reputation doesn't exist because we need to identify others, identifiers exist because we need reputation. Identity certificates are convenient indexes into records, but we don't actually need them to contain everything that they contain. All they really need to contain is a statement that the CA knows who enrolled the key, which is basically what an otherwise-unidentified certification is in any case. Using the same key across multiple places may not seem to be something which has turned out to be a problem in practice, in that TLS sites use the same keys across every client. However, it's a major reason why client-side authentication isn't accepted by the individual consumer. The threat is that businesses will do anything to make a buck, so we must assume that they will be willing (no matter what they say their privacy policies are, because statistically at least one of them is lying) to perform back-end database matching. This means that we can't rely on a single certified public key. We can't even rely on knowing ahead of time how many keys we need to enroll. We can't accept constant DNs. We can't accept static keys. We can't accept static certifications. As a result, we need certifications to be API-enrollable. The API must allow the user to able to specify what aspects of his certified identity are placed into the certificate. Certifications should be a marginal cost item (a penny or two), because there is something of a queue for the certifier token service. They should not be free, but they shouldn't be expensive either. We should focus on providing as many chains of authority as are necessary to ensure security. Perhaps enroll new keys using both a personal enrollment key and a device enrollment key, so that it's possible to identify which device was compromised? -Kyle H
Verify This Message with Penango.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
