RE: More examples-05 issues

["Alexei Shamov" <shamov@xxxxxxx>]

Hi John,

Thank you for the update. Please find my comments below.

>[JSP: Section 6.2 contains a sample EnvelopedData using TripleDES for
>encrypting and RSA for key management, so I do not understand your above
>comment in relation to the section 6.2 sample.  There was a bug reported in
>the section 6.2 SFL-generated sample message (incorrect
>KeyTransRecipientInfo version value).  I have attached the message
reporting
>the bug and the corrected section 6.2 sample message (6.2.bin).]

I have problems with 6.2 because Base64 representation of 6.2 is the same as
of 6.9 in examples-05. Updated version is fine.

>[JSP:  Section 6.2 contains a sample EnvelopedData using TripleDES for
>encrypting and RSA for key management, so I do not understand your above
>comment in relation to the section 6.2 sample.   In the section 6.9 sample
>message, a 3DES KEK is used, so the Triple-DES key wrap algorithm is used.]

RFC 2630 does not explicitly define which algorithm should be used in mixed
cases, when RC2 CEK is wrapped with 3DES KEK.

However, 3DES key wrap can not be used in 6.9 because of the following:
1. 3DES unwrap algorithm MUST fail at 12.6.3.1 simply because ciphertext is
not 40 bytes long.
2. 3DES key parity adjustment/verification does not make sence for RC2 CEK.

I think that wrap algorithm should be selected according to CEK algoritm,
not KEK algorithm (ie RC2 key wrap (12.6.4) should be used with RC2 CEK,
and 3DES key wrap (12.6.2) with 3DES CEK).

Btw. in the KEKRecipientInfo of the same message rc2 key wrap was correcly
selected:

01E1 A2   63:         [2] {
01E3 02    1:           INTEGER 4
01E6 30   22:           SEQUENCE {
01E8 04   11:             OCTET STRING 'MailListTripleDES'
01FB 18    D:             GeneralizedTime '951230235959Z'
            :             }
020A 30   10:           SEQUENCE {
020C 06    B:             OBJECT IDENTIFIER
            :               id-alg-CMSRC2wrap (1 2 840 113549 1 9 16 3 7)
0219 02    1:             INTEGER 58
            :             }

Regards,
Alexei