[xmlsec] Big patch to xmlsec in recent OpenOffice.org sources

[Chandler Peng]

Aleksey ,

I find there is a different process in function 
xmlSecMSCryptoX509FindCert() between the lastest version and our patchs. 
When search a X509 certficate from cert store by the IssuerName and the 
SerialNumber ,  you will firstly retrieve some cert  by the IssuerName 
and then get the certain cert by compareing their SerialNumber . I doubt 
why not get the certain cert directly by the IssuerName and the 
SerialNumber?

In the lastest version :
    while((pCert = CertFindCertificateInStore(store,
                          PKCS_7_ASN_ENCODING | X509_ASN_ENCODING,
                          0,
                          CERT_FIND_ISSUER_NAME,
                          &cnb,
                          pCert)) != NULL) {
       
        /* I have no clue why at a sudden a swap is needed to
         * convert from lsb... This code is purely based upon
         * trial and error :( WK
         */
        if((pCert->pCertInfo != NULL) &&
           (pCert->pCertInfo->SerialNumber.pbData != NULL) &&
           (pCert->pCertInfo->SerialNumber.cbData > 0) &&
           (CertCompareIntegerBlob(&(pCert->pCertInfo->SerialNumber), 
&cib) == TRUE)
           ) {       
            break;
        }
    }
In our patch :
    pCert = CertFindCertificateInStore(
        store,
        X509_ASN_ENCODING | PKCS_7_ASN_ENCODING,
        0,
        CERT_FIND_SUBJECT_CERT,
        &certInfo,
        NULL
    ) ;

-- Chandler .

Andrew Fan wrote:

> Chandler Peng wrote:
>
>>
>>>> Chandler, I think it over about the 
>>>> xmlSecMSCryptoAppliedKeysMngrCreate(). You can replace the 
>>>> functions with another wrapper or block with:
>>>> {
>>>> /* create the key mngr */
>>>> xmlSecKeysMngrPtr keyMngr = xmlSecKeysMngrCreate() ;
>>>>
>>>> /* add key store to the mngr **/
>>>> xmlSecMSCryptoAppDefaultKeysMngrAdoptKeyStore*( keystore ) ;
>>>>
>>>> /* add cert store to the mngr **/**
>>>> xmlSecMSCryptoAppDefaultKeysMngrAdoptTrustedStore*( certstore ) ;
>>>> }
>>>
>>>
>>>
>>>
>>> This is not quite correct. As it is implemented in the OpenOffice
>>> patch you have sent to me, the xmlSecMSCryptoAppliedKeysMngrCreate
>>> function *did not* add keys or certs store passed into it as
>>> input parameters. But this might have just a bug :)
>>
>>
> Yes, :-) in fact, the current application still don't use this 
> feature, one reason for that is because I find no way to import them 
> into "xmlsecKeyStore". But I hope it should be as it supposed to be 
> while "xmlsecKeyDataStore" also make the it work in a different way. :-P
>
>>>
>> OK, I will replace the function xmlSecMSCryptoAppliedKeysMngrCreate() 
>> with a block like this:
>>   {
>> ( line 1 )   keyStore = xmlSecKeyStoreCreate( 
>> xmlSecMSCryptoKeysStoreId ) ;
>> ...
>> ( line 2 )   keyMngr = xmlSecKeysMngrCreate() ;
>>
>> ( line 3 )    xmlSecKeysMngrAdoptKeysStore( keyMngr, keyStore ) ;
>>
>> ( line 4 )   xmlSecMSCryptoKeysMngrInit( keyMngr );
>>
>> ( line 5 )   keyMngr->getKey = xmlSecKeysMngrGetKey ;
>> }
>>
> I think we're on that different way at some senses.  In your codes, 
> line 1, 3, 4, 5 have been wrapped by 
> *xmlSecMSCryptoAppDefaultKeysMngrInit( *xmlSecKeysMngrPtr ), it would 
> be saving call *xmlSecMSCryptoAppDefaultKeysMngrInit() after* 
> xmlSecKeysMngrCreate(). In my cases, "keystore" and "certstore" refer 
> to the input  parameters with xmlSecMSCryptoAppliedKeysMngrCreate( 
> HCERTSTORE keystore, HCERTSTORE certstore ). Personally, I would 
> suggest adding the two HCERTSTOREs into key manager.
>
> Thanks,
> -Andrew
>
>>>
>>>>> Note that all of the XXXKeyLoad functions you listed have no body at
>>>>> all in the patch that was sent to me thus I did not implement them
>>>>> in xmlsec. I can do it but I am not sure it makes much sense to me :)
>>>>>
>>>> The interfaces really give more flexible for end user specify their 
>>>> own keys for signature and decryption. I think is is much more 
>>>> useful for template driven signature/encryption, for non-template 
>>>> driven signature/encryption, one can directly call some interfaces 
>>>> to set the keys used to a certain sign/enc; but for template-auto 
>>>> driven, no one knows what even the template stuff, so put the  raw 
>>>> keys into the mgr is a good automated way. I think encryption cases 
>>>> will show the value of those interfaces. Because openoffice 
>>>> signature is based on pki cert, they really have not been used. I 
>>>> didn't implement those interfaces in mscrypto engine( I forgot why, 
>>>> because of time or anything else ), but they have been implemented 
>>>> in nss engine.
>>>>
>>>> Aleksey, I hope you add the interfaces for both mscrypto and nss 
>>>> engine if you feel valuable. :-)
>>>
>>>
>>>
>>>
>>> OK, I added mscrypto functions (changed names slightly to follow xmlsec
>>> conventions):
>>>
>>> xmlSecMSCryptoAppDefaultKeysMngrPrivateKeyLoad
>>> xmlSecMSCryptoAppDefaultKeysMngrPublicKeyLoad
>>> xmlSecMSCryptoAppDefaultKeysMngrSymKeyLoad
>>>
>>> But you promise to implement them one day :)
>>>
>>> BTW, just to repeat this to Chandler: to get full compatibility with
>>> current OpenOffice patch, one needs to compile xmlsec-mscrypto in "nt4"
>>> compatibility mode. Otherwise, you'll have same functionality but it
>>> will run only on 95/98 (with necessary SP level), Server 2003 and XP.
>>> You can find detailed instructions, reasons and more explanations here:
>>>
>>> http://www.aleksey.com/pipermail/xmlsec/2005/002560.html
>>>
>>> Also note that "nt4" compatibility mode *migth not* be thread safe.
>>>
>>> Aleksey
>>>
>> Thanks , I will test it in openoffice(src680m80) later .
>>
>> Chandler
>> _______________________________________________
>> 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