- From: Erwin vanderKoogh <vdkoogh@mediaport.org>
- Date: Thu, 24 May 2001 13:17:25 +0100
- To: "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
- CC: Erwin van der Koogh - Sun Ireland - Software developer <Erwin.Vanderkoogh@Sun.COM>, w3c-ietf-xmldsig@w3.org, eve.maler@east.sun.com, rags@Sun.COM, lde008@dma.isg.mot.com
> I spoke (or rather wrote) too soon. The J, seed, and pgenCounter have > to do with the NIST recommended way to generate p and q so you can be > confident someone hasn't handed you weak p and q. This needs to be > documented better in the spec. I don't see why this has anything to do with it. The goal is to pass around the value of an existing DSA key. Not with passing around information on how that key was generated. What are you going to use the other parameters for anyway? check that the p and q were really generated with these values? You might just as well check to see if p and q are weak :) You have to make a trust decision on whether to trust this key and signature anyway. Trusting someone to use a decent p and q is part of this process. In fact it's so easy to choose a decent p and q (By choosing a strong Sophie-German prime) I don't see any reason to include a J, seed and pgenCounter (especially because this might reveal more than just this key, but also how other keys (or maybe even the private key) were generated. About my other question about more explanation: All I was asking for is 1 line in the description of KeyInfo that says that keys passed this way are still subject to trust decision covered in paragraph $blah.blah. Regards, Erwin van der Koogh
Received on Thursday, 24 May 2001 08:16:12 UTC