continuity of identity
Trevor Perrin
trevp at trevp.net
Wed Sep 28 07:37:11 EDT 2005
Hi John,
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 [1], and
proposals such as httpsy YURLs [2] and cryptoIDs [3].
[...]
> 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
is easy).
[...]
> 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 [4] 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
architectures.
- Allow subkeys to be granted limited privileges for use in
different protocols.
- 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.
Trevor
[1] RFC 3820
[2] http://www.waterken.com/dev/YURL/
[3] http://trevp.net/cryptoID/
[4] http://www.waterken.com/user/PetnameTool/
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
More information about the cryptography
mailing list