[xmlsec] xmlSecTransformRsaPkcs1

Aleksey Sanin aleksey@aleksey.com
Sun, 10 Aug 2003 17:44:54 -0700


> ...changing transforms engine itself seems like a big problem for me.

To be precise, the changes would look like this:
    0) Add a new pushKey/popKey methods to xmlSecTransformKlass (where
    are two "reserved" pointers thus it won't break ABI compatibility). 
Also add
    all the functions to support new "key" input type:  
          xmlSecTransformPushKey
          xmlSecTransformPopKey
          xmlSecTransformCtxExecuteKey
          ...

    1) Modify the code in transforms.c to deal with this new 
input/output type:  
          xmlSecTransformDefaultGetDataType
          xmlSecTransformCtxPrepare
          xmlSecTransformCtx*Execute
          xmlSecTransformPump
          ...
    In some of these functions you might need to transform keys to binary
    data if needed. I understand that NSS would not support this but it 
might
    be required in some cases it might be required. Thus, there should be
    code to do this (probably using xmlSecKeyDataBinWrite).
    BTW, there is a good question of how to pass around the information
    about the expected key id (decryption case). Probably somewhere in
    xmlSecKeyInfoCtx or xmlSecTransformCtx.

    2) Add new xmlSecEncCtxKeyEncrypt/xmlSecEncCtxKeyDecrypt to
    xmlenc.c

    3) Modify code in xmlSecKeyDataEncryptedKeyXmlRead and
    xmlSecKeyDataEncryptedKeyXmlWrite to use these new functions
    instead of xmlSecKeyDataBinWrite + xmlSecEncCtxBinaryEncrypt.

    4) Finaly, implement these new popKey/pushKey methods for RSA-PKCS
    transport for NSS. Of course this would mean that xmlsec-nss would not
    support RSA-PKCS for data encryption.

This does not look like these change would break API or ABI compatibility
(thanks to "reserved" items :) ). But this sounds like a significant 
change and
I would estimate the full patch with -u option to be around 3000-4000 lines.

Aleksey