CMC/CRMF: RSA key transport and PKCS #1

Excerpting from section 4.2 of cmc-01:

"Clients and servers 
SHOULD also be capable of producing and processing RSA key transport.  
When used for PKI messages, RSA key transport SHALL be indicated as 
specified in section 7.2.1 of PKIXCERT."

Here's a specific point, which may raise a broader issue.  Per the reference
in the last sentence, note that section 7.2.1 of part1-09 specifies means
for RSA signature, not for key transport.  If the same intent which that
section specifies for signatures, to apply padding and encoding conventions
per RFC-2313 (PKCS #1), applies for key transport as well, a vulnerability
announced earlier this summer may be relevant in this context.

When PKCS #1 padding is used for encryption in an interactive environment,
it's possible for an adaptive chosen ciphertext attack to extract the result
of a particular RSA/PKCS#1 encryption.  The attack requires that a large
number (e.g., 1,000,000) of queries be sent to a server acting as an oracle,
with the attacking client receiving and adapting to server responses which
reveal information about the results of attempted decryptions.
Countermeasures include alternate forms of padding and/or protocol
construction so that attackers cannot obtain information about the results
of decryption attempts. More information and analysis is available via
http://www.rsa.com/rsalabs/pkcs1/ and an Internet-Draft version of a
proposed successor to RFC-2313, addressing the vulnerability through revised
padding, on draft-kaliski-pkcs-pkcs1v2-00.txt.  

In terms of CMC, this vulnerability appears most relevant when PKCS #1 is
used to transport secrets from a requester to a responder.  This might,
e.g., arise when CMC transports a CRMF request for POP or archiving
involving encrypted transfer of a private key. 

--jl