Re: [Keyrings] Re: [PATCH 01/04] Add multi-precision-integer maths library

[Trond Myklebust <trond.myklebust@fys.uio.no>]

On Sun, 2006-01-29 at 17:54 -0500, Kyle Moffett wrote:
> You keep mentioning proxy certificates.  So you are saying that when  
> I pass the key to some daemon to which I do not want it to have  
> permanent access, I should create a proxy certificate to pass  
> instead?  This _vastly_ increases the amount of math that needs to be  
> done.  Instead of just using my private key to encrypt data, I would  
> need to generate a new private key with the required encryption  
> strength, generate a proxy certificate, sign the proxy certificate  
> with the old private key, keep track of revocation lists somehow (how  
> do I reliably expire a proxy certificate on-demand everywhere it  
> might be without a web-server hosting the CRLs?), _then_ I can  
> finally encrypt my data with the proxy certificate.  I think this  
> qualifies as a serious performance problem, especially if I'm opening  
> and closing lots of SSH tunnels, like running remote commands on  
> every system in a cluster.

Feel free to profile it. I challenge you to find a real-life application
where the above is actually a performance problem.

> If we use this proposed in-kernel system, then I can give my  
> certificate/pubkey to the kernel code, and then my web browser, SSH,  
> and anything else can automatically use it to decrypt and sign data  
> without being able to directly access (and thus compromise) the key.   
> If I later notice what I think might be a rogue process, I can  
> instantly and globally revoke all access to that keypair.

The latter is something you can do with keyrings anyway. As for the
former, that too is completely solvable in userspace. For instance, CITI
has a scheme for issuing X509 proxy certificates given a kerberos key.
ssh can log you in automatically given the same kerberos key,...

This sort of problem is simply not a reason for sticking dsa into the
kernel.

Cheers,
  Trond