214236 - Add PK11 wrapper to en/decryp data with CKM_RSA_PKCS mechanism

Status: NEW

(NSS :: Libraries, enhancement, P4)

Description

[Tej Arora]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
Build Identifier: 

PK11_PubEncryptRaw/PK11_PubDecryptRaw are the only PK11 wrappers available 
for RSA encryption/decryption. These functions hardcode the 
CKM_RSA_X_509 mechanism (no padding).

Need a way to do RSA encryption/decryption using the CKM_RSA_PKCS
mechanism (PKCS#1 v1.5 padding)

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

PK11_CipherOp and PK11_Finalize cannot be used for this purpose because they
use C_EncryptUpdate/C_DecryptUpdate and C_EncryptFinal.  The RSA mechanisms
require the use of C_Encrypt/C_Decrypt rather than the combination of
C_EncryptUpdate/C_DecryptUpdate and C_EncryptFinal.  (Note that this is also
true for the recently added AES Key Wrap mechanisms.) 

Historically, RSA encryption with PKCS 1 v1.5 padding has been used only 
for wrapping/unwrapping keys and for signature production and verification.   
NSS offers functions that will wrap and unwrap keys with the RSA mechanisms.  
It also offers functions for signing and signature verification.

So, the questions are:

a) is there any reason to disallow the use of RSA mechanisms with padding
for en/decrypting data other than keys?  (The concern is that people will
use it to encrypt key material that is not in a token).

b) what is the best way to do it?  Change PK11_CipherOp or add new functions?

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

According to http://bugzilla.gnome.org/show_bug.cgi?id=118628 the XML Sec
feature that needs the feature requested in this RFE is 
         RSA-PKCS 1.5 key transport 

Key transport means wrapping and unwrapping keys.  Key material should always
be on a token, and should be encrypted and decrypted using the PK11 functions
for wrapping and unwrapping, not the functions for encrypting and decrypting 
user data.  So, this RFE seems invalid.  

Comment 3

[Tej Arora]

The xml encryption spec does talk about the possibility of
encrypting raw data (see below). It does not require it, but
allows for the possibility.

5.4 Key Transport

Key Transport algorithms are public key encryption algorithms especially
specified for encrypting and decrypting keys. Their identifiers appear as
Algorithm attributes to EncryptionMethod elements that are children of
EncryptedKey. EncryptedKey is in turn the child of a ds:KeyInfo element. The
type of key being transported, that is to say the algorithm in which it is
planned to use the transported key, is given by the Algorithm attribute of the
EncryptionMethod child of the EncryptedData or EncryptedKey parent of this
ds:KeyInfo element.

(Key Transport algorithms may optionally be used to encrypt data in which case
they appear directly as the Algorithm attribute of an EncryptionMethod child of
an EncryptedData element. Because they use public key algorithms directly, Key
Transport algorithms are not efficient for the transport of any amounts of data
significantly larger than symmetric keys.)