continuity of identity
trevp at trevp.net
Wed Sep 28 07:37:11 EDT 2005
John Denker wrote:
> For starters, let me suggest that rather than having a self-signed
> certificate of the type created more-or-less automatically when
> you set up your Apache server or set up your SSH daemon, it makes
> more sense to set up your own CA and issue your own certs from
> there. In some sense this is just a different type of self-signing,
> but it adds a possibly useful layer of indirection.
Conceptually, this self-managed layer of indirection is similar to
things like PGP master keys / subkeys, X.509 Proxy Certificates , and
proposals such as httpsy YURLs  and cryptoIDs .
> This scheme is in some sense doable already, since modern browsers
> have a way of importing new CA keys under user control. If you
> can persuade a user to go through those steps you're all set.
Browsers would need to be modified for this. I don't think you want to
encourage users to import CA certs into current browsers, since those
certs will usually become trusted for all domains. So you'd need
something like a known_hosts file to bind the imported certificates to
domain names. Adding this with a good UI to mainstream browsers seems
like the biggest challenge (sending a CA cert during the SSL handshake
> Comments, anyone?
One pragmatic issue is that it would be nice if you could form
"continuity of identity" bindings to existing 3rd-party-managed
identities as well as self-managed identities. If the client records an
identity as something like (CA cert, domain name), then this identity
would remain stable across end-entity key and cert changes regardless of
whether the CA cert is self-managed or belongs to Verisign. Tyler
Close's Petname Toolbar  is an excellent implementation of this concept.
Moving from pragmatics to, I guess, "theory": Once you have a layer of
indirection between an entity's public identity and the subkey(s) it
uses in protocols, there's a lot of features you could add.
A simple layer of indirection would be a master key that can sign
(subkey, expiration time) certificates. But you could achieve more
security and flexibility in managing keys with things like:
- Allow the master key to delegate revalidation/revocation of
subkeys to other authorities, so compromised subkeys could be quickly
disabled without involving the master key.
- Allow the public identity to be a combination of a public master
key and a user identifier (as above) so that a single master key could
support different identities (for example, multiple users might choose a
trustworthy 3rd-party to host their identity).
- Allow subkeys to sign other subkeys, to allow more flexible
- Allow subkeys to be granted limited privileges for use in
- Allow SPKI-like threshold subjects, for greater resilience.
It's interesting that all these techniques developed for other PKIs
could be applied for the purpose of making a single "crypto identity"
more secure and flexible.
It's also interesting that such an identity is not just useful for a
"leap-of-faith" / key continuity model, but could be used with any other
PKI model (web of trust, authorization certs, name certs, etc.) - you
could include the identity information or its hash in a certificate, or
manually exchange it.
One could argue that this gives a nice architecture: The PKI or other
infrastructure would be responsible for distributing and attesting to
bindings between crypto identities and real-world names, authorizations,
etc. Then, users would be responsible for the key management tasks
relating to security and stability of their identities.
 RFC 3820
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
More information about the cryptography