Ok, the title doesn't really say much, sorry for that - but I really couldn't think about any good, short, precise phrasing for this ... idea.
Let me allow you a peek into the thinking process behind it all.
Since I heard about the Yubikey on Security Now, I was thinking about its applications and possibilities - I recently got one myself, otherwise I couldn't post this, of course. It occurred to me, that there is one possible promlem with the architecture. One Key can only authenticate itself against one server - now, this relation is fine because then, the single server always knows the state of my key and can therefore examine the submitted OTPs more precisely.
Now picture this: you already have a yubikey for your OpenID account and similar stuff (like this forum and the wiki) so basically, this key authenticates against Yubico. Now another party comes along, which implemented the yubikey but does not want to rely on Yubicos server for whatever reason. In the current situation, you'll have to get a second Yubikey from this new party to authenticate against their server. So you might end up with the same problem, that all the other "type in this number"-OTP-tokens have - you get a bunch of them for different accounts.
Now, the solution to this problem would be, that the database entries from Yubico (public ID, secret ID and AES chiffre) have to be transferred to the other party - so that one key can authenticate to two different servers without communication between them. The new problem would of course be, that neither server would know the exact state of the Yubikey and thus some information from the OTP gets less valuable. But you would gain a little bit more redundancy.
Technically, this transfer would be quite easy. You give an OTP to the new server, which asks Yubico to authenticate it. Then the new server has to ask the Yubico server to send its database entries, establish an SSL connection between them, have the user give the Yubico server a consecutive OTP to the first one to verify the transfer and if all goes well, have the Yubico server submit the entry to the key through an SSL connection to the new server. (I hope this explanation isn't too confusing
)One advantage of this procedure is, that the key and the secret informations are never in the same place, which could eventually destroy all cryptographic security.
If you need a nice and flashy example of this, think about PayPal or Blizzard (World of Warcraft login) - they don't support OpenID and they probably never will, but they might consider implementing the Yubikey. But why have them send you another one if you already have one?
What do you think about it?
A small colored sticker will help me figure out which end to insert!
