RE: More examples-05 issues

John,

After investigating your new 6.2 example I found that it has an
OriginatorInfo structure, and thus contradicting the draft description of
the example. The draft description is included below for reference:

----
6.2 Basic encrypted content, TripleDES and RSA

Same as 6.1, except with RSA for key management. An EnvelopedData from
Alice to Bob of ExContent using TripleDES for encrypting and RSA for
key management. Does not have a OriginatorInfo, and has unprotected
attributes."
----

Furthermore the OriginatorInfo contains DSS certificates & CRLs for Alice
and Carl. This is obvously of not much use since the example uses RSA for
key management.

In my opinion the 6.1 and 6.2 examples should not contain any optional
information fields since they are basic examples. They should just stick to
the basic requirements. If the unprotected attributes are also removed from
the example it would actually also be backwards compatible to the PKCS#7
spec. Do you agree with me John? This is just my personal opinion, but the
inconsistency with the OriginatorInfo field needs to be solved anyway.

Regards,
Magnus


-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of Pawling,
John
Sent: Wednesday, January 17, 2001 4:53 PM
To: 'Alexei Shamov'; [email protected]
Cc: Colestock, Robert
Subject: RE: More examples-05 issues


Alexei,

Thank you very much for your feedback. Getronics Government Solutions
generated the section 6.2, 6.9 and 6.10 sample messages included in the
"Examples of S/MIME Messages" I-D (Examples-05).  Please see my responses
in-line.  The rest of your comments should be addressed by Paul Hoffman.

===========================================
John Pawling, [email protected]
Getronics Government Solutions, LLC
===========================================

-----Original Message-----
From: Alexei Shamov [mailto:[email protected]]
Sent: Monday, January 15, 2001 8:41 AM
To: [email protected]
Subject: More examples-05 issues


Hi All,

Testing examples-05 document, I have found some more issues as follows:

1. I was unable to decrypt some Diffie-Hellman enveloped messages (6.2, 6.9,
6.10) with User Keying Material specified in KeyAgreeRecipientInfo.

[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).]


Firstly, ukm is 1024 bits long (128 bytes) octet string. Should not it be
512 bits (64 bytes) as specified in RFC 2631 / 2.1.2? (Ahmed Bhamjee has
already addressed this issue before).

[JSP: In the sample messages for sections 6.9 and 6.10, you are correct that
the size of partyAInfo contained in the OtherInfo sequence must be 512 bits
in size.  When Ahmed Bhamjee reported this error in the SFL (see attached
message), we corrected the bug in the SFL, but we forgot to re-generate the
sample messages for sections 6.9 and 6.10 including the incorrect partyAInfo
values.  We will generate corrected messages and provide them to the list as
soon as possible.]


Secondly, in examples 6.2, 6.9 when RC2 CEK was wrapped with 3DES KEK,  it
seems that Triple-DES key wrap algorithm (RFC2630/12.6.2) was used (only
128-bit plain CEK appears after decryption, not LENGTH || CEK || PAD).
Should not RC2 key wrap algorithm (RFC2630/12.6.4) be used?

[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.]


Example 6.10 failed at KeyCheck step of RC2 key unwrap. Perhaps this is a
problem of my implementation (some debug information is attached to the end
of this message).

[JSP: We will reply to this comment in a later message.]


4. In 6.2 and some other messages GeneralizedTime does not have century
specified, as per RFC 2459/4.1.2.5.2. Is it acceptable?

[JSP:  You are correct that GeneralizedTime must always specify the century.
When we re-generate the sample message for section 6.9, we will ensure that
the GeneralizedTime value is corrected.  Also, we will re-generate the
sample messages for section 6.11 to correct the GeneralizedTime value.  We
have already re-generated the sample message for section 11.5 to correct the
GeneralizedTime value (attached).  If you see any other incorrect
GeneralizedTimes, please let us know.  Please note that the X.509
certificates included in many of the sample messages (such as Section 6.2)
include UTCTimes which (correctly) do not specify the century. ]


01E1 A2   63:         [2] {
01E3 02    1:           INTEGER 4
01E6 30   22:           SEQUENCE {
01E8 04   11:             OCTET STRING 'MailListTripleDES'
01FB 18    D:             GeneralizedTime '951230235959Z'

Regards,
Alexei

P.S. Debug information for example 6.10

OtherInfo=
0000 30   A3: SEQUENCE {
0003 30   13:   SEQUENCE {
0005 06    B:     OBJECT IDENTIFIER
            :       id-alg-CMSRC2wrap (1 2 840 113549 1 9 16 3 7)
0012 04    4:     OCTET STRING
            :       00 00 00 01
            :     }
0018 A0   83:   [0] {
001B 04   80:     OCTET STRING
            :       17 2F 3B 6C DE 37 69 19 8A 7A 03 F2 DE A3 04 96
            :       7E 0A 8E 30 3F 76 C8 58 3A 95 B0 46 98 23 50 82
            :       DC 46 52 6E 7C 5E 60 1B 3E B5 DC 2D 2D B7 1A EC
            :       13 70 8A 7B 83 73 4D 17 BE 93 4B 58 BC 66 D1 8B
            :       42 95 A7 E2 F1 9A 5B 08 61 16 88 E4 C2 AC DD 1A
            :       79 0D 37 FF A8 E6 7A AC 91 79 2F 2A 33 E1 E9 52
            :       4F 18 AE 18 46 03 25 84 D1 13 E1 87 1B 48 80 74
            :       F3 33 23 68 1E CD 81 40 4A E9 83 02 2D 23 0B A2
            :     }
009E A2    6:   [2] {
00A0 04    4:     OCTET STRING
            :       00 00 00 80
            :     }
            :   }

ZZ =
c2 5e 2c 49 65 6b 8e 28 36 45 9a 5c 54 f4 ce 64
0d 97 cc 0e ce 40 f3 4e ff 6c 9f 9a c8 76 c7 38
02 48 ec 39 c5 6b e1 6d 0a 73 ac cb cc 25 4b 6b
b6 32 54 89 40 95 f7 64 06 99 d3 61 af 86 06 51
10 97 be 2a 2d 30 76 92 e6 26 8d 38 4b a6 7c cb
3c 68 4b f1 b4 44 6d 60 d3 b1 d7 13 4e 91 a1 96
48 c4 74 79 7e 1b 69 c5 43 52 11 cc b9 a0 93 4b
e3 21 30 de 7a 98 85 c2 40 1c f4 b5 1f 4d 41 f2

KEK=95 cf 08 a6 f9 5c 97 a9 18 ae 3b ee 26 67 71 6a