[xmlsec] xmlSecTransformRsaPkcs1

[Andrew Fan]

Hi,

I forgot adding a note. As I know, some crypto devices keep some 
symmetric key quite secretly, it's not permitted to export any plaintext 
material, and the key wrap method also depend on the crypto device, only 
the same crypto device or the same type device can unwrap the wraped 
keys. I think this is another support for Tej's.

In general, session keys are not so strictly limited.

Andrew


Andrew Fan wrote:

> Hi Tej,
>
> I think in XML Encryption recommendation, we can regard a symmetric 
> key and non-key data as a raw symmetric key in the process of key 
> transport( RSA-PKCS1), they ship the same standards. After the wrap or 
> unwrap process, the application will determine it is a key or non-key.
>
> About the key type problems, I find a quite interesting example in 
> lines 115 of  lib/crmf/cmmfchal.c, which use a "trick" mechanism. 
> Surely, it work, I think, because CRMF is a so general standards. So 
> in my patches, I also use a "trick" mechanism when importing symmetric 
> key from a raw key or non-key data. It work.
>
> Hope help,
> Andrew
>
> Tej Arora wrote:
>
>> This transform is supposed to encrypt a symmetric key using RSA.
>> The key to be encrypted is expected to be in cleartext in the
>> input buffer.
>>
>> Under some crypto systems like NSS, any keys in cleartext is frowned
>> upon. In practice, raw keys reside only in crypto tokens, and when
>> they leave the token they're always encrypted.
>>
>>  Encryption of key data is called "wrapping" and that of non-key data
>> is just called "encryption".
>>
>> NSS provides these forms of RSA encryption:
>> 1) WRAP a key using RSA. The key must be on some token. If it
>> is not on a token, the app must first get it on the token. It is 
>> possible
>> to get a cleartext key onto a token.  To do that one has to know the
>> key type. The implementation of xmlSecTransformRsaPkcs1 is
>> such that this information is not available to the transform. XML ENC
>> spec actually specifies that information in the schema.
>> 2) Encrypt non-key data using RSA (no support for padding)
>>
>> The bottom line is that the only way to make the RsaPkcs1 transform
>> work for NSS is to implement (2) with padding support. The NSS
>> team however has strong objections to encrypting cleartext keys
>> in the first place.
>>
>> So, I'm writing to ask if you can add a new RSA PKCS1 transform
>> whose input is a key reference (not the raw key) and the output is the
>> wrapped key.  I understand that xmlsec tests will still load raw keys
>> from files, but with the new transform - we'll atleast be able to 
>> support
>> a secure mode of operation that can be used by NSS based deployments.
>>
>>
>> thanks,
>>
>> -Tej
>>
>> _______________________________________________ xmlsec mailing list 
>> xmlsec@aleksey.com http://www.aleksey.com/mailman/listinfo/xmlsec 
>
>
>
>
> _______________________________________________
> xmlsec mailing list
> xmlsec@aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec