continuity of identity

[Trevor Perrin]

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