From: Ted Lemon <[email protected]> >I think you've slightly misrepresented PHB's modification—what he said was >that you would keep the public/private keypair per >site on the key server, >but the keys you use to authenticate to the site would be private keys. This >saves having to generate >multiple public/private key pairs per site, and >works fine as long as you have repudiation.
But can this authentication be performed using TLS as it currently exists? That was my concern. >Two additional things that have occurred to me since we had this conversation: >- Repudiation can be done by having any device contact the key server and >repudiate any key, after having gotten the repudiation message signed by the >key server using the private key associated with that site; this avoids the >privacy issue of revealing the key server's IP address, but requires that the >site actually implement the repudiation protocol; if they don't, you're SOL. >One could also have a distributed repudiation model, but I don't think it adds >anything. And even with online repudiation, it's up to the site to check >that the key hasn't been repudiated, so no matter what, you are relying on the >site to do repudiation correctly. The good news is that it's easy to test >whether they are doing it, and indeed that could be written into the protocol. >- One use case for this is, e.g., if you have a financial manager who needs >access to some of your accounts in order to make trades on your behalf, and >you want to give them a key, but you'd like to be able to revoke the key. No >change to the proposed protocol is required—it's simply another case where >this security model would win massively. Sounds good to me. Iain. _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
