[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