- From: Brian LaMacchia <bal@microsoft.com>
- Date: Fri, 8 Jun 2001 10:54:18 -0700
- To: "Donald E Eastlake 3rd" <dee3@torque.pothole.com>
- Cc: <w3c-ietf-xmldsig@w3.org>
Hi Don, I think there's some confusion about the meaning of the optional parameter J. In my implementation (which is based off what the MS CryptoAPI library produces), J is (P-1)/Q, not the internal counter from the DSA FIPS key-generation algorithm. I believe this was the original intent of including a J in the structure. I asked Jim Schaad if he knew why J was optionally explicitly called out since it could always be computed from the other parameters and he said it was for performance reasons -- bignum multiplication being faster than bignum division -- for validating that the group parameters are properly constructed. (For DH J is typically small and probably more important, but with DSA its going to be large because Q is limited to 160 bits. CryptoAPI also includes J for DH public key blobs, presumably for this exact reason.) Obviously I would prefer that J, defined as P-1/Q, remain as an optional component of the structure, since I currently emit it when creating DSAKeyValue elements :-) --bal -----Original Message----- From: Donald E Eastlake 3rd [mailto:dee3@torque.pothole.com] Sent: Wednesday, June 06, 2001 12:08 PM To: w3c-ietf-xmldsig@w3.org Subject: DSAKeyValue text I propose the attached text for the DSAKeyValue section. I have tried to be compatible with the existing material, so that at least any existing DSA key would conform to the newer syntax. However, I really couldn't figure out why the optional J parameter had been included. As far as I can tell from the FIPS, it's just an internal parameter in the suggested primality test algorithm and there is no reson to preserve it. It was optional before and I'd be interested to hear if anyone was actually generation DSAKeyValue elements with a J child element. Thanks, Donald
Received on Friday, 8 June 2001 14:47:54 UTC