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, John.Pawling@xxxxxxxxxxxxxxxx
Getronics Government Solutions, LLC
===========================================
-----Original Message-----
From: Alexei Shamov [mailto:shamov@xxxxxxx]
Sent: Monday, January 15, 2001 8:41 AM
To: ietf-smime-examples@xxxxxxx
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
--- Begin Message ---
- To: "'imc-sfl@xxxxxxx'" <imc-sfl@xxxxxxx>
- Subject: More UKM size in the SMIME Freeware Library v1.8
- From: "Pawling, John" <John.Pawling@xxxxxxxxxxxxxxxx>
- Date: Tue, 12 Dec 2000 13:55:18 -0500
All, Please note the additional change required to implement this fix. =========================================== John Pawling, John.Pawling@xxxxxxxxxxxxxxxx Getronics Government Solutions, LLC =========================================== -----Original Message----- From: Colestock, Robert To: 'Ahmed Bhamjee ' Cc: Pawling, John Sent: 12/12/2000 1:51 PM Subject: FW: UKM size in the SMIME Freeware Library v1.8 Ahmed: Since the 512 is a bit count, you must also modify the source in sm_free3.cpp to divide by 8 for the random number call. It ends up our old value used 1024 bits (the parameter to the SMTI_Random(...) routine takes a byte count). in ./alg_libs/sm_free3/sm_free3.cpp ... SME(SMTI_Random(NULL, pUKM, SM_FREE_RA_SIZE/8)); ... Bob Colestock VDA. -----Original Message----- From: Colestock, Robert Sent: Tuesday, December 12, 2000 12:41 PM To: 'imc-cml@xxxxxxx'; 'Ahmed Bhamjee ' Subject: RE: UKM size in the SMIME Freeware Library v1.8 Ahmed: You are absolutely correct. I had to dig up the rfc2631 specification for DH to determine the actual UserKeyMaterial size. 128 byte length works fine, but is not correct to the specification. Thank you for pointing this out. If you wish to change your copy, simply update the variable "SM_FREE_RA_SIZE" in ./alg_libs/sm_free3/sm_free3.h from 128 to 512 and re-build. Our next release will have the updated size. This has been tested on ESDH operations and now produces the appropriate sized PartyAInfo structures (only used for the wrap hash). Thank you Bob Colestock VDA. -----Original Message----- From: Ahmed Bhamjee To: ietf-smime@xxxxxxx Sent: 12/12/2000 6:18 AM Subject: UKM size in the SMIME Freeware Library v1.8 I have been testing our product with the latest SFL version. More specifically, I have performed tests using the Diffie-Hellman key agreement method. From the RFC (2631), the size of partyAInfo contained in the OtherInfo sequence must be 512 bits in size. However, the SFL produces keying material with partyAInfo set to 128 bytes. Should this not be 64 bytes? Perhaps I am missing something. Thanks Ahmed
--- End Message ---
--- Begin Message ---
- To: "'magnus.svensson@xxxxxxxxxxxxx'" <magnus.svensson@xxxxxxxxxxxxx>, "'Paul Hoffman (E-mail)'" <phoffman@xxxxxxx>
- Subject: RE: Issues with draft-ietf-smime-examples-05
- From: "Pawling, John" <John.Pawling@xxxxxxxxxxxxxxxx>
- Date: Thu, 11 Jan 2001 15:03:56 -0500
Magnus and Paul, Attached is the corrected section 6.2 sample message (includes KeyTransRecipientInfo version set to 0). We fixed the bug in the SFL that caused this problem. =========================================== John Pawling, John.Pawling@xxxxxxxxxxxxxxxx Getronics Government Solutions, LLC =========================================== -----Original Message----- From: Pawling, John [mailto:John.Pawling@xxxxxxxxxxxxxxxx] Sent: Thursday, January 11, 2001 1:30 PM To: 'magnus.svensson@xxxxxxxxxxxxx'; ietf-smime-examples@xxxxxxx Subject: RE: Issues with draft-ietf-smime-examples-05 Magnus, Getronics Government Solutions generated the section 6.2 sample message included in the "Examples of S/MIME Messages" I-D (Examples-05). We agree that the section 6.2 sample message KeyTransRecipientInfo version number should be 0 (rather than 2) since the RecipientIdentifier is of the IssuerAndSerialnumber choice. We will generate a new message with a corrected version number for inclusion in the next version of the Examples I-D. The rest of your comments should be addressed by Paul Hoffman. =========================================== John Pawling, John.Pawling@xxxxxxxxxxxxxxxx Getronics Government Solutions, LLC =========================================== -----Original Message----- From: Magnus Svensson [mailto:magnus@xxxxxxxxxxxx] Sent: Thursday, January 11, 2001 11:30 AM To: ietf-smime-examples@xxxxxxx Subject: Issues with draft-ietf-smime-examples-05 When working with IETF's draft-ietf-smime-examples-05 I discovered some issues that I would like to present and probably needs to be fixed. If I am wrong I would appreciate if someone could explain it to me. - AliceRSASignByCarl.cer: The asn1dump of the certificate in the draft-text is not a correct representation of the binary certificate. The binary certificate has has a different OID for the signature algorithm identifier (sha-1WithRSAEncryption (1 3 14 3 2 29)) which also results in a different signature value. Alice's RSA certificate conveyed within the example messages (for example 5.2) has the OID that the draft-text specifies. If using the stand-alone binary certificate, this could lead to a conflict where you have two binary different certificates with the same issuer and serial number. I suppose that the stand-alone binary form ("AliceRSASignByCarl.cer") needs to be updated to be the same as the one present in the binary examples and the draft-text. - CRL's and nextUpdate field: None of the CRLs in the examples have the nextUpdate field present. I know that the field is optional in the ASN1 spec, but it is required to be present according to RFC 2459, sec 5.1.2.5. - example 6.2: The asn1dump of the example present in the draft-text is not a correct representation of the binary form of the 6.2 example. For example: before the asn1dump the draft-text declares that the example does not have an OriginatorInfo field, which is correct in the binary example but not according to the asn1dump that follows in the draft-text. There are also a lot of other differences but I will leave out those details. I suppose that the binary version of the example is the correct one and the asn1dump in the draft-text needs to be updated. If the binary version of the example is the correct one, there is an incorrect version number of the KeyTransRecipientInfo field. Since the RecipientIdentifier is of the IssuerAndSerialnumber choice the version number should be 0 and not 2 (RFC 2630, sec 6.2.1). Below is my asn1dump of the KeyTransRecipientInfo field of the binary version of the 6.2 example: 30 30 187: SEQUENCE { 33 02 1: INTEGER 2 36 30 38: SEQUENCE { 38 30 18: SEQUENCE { 40 31 16: SET { 42 30 14: SEQUENCE { 44 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 49 13 7: PrintableString 'CarlRSA' : } : } : } 58 02 16: INTEGER : 46 34 6B C7 80 00 56 BC 11 D3 6E 2E CD 5D 71 D0 : } 76 30 11: SEQUENCE { 78 06 9: OBJECT IDENTIFIER : rsaEncryption (1 2 840 113549 1 1 1) : } 89 04 128: OCTET STRING : 45 1E C2 3C B5 4A DA DD CD F0 1F CF BE 2F 90 E4 : 54 DB 57 DC 87 40 E9 99 35 51 64 50 1B D0 5E 1C : 94 DC E9 9B 9F F8 B1 40 E4 F8 91 09 9D F8 F7 E5 : 19 DB 43 38 69 70 E7 67 36 E1 0E E6 4A 73 B0 DF : 19 AD 0E 47 4F 13 27 57 2C E9 81 F3 F1 A6 DF 1F : B6 B2 1D 32 D0 50 BE 0D 73 E1 D0 E3 27 FC 70 F4 : 05 8E DA D9 42 02 00 16 3F 64 26 45 9B F8 98 29 : 0C 68 09 94 E8 61 F9 09 4B 73 35 82 9A CE D0 8B : } Regards, Magnus Svensson
--- End Message ---
Attachment:
6.2.bin
Description: Binary data
Attachment:
11.5.bin
Description: Binary data