Re: DSAKeyValue text

In-reply-to: Your message of "Fri, 08 Jun 2001 10:54:18 PDT."
             <BCDB2C3F59F5744EBE37C715D66E779CEAB702@red-msg-04.redmond.corp.microsoft.com>

I don't have any big problem adding "J" back in but it needs
explanation.  I went to the FIPS for DSA and, as far as I can recall,
the only J that I saw was in the primality test.

See the attached.

Thanks,
Donald

From:  "Brian LaMacchia" <bal@microsoft.com>
Date:  Fri, 8 Jun 2001 10:54:18 -0700
Message-ID:  <BCDB2C3F59F5744EBE37C715D66E779CEAB702@red-msg-04.redmond.corp.microsof
t.com>
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