RE: Issues with draft-ietf-smime-examples-05
"Pawling, John" <[email protected]> Thu, 11 Jan 2001 13:30:06 -0500
| Newsgroups | gmane.ietf.smime-examples |
|---|---|
| Message-ID | <[email protected]> |
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, [email protected] Getronics Government Solutions, LLC =========================================== -----Original Message----- From: Magnus Svensson [mailto:[email protected]] Sent: Thursday, January 11, 2001 11:30 AM To: [email protected] 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