idnits 2.17.1 draft-schaad-smime-hash-experiment-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 24, 2011) is 4841 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5751 (ref. 'SMIME-MSG') (Obsoleted by RFC 8551) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Schaad 3 Internet-Draft Soaring Hawk Consulting 4 Intended status: Experimental January 24, 2011 5 Expires: July 28, 2011 7 Experiment: Hash functions with parameters in CMS and S/MIME 8 draft-schaad-smime-hash-experiment-06 10 Abstract 12 New hash algorithms are being developed and these algorithms may 13 include parameters. CMS has not currently defined any hash 14 algorithms with parameters, but anecdotal evidence suggests that 15 defining one could cause major problems. In this document we define 16 just such an algorithm and describe how to use it so that we can run 17 experiments to find out how bad including hash parameters will be. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 28, 2011. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 2. XOR-MD5 Digest Algorithm . . . . . . . . . . . . . . . . . . . 6 56 3. ASN.1 Encoding . . . . . . . . . . . . . . . . . . . . . . . . 7 57 4. CMS ASN.1 Handling . . . . . . . . . . . . . . . . . . . . . . 8 58 5. MIME handling . . . . . . . . . . . . . . . . . . . . . . . . 9 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 62 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 63 8.2. Informational References . . . . . . . . . . . . . . . . . 12 64 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 13 65 A.1. Encapsulated Signed Data Example . . . . . . . . . . . . . 13 66 A.2. Multipart Signed Message . . . . . . . . . . . . . . . . . 15 67 A.3. Authenticated Data Example . . . . . . . . . . . . . . . . 17 68 Appendix B. 2008 ASN.1 Module . . . . . . . . . . . . . . . . . . 18 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 71 1. Introduction 73 At the present time, all hash algorithms that are used in 74 Cryptographic Message Syntax (CMS) implementations are defined as 75 having no parameters. Anecdotal evidence suggests that if a hash 76 algorithm is defined that does require the presence of parameters 77 there may be extensive problems. This document presents the details 78 needed to run an experiment so that we can find out just how bad the 79 situation really is and, if we need to, either make drastic changes 80 in implementations or make sure that any hash algorithms chosen do 81 not have parameters. 83 In CMS data structures, hash algorithms currently exist in the 84 following locations: 86 o SignerInfo.digestAlgorithm -- holds the digest algorithm used to 87 compute the hash value over the content. 89 o DigestedData.digestAlgorithm -- holds the digest algorithm used to 90 compute the hash value over the content 92 o AuthenticatedData.digestAlgorithm -- holds the digest algorithm 93 used to compute the hash value over the content 95 o SignedData.digestAlgorithms -- an optional location to place 96 information about the set of digest algorithms used in computing 97 the hash value over the content. 99 o multipart/signed micalg - Holds a textual indicator of the hash 100 algorithm for multipart signed MIME messages. 102 The first three locations hold the identification of a single hash, 103 and would hold the parameters for that hash. These fields are 104 mandatory to be filled in. 106 The ASN.1 defined for the types DigestedData and AuthenticatedData 107 are defined by placing the digest algorithm before the encapsulated 108 data. This means that the hash algorithm (including the parameters) 109 is fully defined before the hash function would start hashing the 110 encapsulated data. 112 In the ASN.1 defined for the SignedData type, the value of 113 SignerInfo.digestAlgorithm is not seen until the content has been 114 processed. This is the reason for the existence of the 115 SignedData.digestAlgorithms field, so that the set of all digest 116 algorithms used can be seen prior to the content being processed. It 117 is not currently a mandatory to fill in this field, and the signature 118 validation process is supposed to succeed even if this field is 119 absent. (RFC 5652 says signature validation MAY fail if the digest 120 algorithm is absent.) 122 For the case of detached content, the ASN.1 structures need to be 123 processed before processing the detached content in order to obtain 124 the parameters of the hash function. The MIME multipart/signature 125 content type attempts to avoid this problem by defining a micalg 126 field which contains the set of hash algorithms (with parameters) so 127 that the hash functions can be setup prior to processing the content. 129 When processing multipart/signed messages two paths exists: 131 1. Process the message content before the ASN.1. The steps involved 132 are: 134 * Get a set of hash functions by looking at the micalg parameter 135 and potentially add a set of generic algorithms 137 * Create a hasher for each of those algorithms 139 * Hash the message content (the first part of the multipart) 141 * Process the ASN.1 and have a potential failure point if a hash 142 algorithm is required which was not computed. 144 2. Process the message content after the ASN.1. The steps involved 145 are: 147 * Save the message content for later processing 149 * Parse the ASN.1 and build a list of hash functions based on 150 it's content 152 * Create a hasher for each of those algorithms 154 * Hash the saved message content 156 * Perform the signature validation. 158 The first path allows for single pass processing, but has the 159 potential that a fallback path needs to be added in some cases. The 160 second path does not need a fallback path, but does not allow for 161 single pass processing. 163 The fallback path above may also be needed for the encapsulated 164 content case. Since it is optional to place hash algorithms in the 165 SignedData.digestAlgorithms field, the content will be completely 166 parsed before the set of hash algorithms used in the various 167 SignerInfo structures are determined. It may be that we need to 168 require population of the SignedData.digestAlgorithms field if we 169 adopt a parameterized hash field. 171 In this document a new hash function is created that is based on the 172 XOR operator and on MD5. MD5 was deliberately used as the basis of 173 this digest algorithm since it is known to be insecure and I do not 174 want to make any statements that the hash algorithm designed here is 175 in any way secure. This hash function MUST NOT be released as 176 shipping code, it is designed only for use in experimentation. An 177 example of a parameterized hash algorithm that might be standardized 178 is a scheme developed by Shai Halevi and others [Random-Hash]. 180 1.1. Notation 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in [RFC2119]. 186 2. XOR-MD5 Digest Algorithm 188 The XOR-MD5 digest algorithm has been designed to use two existing 189 operators, XOR and the MD5 hash algorithm [MD5]. The hash algorithm 190 works as follows: 192 1. A random XOR string consisting of exactly 64 bytes is created. 194 2. The input content is broken up into 64 byte blocks. The last 195 block may be less that 64 bytes. 197 3. Each block is XOR-ed with the random string. The last block uses 198 the same number of bits from the random string as it contains. 200 4. The resulting string is run through the MD5 hash function. 202 The length of the XOR string was designed to match the barrel size of 203 the MD5 hash function. 205 3. ASN.1 Encoding 207 The following ASN.1 is used to define the algorithm: 209 mda-xor-md5-EXPERIMENT DIGEST-ALGORITHM ::= { 210 IDENTIFIER id-alg-MD5-XOR-EXPERIMENT 211 PARAMS TYPE MD5-XOR-EXPERIMENT ARE required 212 } 214 id-alg-MD5-XOR-EXPERIMENT OBJECT IDENTIFIER ::= { 215 iso(1) member-body(2) us(840) rsadsi(113549) 216 pkcs(1) pkcs-9(9) smime(16) id-alg(3) 13 217 } 219 MD5-XOR-EXPERIMENT ::= OCTET STRING (SIZE(64)) 221 The octet string holds the value of the random XOR string. 223 4. CMS ASN.1 Handling 225 The algorithm is added to the DigestAlgorithmSet in [CMS]. 227 When this algorithm is used in a signed message, it is REQUIRED that 228 the algorithm be placed in the SignedData.digestAlgorithms sequence. 229 The algorithm MUST appear in the sequence at least once for each 230 unique set of parameters. The algorithm SHOULD NOT appear multiple 231 times with the same set of parameters. 233 5. MIME handling 235 This section defines the string that appears in the micalg parameter. 237 The algorithm is identified by the string xor-md5. The parameters 238 for the algorithm are the hex encoded DER ASN.1 encoding. The 239 parameters and the identifier string are separated by a colon. One 240 of the issues that needs to be addressed is the fact this this will 241 generate very long data values for parameters. These will be too 242 long for many systems to deal with. The issue of how to deal with 243 this has been addressed by creating a method to fragment values in 244 [RFC2231]. An example content-type string that has been fragmented 245 is: 247 Content-Type: multipart/signed; 248 protocol="application/pkcs7-signature"; 249 micalg*0="sha1, xor-md5:04400102030405060708090a0b0c0d0e0f0011"; 250 micalg*1="12131415161718191a1b1c1d1e1f102122232425262728292a2b"; 251 micalg*2="2c2d2e2f203132333435363738"; 252 micalg*3="393a3b3c3d3e3f30"; boundary=boundar42 254 Arguments could be made that the string should be base64 encoded 255 rather than hex encoding the string. The advantage is that the 256 resulting encoding is shorter. This could be significant if there 257 are a substantial number of parameters and of a substantial size. 258 Even with the above example we needed to break the encoding across 259 multiple lines. The downside would be the requirement that the 260 micalg parameter always be quoted. 262 It may be reasonable to require that whitespace be inserted only on 263 encoding boundaries, but it seems to be overly restrictive. 265 6. IANA Considerations 267 There are no IANA considerations. All identifiers are assigned out 268 of the S/MIME OID arc. 270 7. Security Considerations 272 The algorithm XOR-MD5 is not designed for general purpose use. The 273 hash algorithm included here is designed for running this experiment 274 and nothing more. 276 This document makes no representation that XOR-MD5 is a secure digest 277 algorithm. I believe that the algorithm is no more secure than MD5, 278 and I consider MD5 to be a broken hash algorithm for many purposes. 280 One known issue with the algorithm as present is the fact that the 281 xor pattern is always 64 bytes long, even if the data is shorter. 282 This means that there is a section of the data than can be 283 manipulated without changing the hash. In a real algorithm this 284 should either be truncated or forced to a known value. 286 8. References 288 8.1. Normative References 290 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 291 April 1992. 293 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 294 Requirement Levels", BCP 14, RFC 2119, March 1997. 296 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 297 Word Extensions: 298 Character Sets, Languages, and Continuations", RFC 2231, 299 November 1997. 301 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", 302 RFC 5652, September 2009. 304 [SMIME-MSG] 305 Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 306 Mail Extensions (S/MIME) Version 3.2 Message 307 Specification", RFC 5751, January 2010. 309 [ASN.1-2008] 310 ITU-T, "ITU-T Recommendations X.680, X.681, X.682, and 311 X.683", 2008. 313 8.2. Informational References 315 [SMIME-EXAMPLES] 316 Hoffman, P., "Examples of S/MIME Messages", RFC 4134, 317 July 2005. 319 [CMS-ASN] Hoffman, P. and J. Schaad, "New ASN.1 Modules for 320 Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, 321 June 2010. 323 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 324 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 325 June 2010. 327 [Random-Hash] 328 Halevi, S., Shao, W., Krawczyk, H., Boneh, D., and M. 329 McIntosh, "Implementing the Halevi-Krawczyk Randomized 330 Hashing Scheme". 332 Appendix A. Examples 334 Provided here are a set of simple S/MIME messages [SMIME-MSG] that 335 are provided for testing. The content used is the same as that found 336 in Section 2.1 of [SMIME-EXAMPLES]. The certificates and key pairs 337 found in [SMIME-EXAMPLES] are also used here. 339 The perl script in Appendix A of [SMIME-EXAMPLES] can be used to 340 extract the binary examples from this file. The mime examples can be 341 extracted with a standard text editor. 343 Note: The examples presented here have not been independently 344 verified. I was unable to use the Microsoft APIs because of the new 345 cryptographic hash algorithm. However, for the purposes of this 346 experiment I believe that the form of the messages, which can be 347 verified visually as correct, is more important than the question of 348 the message validating. 350 NOTE FOR RFC EDITOR: The | character needs to be in column #1 in 351 order for the extraction script to work. I would suggest that all of 352 the examples below (inside of the artwork) start in column #1. 354 A.1. Encapsulated Signed Data Example 356 This section contains a detached signed data example. The content 357 was hashed with the md5-xor algorithm defined in this document. The 358 signature is performed using RSA with MD5. The signature is wrapped 359 as an embedded signed mime message. 361 MIME-Version: 1.0 362 To: BobRSA@example.com 363 From: AliceDss@example.com 364 Subject: MD5-XOR example message 365 Message-Id: <34567809323489fd.esc@example.com> 366 Date: Wed, 16 Dec 2010 23:13:00 -0500 367 Content-Type: application/pkcs7-mime; smime-type=signed-data; 368 name=smime.p7m; 369 micalg*0="xor-md5: 0440010203405060708090a0b0c0d0e0f10"; 370 micalg*1="111213415161718191a1b1c1d1e1f20212223425262728292a2b2c"; 371 micalg*2="2d2e2f30313233435363738393a3b3c3d3e3f40" 372 Content-Transfer-Encoding: base64 373 Content-Disposition: attachment; filename=smime.p7m 375 MIIEqAYJKoZIhvcNAQcCoIIEmTCCBJUCAQExUTBPBgsqhkiG9w0BCRADDQRAAQIDBAUGBw 376 gJCgsMDQ4PEBESEwQVFhcYGRobHB0eHyAhIiMEJSYnKCkqKywtLi8wMTIzBDU2Nzg5Ojs8 377 PT4/QDArBgkqhkiG9w0BBwGgHgQcVGhpcyBpcyBzb21lIHNhbXBsZSBjb250ZW50LqCCAi 378 swggInMIIBkKADAgECAhBGNGvHgABWvBHTbi7NXXHQMA0GCSqGSIb3DQEBBQUAMBIxEDAO 379 BgNVBAMTB0NhcmxSU0EwHhcNOTkwOTE5MDEwOTAyWhcNMzkxMjMxMjM1OTU5WjARMQ8wDQ 380 YDVQQDEwZCb2JSU0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKnhZ5g/OdVf8qCT 381 QV6meYmFyDVdmpFb+x0B2hlwJhcPvaUi0DWFbXqYZhRBXM+3twg7CcmRuBlpN235ZR572a 382 kzJKN/O7uvRgGGNjQyywcDWVL8hYsxBLjMGAgUSOZPHPtdYMTgXB9T039T2GkB8QX4enDR 383 voPGXzjPHCyqaqfrAgMBAAGjfzB9MAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgUgMB 384 8GA1UdIwQYMBaAFOngkCeseCB6mtNM8kI3TiKunji7MB0GA1UdDgQWBBTo9Lhn2LOWpCrz 385 Eaop05Vahha0JDAdBgNVHREEFjAUgRJCb2JSU0FAZXhhbXBsZS5jb20wDQYJKoZIhvcNAQ 386 EFBQADgYEAe45mxfEQPxAgTIhxq3tAayEz+kqV3p0OW2uUIQXA8uF+Ks2ck4iH+4u3fn1B 387 YeHk1m354gRVYUW8ZCdEwKG9WXnZHWQ8IdZFsF1oM5LqrPFX5YF9mOY1kaM53nf06Bw7Kd 388 x/UQeX8zbwUArdm962XjgRK/tX6oltrcmI2I/PK9MxggHfMIIB2wIBATAmMBIxEDAOBgNV 389 BAMTB0NhcmxSU0ECEEY0a8eAAFa8EdNuLs1dcdAwTwYLKoZIhvcNAQkQAw0EQAECAwQFBg 390 cICQoLDA0ODxAREhMEFRYXGBkaGxwdHh8gISIjBCUmJygpKissLS4vMDEyMwQ1Njc4OTo7 391 PD0+P0CggcowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMD 392 kxMjEwMjMyNTAwWjAfBgkqhkiG9w0BCQQxEgQQlmmuYRtXnoPqECtrSd3A+TBvBgkqhkiG 393 9w0BCTQxYjBgME8GCyqGSIb3DQEJEAMNBEABAgMEBQYHCAkKCwwNDg8QERITBBUWFxgZGh 394 scHR4fICEiIwQlJicoKSorLC0uLzAxMjMENTY3ODk6Ozw9Pj9AoQ0GCSqGSIb3DQEBBAUA 395 MA0GCSqGSIb3DQEBBAUABIGAClMpfG4IL1yAdRxWdvYKbtuFz1XKnFqo9ui7V5PndjlDut 396 yib02knY7UtGNhg6oVEkiZHxYh/iLuoLOHSFA1P4ZacTYrEKChF4K18dsqvlFip1vn8BG/ 397 ysFUDfbx5VcTG2Md0/NHV+qj5ihqM+Pye6Urp+5jbqVgpZOXSLfP+pI= 399 |>sd.bin 400 |MIIEqAYJKoZIhvcNAQcCoIIEmTCCBJUCAQExUTBPBgsqhkiG9w0BCRADDQRAAQIDBAUGBw 401 |gJCgsMDQ4PEBESEwQVFhcYGRobHB0eHyAhIiMEJSYnKCkqKywtLi8wMTIzBDU2Nzg5Ojs8 402 |PT4/QDArBgkqhkiG9w0BBwGgHgQcVGhpcyBpcyBzb21lIHNhbXBsZSBjb250ZW50LqCCAi 403 |swggInMIIBkKADAgECAhBGNGvHgABWvBHTbi7NXXHQMA0GCSqGSIb3DQEBBQUAMBIxEDAO 404 |BgNVBAMTB0NhcmxSU0EwHhcNOTkwOTE5MDEwOTAyWhcNMzkxMjMxMjM1OTU5WjARMQ8wDQ 405 |YDVQQDEwZCb2JSU0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKnhZ5g/OdVf8qCT 406 |QV6meYmFyDVdmpFb+x0B2hlwJhcPvaUi0DWFbXqYZhRBXM+3twg7CcmRuBlpN235ZR572a 407 |kzJKN/O7uvRgGGNjQyywcDWVL8hYsxBLjMGAgUSOZPHPtdYMTgXB9T039T2GkB8QX4enDR 408 |voPGXzjPHCyqaqfrAgMBAAGjfzB9MAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgUgMB 409 |8GA1UdIwQYMBaAFOngkCeseCB6mtNM8kI3TiKunji7MB0GA1UdDgQWBBTo9Lhn2LOWpCrz 410 |Eaop05Vahha0JDAdBgNVHREEFjAUgRJCb2JSU0FAZXhhbXBsZS5jb20wDQYJKoZIhvcNAQ 411 |EFBQADgYEAe45mxfEQPxAgTIhxq3tAayEz+kqV3p0OW2uUIQXA8uF+Ks2ck4iH+4u3fn1B 412 |YeHk1m354gRVYUW8ZCdEwKG9WXnZHWQ8IdZFsF1oM5LqrPFX5YF9mOY1kaM53nf06Bw7Kd 413 |x/UQeX8zbwUArdm962XjgRK/tX6oltrcmI2I/PK9MxggHfMIIB2wIBATAmMBIxEDAOBgNV 414 |BAMTB0NhcmxSU0ECEEY0a8eAAFa8EdNuLs1dcdAwTwYLKoZIhvcNAQkQAw0EQAECAwQFBg 415 |cICQoLDA0ODxAREhMEFRYXGBkaGxwdHh8gISIjBCUmJygpKissLS4vMDEyMwQ1Njc4OTo7 416 |PD0+P0CggcowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMD 417 |kxMjEwMjMyNTAwWjAfBgkqhkiG9w0BCQQxEgQQlmmuYRtXnoPqECtrSd3A+TBvBgkqhkiG 418 |9w0BCTQxYjBgME8GCyqGSIb3DQEJEAMNBEABAgMEBQYHCAkKCwwNDg8QERITBBUWFxgZGh 419 |scHR4fICEiIwQlJicoKSorLC0uLzAxMjMENTY3ODk6Ozw9Pj9AoQ0GCSqGSIb3DQEBBAUA 420 |MA0GCSqGSIb3DQEBBAUABIGAClMpfG4IL1yAdRxWdvYKbtuFz1XKnFqo9ui7V5PndjlDut 421 |yib02knY7UtGNhg6oVEkiZHxYh/iLuoLOHSFA1P4ZacTYrEKChF4K18dsqvlFip1vn8BG/ 422 |ysFUDfbx5VcTG2Md0/NHV+qj5ihqM+Pye6Urp+5jbqVgpZOXSLfP+pI= 423 | 437 Date: Fri, 18 Dec 2010 00:25:21 -0300 438 Content-Type: multipart/signed; 439 micalg*0="xor-md5: 0440010203405060708090a0b0c0d0e0f10"; 440 micalg*1="111213415161718191a1b1c1d1e1f20212223425262728292a2b2c2d2e"; 441 micalg*2="2f30313233435363738393a3b3c3d3e3f40"; 442 boundary="----=_NextBoundry____Fri,_18_Dec_2009_00:25:21"; 443 protocol="application/pkcs7-signature" 445 This is a multi-part message in MIME format. 447 ------=_NextBoundry____Fri,_18_Dec_2009_00:25:21 449 This is some sample content. 450 ------=_NextBoundry____Fri,_18_Dec_2009_00:25:21 451 Content-Type: application/pkcs7-signature; name=smime.p7s 452 Content-Transfer-Encoding: base64 453 Content-Disposition: attachment; filename=smime.p7s 455 MIIEiAYJKoZIhvcNAQcCoIIEeTCCBHUCAQExUTBPBgsqhkiG9w0BCRADDQRAAQIDBAUGBw 456 gJCgsMDQ4PEBESEwQVFhcYGRobHB0eHyAhIiMEJSYnKCkqKywtLi8wMTIzBDU2Nzg5Ojs8 457 PT4/QDALBgkqhkiG9w0BBwGgggIrMIICJzCCAZCgAwIBAgIQRjRrx4AAVrwR024uzV1x0D 458 ANBgkqhkiG9w0BAQUFADASMRAwDgYDVQQDEwdDYXJsUlNBMB4XDTk5MDkxOTAxMDkwMloX 459 DTM5MTIzMTIzNTk1OVowETEPMA0GA1UEAxMGQm9iUlNBMIGfMA0GCSqGSIb3DQEBAQUAA4 460 GNADCBiQKBgQCp4WeYPznVX/Kgk0FepnmJhcg1XZqRW/sdAdoZcCYXD72lItA1hW16mGYU 461 QVzPt7cIOwnJkbgZaTdt+WUee9mpMySjfzu7r0YBhjY0MssHA1lS/IWLMQS4zBgIFEjmTx 462 z7XWDE4FwfU9N/U9hpAfEF+Hpw0b6Dxl84zxwsqmqn6wIDAQABo38wfTAMBgNVHRMBAf8E 463 AjAAMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAWgBTp4JAnrHggeprTTPJCN04irp44uz 464 AdBgNVHQ4EFgQU6PS4Z9izlqQq8xGqKdOVWoYWtCQwHQYDVR0RBBYwFIESQm9iUlNBQGV4 465 YW1wbGUuY29tMA0GCSqGSIb3DQEBBQUAA4GBAHuOZsXxED8QIEyIcat7QGshM/pKld6dDl 466 trlCEFwPLhfirNnJOIh/uLt359QWHh5NZt+eIEVWFFvGQnRMChvVl52R1kPCHWRbBdaDOS 467 6qzxV+WBfZjmNZGjOd539OgcOyncf1EHl/M28FAK3Zvetl44ESv7V+qJba3JiNiPzyvTMY 468 IB3zCCAdsCAQEwJjASMRAwDgYDVQQDEwdDYXJsUlNBAhBGNGvHgABWvBHTbi7NXXHQME8G 469 CyqGSIb3DQEJEAMNBEABAgMEBQYHCAkKCwwNDg8QERITBBUWFxgZGhscHR4fICEiIwQlJi 470 coKSorLC0uLzAxMjMENTY3ODk6Ozw9Pj9AoIHKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B 471 BwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIxMDIzMjUwMFowHwYJKoZIhvcNAQkEMRIEEJZprm 472 EbV56D6hAra0ndwPkwbwYJKoZIhvcNAQk0MWIwYDBPBgsqhkiG9w0BCRADDQRAAQIDBAUG 473 BwgJCgsMDQ4PEBESEwQVFhcYGRobHB0eHyAhIiMEJSYnKCkqKywtLi8wMTIzBDU2Nzg5Oj 474 s8PT4/QKENBgkqhkiG9w0BAQQFADANBgkqhkiG9w0BAQQFAASBgEDMeyAkXMYqg/wW2B3P 475 i8HWwGnZVA/4muJJ7+dEPacv3bRqE7n4dP0vXIYR7TJ1eRJk9uB/wry2fRPcnG3Y/Rn0Jy 476 CqXsb+dXXfwOGK/rvLvJOloXUCy4+HxQk6eaYIBrjiVIUgZjpZXGJcZg2xq5yH1e4aw5Ov 477 fQlfQXPiKp1l 479 ------=_NextBoundry____Fri,_18_Dec_2009_00:25:21-- 480 A.3. Authenticated Data Example 482 This section contains an authenticated data example. The content was 483 hashed with the md5-xor algorithm defined in this document. The 484 authentication was done with the HMAC-SHA1 algorithm. The key is 485 transported using RSA encryption to BobRSASignByCarl certificate. 487 MIME-Version: 1.0 488 To: BobRSA@example.com 489 From: AliceDss@example.com 490 Subject: MD5-XOR example message 491 Message-Id: <34567809323489fd.esc@example.com> 492 Date: Wed, 16 Dec 2010 23:13:00 -0500 493 Content-Type: application/pkcs7-mime; smime-type=authenticated-data; 494 name=smime.p7m; 495 micalg*0="xor-md5: 0440010203405060708090a0b0c0d0e0f10"; 496 micalg*1="111213415161718191a1b1c1d1e1f20212223425262728292a2b2c2d2e"; 497 micalg*2="2f30313233435363738393a3b3c3d3e3f40" 498 Content-Transfer-Encoding: base64 499 Content-Disposition: attachment; filename=smime.p7m 501 MIICRQYLKoZIhvcNAQkQAQKgggI0MIICMAIBADGBwDCBvQIBADAmMBIxEDAOBgNVBAMMB0 502 NhcmxSU0ECEEY0a8eAAFa8EdNuLs1dcdAwDQYJKoZIhvcNAQEBBQAEgYCH70EpEikY7deb 503 859YJRAWfFondQv1D4NFltw6C1ceheWnlAU0C2WEXr3LUBXZp1/PSte29FnJxu5bXCTn1g 504 elMm6zNlZNWNd0KadVBcaxi1n8L52tVM5sWFGJPO5cStOyAka2ucuZM6iAnCSkn1Ju7fgU 505 5j2g3bZ/IM8nHTcygjAKBggrBgEFBQgBAqFPBgsqhkiG9w0BCRADDQRAAQIDBAUGBwgJCg 506 sMDQ4PEBESEwQVFhcYGRobHB0eHyAhIiMEJSYnKCkqKywtLi8wMTIzBDU2Nzg5Ojs8PT4/ 507 QDArBgkqhkiG9w0BBwGgHgQcVGhpcyBpcyBzb21lIHNhbXBsZSBjb250ZW50LqKBxzAYBg 508 kqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTEyMTAyMzI1MDBa 509 MB8GCSqGSIb3DQEJBDESBBCWaa5hG1eeg+oQK2tJ3cD5MGwGCSqGSIb3DQEJNDFfMF0wTw 510 YLKoZIhvcNAQkQAw0EQAECAwQFBgcICQoLDA0ODxAREhMEFRYXGBkaGxwdHh8gISIjBCUm 511 JygpKissLS4vMDEyMwQ1Njc4OTo7PD0+P0CiCgYIKwYBBQUIAQIEFLjUxQ9PJFzFnWraxb 512 EIbVbg2xql 514 |>ad.bin 515 |MIICRQYLKoZIhvcNAQkQAQKgggI0MIICMAIBADGBwDCBvQIBADAmMBIxEDAOBgNVBAMMB0 516 |NhcmxSU0ECEEY0a8eAAFa8EdNuLs1dcdAwDQYJKoZIhvcNAQEBBQAEgYCH70EpEikY7deb 517 |859YJRAWfFondQv1D4NFltw6C1ceheWnlAU0C2WEXr3LUBXZp1/PSte29FnJxu5bXCTn1g 518 |elMm6zNlZNWNd0KadVBcaxi1n8L52tVM5sWFGJPO5cStOyAka2ucuZM6iAnCSkn1Ju7fgU 519 |5j2g3bZ/IM8nHTcygjAKBggrBgEFBQgBAqFPBgsqhkiG9w0BCRADDQRAAQIDBAUGBwgJCg 520 |sMDQ4PEBESEwQVFhcYGRobHB0eHyAhIiMEJSYnKCkqKywtLi8wMTIzBDU2Nzg5Ojs8PT4/ 521 |QDArBgkqhkiG9w0BBwGgHgQcVGhpcyBpcyBzb21lIHNhbXBsZSBjb250ZW50LqKBxzAYBg 522 |kqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTEyMTAyMzI1MDBa 523 |MB8GCSqGSIb3DQEJBDESBBCWaa5hG1eeg+oQK2tJ3cD5MGwGCSqGSIb3DQEJNDFfMF0wTw 524 |YLKoZIhvcNAQkQAw0EQAECAwQFBgcICQoLDA0ODxAREhMEFRYXGBkaGxwdHh8gISIjBCUm 525 |JygpKissLS4vMDEyMwQ1Njc4OTo7PD0+P0CiCgYIKwYBBQUIAQIEFLjUxQ9PJFzFnWraxb 526 |EIbVbg2xql 527 |