distributed identity for the cert-centric

[Johannes Ernst]

Let me take a stab at this ...

On Feb 2, 2006, at 13:17, Jens Alfke wrote:

> I've been talking with some people at work about YADIS, OpenID,  
> LID, etc. Some people come at "identity" from a more traditional  
> PKI mindset: they want to have a certificate to represent an  
> identity, use the public key in that cert for authentication, and  
> use a certificate-revocation-list protocol to periodically check  
> its validity.
>
> This is somewhat different from the approach taken by LID and,  
> especially, OpenID. I'm wondering how to bridge this. I'm by no  
> means an expert at security, crypto or distributed-identity, but  
> that won't stop me from offering some ideas. Stop me if I go off  
> into the weeds:
>
> 0. (I'm using LID in this example because I know it uses key-pairs  
> and is pretty extensible. As far as I know, OpenID is keyless and  
> is aimed more specifically at web-based single-sign-on.)
> 1. A LID identity server already generates a key-pair and uses  
> signatures to respond to identity challenges.
> 2. The key-pair can easily be wrapped in a self-signed X.509 cert.

Or, somebody else can sign it. There is no reason why, say, the  
government of Transsylvania couldn't make a law that all private/ 
public key pairs used for URL-based identity must be signed first by  
that government before the Transsylvanians are allowed to use them.  
(Not that I'd like that idea, but technically there is no reason why  
not.)

Or that Relying Party X (say, the tax authorities) may decide it only  
accepts certificates issued by the immigration authorities to sign- 
on, but not self-signed certs or plain public keys.

> 3. The cert can include a signed copy of the identity URL it's  
> associated with.
> 4. There can be (or perhaps already is) a LID profile to fetch such  
> a cert.
>
> Given that, the mechanism for verifying such a cert (if you didn't  
> get it directly from the identity URL) would be to extract its URL,  
> use the LID protocol to fetch the current cert from that URL, and  
> compare the key. And rather than checking a revocation list, you  
> just periodically repeat that process. (The cert can be given a  
> short expiration time, to enforce this.)

There is a use case about somebody taking over what used to be your  
identity URL (e.g. you forget to pay your ISP, and by the time you  
noticed, somebody else got your username). There are two ways of  
dealing with this:
  - use a revocation list. The downside is that it introduces a third  
party (the maintainer of that list) into the problem whose  
trustworthiness, in a decentralized system like OpenID and LID and  
YADIS, is unclear. (this could be fixed, but even if it is, it adds  
complexity)
  - assume the ISP deleted all your data (including your key pair)  
before giving your URL to somebody else, use a key "migration" protocol.

> In other words, to revoke your identity cert if your private key is  
> compromised, you just have your LID server generate a new key-pair.  
> A nice side effect is that as the holders of the old cert re-verify  
> it, they end up with a copy of the new, valid one.
>
> A simple protocol like this might make it feasible to write a plug- 
> in that would add distributed-identity support to traditional cert- 
> based security implementations, not to mention making URL-centric  
> distributed identity more understandable and approachable by those  
> used to more traditional security mechanisms.
>
> Does this seem reasonable?

Absolutely. There are certainly  stakeholders and scenarios where a  
hierarchical trust model is appopriate. One of the nice things about  
a decentralized system is that you can always very easily turn it  
into a centralized system, while the reverse is generally not true.

So far, we have only defined how to use gpg keys in LID, but the "lid- 
credtype" parameter is an enum, so it's easy to plug in things like  
RSA certs if people wanted to do that....

>
> --Jens

Johannes Ernst
NetMesh Inc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lid.gif
Type: image/gif
Size: 973 bytes
Desc: not available
Url : http://lists.danga.com/pipermail/yadis/attachments/20060202/7eb0a6eb/lid.gif
-------------- next part --------------
  http://netmesh.info/jernst