[xmlsec] Problem with some cert which has a negative serial number

[Michael Mi]

Hi,

What I suggest is to add minus sign to the string format (no matter what 
base it is) when a bn is negative. When creating bn from this string, 
the minus sign can be used to help converting back to the original bn.

Anyway, I just hope any bn in string format is only used in purpose of 
displaying, otherwise, the minus sign may cause some problem.

Moreover, I also think the leading zero prefix should be reserved 
converting between bn and string. For instance, when converting a bn 
"01" to a string, the result should be "01", instead of "1". Only in 
this way, when converting back to a bn, the leading zero can be recoveredd.

Michael

Aleksey Sanin wrote:

> OK, let me think about this. It should be possible to fix but
> I need to figure out the simeplest way of doing this.
>
> Aleksey
>
> Chandler Peng wrote:
>
>> Aleksey Sanin wrote:
>>
>>> OK, I see it now. However, I am not sure I understand how to fix
>>> your problem w/o breaking Michael's code because it seems that
>>> in his case "B2 ..." is *always* a positive integer. I am coping
>>> this email to Michael too get his opinion.
>>>
>>> Meantime, it would be great if you can try to parse your certificate
>>> with openssl and check if it would consider this number negative or
>>> positive.
>>
>>
>>
>> I have checked the cert in openssl.0.9.4 and get the result list 
>> below using the command "openssl asn1parse -inform DER -in c:\10.cer".
>> The serial number in cert is "80E3EDD4CCCA58A846A9D734E3C3D90B", the 
>> result parsed by openssl is "-7F1C122B3335A757B95628CB1C3C26F5".
>> I attached the certificate for you analysis.
>>
>>    0:d=0  hl=4 l= 502 cons: SEQUENCE
>>    4:d=1  hl=4 l= 351 cons: SEQUENCE
>>    8:d=2  hl=2 l=   3 cons: cont [ 0 ]
>>   10:d=3  hl=2 l=   1 prim: INTEGER           :02
>>   13:d=2  hl=2 l=  16 prim: INTEGER           
>> :-7F1C122B3335A757B95628CB1C3C26F5
>>   31:d=2  hl=2 l=  13 cons: SEQUENCE
>>   33:d=3  hl=2 l=   9 prim: OBJECT            :md5WithRSAEncryption
>>   44:d=3  hl=2 l=   0 prim: NULL
>>   46:d=2  hl=2 l=  13 cons: SEQUENCE
>>   48:d=3  hl=2 l=  11 cons: SET
>>   50:d=4  hl=2 l=   9 cons: SEQUENCE
>>   52:d=5  hl=2 l=   3 prim: OBJECT            :commonName
>>    ..........
>>
>> Thanks,
>> Chandler
>>
>>>
>>> Aleksey
>>>
>>>
>>> Chandler Peng wrote:
>>>
>>>> Dear Aleksey ,
>>>>  
>>>> That bug  you refer to resolved a  problem how to transfer a 
>>>> positive decimal string to a positive integer . For example , there 
>>>> is a serial number "00 B2 2F 00 00 /00 02 20 73 3B 25 34 C4 42 6F"/ 
>>>> in the certificate , the serial number is a positive integer for 
>>>> the first byte is 0x00(the first bit is 0) . The libxmlsec will 
>>>> transfer the SN to "/3613992633088206991095317234205295" /in 
>>>> decimal format and transfer back to /"B2 2F 00 00 00 02 20 73 3B 25 
>>>> 34 C4 42 6F" /in der format . That is a bug for the integer "00 B2 
>>>> 2F 00 00 /00 02 20 73 3B 25 34 C4 42 6F" is not equal to /the 
>>>> integer  "B2 2F 00 00 /00 02 20 73 3B 25 34 C4 42 6F". /That bug 
>>>> has been fixed in CVS./
>>>>
>>>> /This bug we reported is different with that bug.
>>>> For example , if there is a serial number "B2 2F 00 00 /00 02 20 73 
>>>> 3B 25 34 C4 42 6F"/ in the certificate , the serial number is a 
>>>> negative integer for the first byte is 0xB2(the first bit is 1) . 
>>>> The libxmlsec will transfer the SN to 
>>>> "/3613992633088206991095317234205295" /in decimal format and 
>>>> transfer back to /"00 B2 2F 00 00 00 02 20 73 3B 25 34 C4 42 6F" 
>>>> /in der format . This is a bug for "B2 2F 00 00 /00 02 20 73 3B 25 
>>>> 34 C4 42 6F" /is a  negative integer and 
>>>> "/3613992633088206991095317234205295"/ is a positive decimal format 
>>>> string. They are not equal.
>>>>
>>>> It seem that there should be a flag in decimal format to 
>>>> distinguish whether the decimal string is positive or not , does'nt 
>>>> it?
>>>>
>>>> --Chandler
>>>>  
>>>> Aleksey Sanin wrote:
>>>>
>>>>> I guess you are using xmlsec-mscrypto library and if this is
>>>>> the case then I believe that this bug was already fixed in CVS:
>>>>>
>>>>> http://www.aleksey.com/pipermail/xmlsec/2005/002487.html
>>>>>
>>>>> It would be great if you can try the CVS version and report if your
>>>>> problem still exists.
>>>>>
>>>>> Thanks,
>>>>> Aleksey
>>>>> _______________________________________________
>>>>> xmlsec mailing list
>>>>> xmlsec at aleksey.com
>>>>> http://www.aleksey.com/mailman/listinfo/xmlsec
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------ 
>>>>
>>>>
>>>> _______________________________________________
>>>> xmlsec mailing list
>>>> xmlsec at aleksey.com
>>>> http://www.aleksey.com/mailman/listinfo/xmlsec
>>>
>>>
>>>
>>> _______________________________________________
>>> xmlsec mailing list
>>> xmlsec at aleksey.com
>>> http://www.aleksey.com/mailman/listinfo/xmlsec
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> xmlsec mailing list
>> xmlsec at aleksey.com
>> http://www.aleksey.com/mailman/listinfo/xmlsec
>
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec