Markku-Juhani Saarinen <[EMAIL PROTECTED]> writes:
>>I now believe you've decoded the below incorrectly because the leading
>>bit is set, making this a signed number which may have made some of your
>>tools croak. Decoding by hand, I get the following mod/exp:
>Are you saying that under some conditions Microsoft Outlook generates a x.509
>cert with a negative modulus that can only be docoded "correctly" with the
>other microsoft tools ?
MS implementations have got this wrong for as long as I can remember (it's been
pointed out to them, but they haven't fixed it). Here's a posting to the
openssl-dev list which covers this:
-- Snip --
AFAIK it's bugs in both. MS have always got the sign bit wrong in their
encoding, but it's not that much of a problem because all the vendors know this
(or just expect it from MS without even bothering to check :-) so they treat
ints as unsigned (actually there's nowhere in any cert-relevant code which uses
signed ints, I expect most implementations always treat them as unsigned). From
the OpenSSL side, it looks like it's doing something with the sign bit, so the
integer gets transformed into a completely different value. This may be due to
recent changes, ISTR that SSLeay always assumed the numbers were unsigned.
As for the size in bits, that's normal, you don't always get exactly what you
asked for (check your PGP keyring for examples).
-- Snip --
Peter.
