...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
_______________________________________________ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
