idnits 2.17.1 draft-ietf-smime-multisig-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 743. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 754. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 761. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 767. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 11, 2008) is 5852 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) ** Obsolete normative reference: RFC 3280 (ref. 'PROFILE') (Obsoleted by RFC 5280) -- Possible downref: Non-RFC (?) normative reference: ref. 'SMIME-CERT' -- Possible downref: Non-RFC (?) normative reference: ref. 'SMIME-MSG' Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 S/MIME WG Sean Turner, IECA 2 Internet Draft Jim Schaad, Soaring Hawk 3 Intended Status: Standard Track March 11, 2008 4 Expires: September 11, 2008 6 Multiple Signatures in S/MIME 7 draft-ietf-smime-multisig-05.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on September 11, 2008. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2008). 38 Abstract 40 Cryptographic Message Syntax (CMS) SignedData includes the SignerInfo 41 structure to convey per-signer information. SignedData supports 42 multiple signers and multiple signature algorithms per-signer with 43 multiple SignerInfo structures. If a signer attaches more than one 44 SignerInfo, there are concerns that an attacker could perform a 45 downgrade attack by removing the SignerInfo(s) with the 'strong' 46 algorithm(s). This document defines the multiple-signatures 47 attribute, its generation rules, and its processing rules to allow 48 signers to convey multiple SignerInfo while protecting against 49 downgrade attacks. Additionally, this attribute may assist during 50 periods of algorithm migration. 52 Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in [RFC2119]. 58 Discussion 60 This draft is being discussed on the 'ietf-smime' mailing list. To 61 subscribe, send a message to ietf-smime-request@imc.org with the 62 single word subscribe in the body of the message. There is a Web site 63 for the mailing list at . 65 Table of Contents 67 1. Introduction...................................................3 68 2. Rationale......................................................3 69 2.1. Attribute Design Requirements.............................4 70 3. Multiple Signature Indication..................................5 71 4. Message Generation and Processing..............................6 72 4.1. SignedData Type...........................................7 73 4.2. EncapsulatedContentInfo Type..............................7 74 4.3. SignerInfo Type...........................................7 75 4.4. Message Digest Calculation Process........................8 76 4.4.1. multiple-signatures Signed Attribute Generation......8 77 4.4.2. Message Digest calculation Process...................8 78 4.5. Signature Generation Process..............................8 79 4.6. Signature Verification Process............................8 80 5. Signature Evaluation Processing................................9 81 5.1. Evaluation of a SignerInfo object.........................9 82 5.2. Evaluation of a SignerInfo Set...........................10 83 5.3. Evaluation of a SignedData Set...........................11 84 6. Security Considerations.......................................12 85 7. IANA Considerations...........................................12 86 8. References....................................................12 87 8.1. Normative References.....................................12 88 8.2. Informative References...................................13 89 Appendix A. ASN.1 Module.........................................14 90 Appendix B. Background...........................................16 91 B.1. Attacks..................................................16 92 B.2. Hashes in CMS............................................16 94 1. Introduction 96 The Cryptographic Message Syntax (CMS), see [CMS], defined SignerInfo 97 to provide data necessary for relying parties to verify the signer's 98 digital signature, which is also included in the SignerInfo 99 structure. Signers include more than one SignerInfo in a SignedData 100 if they use different digest or signature algorithms. Each SignerInfo 101 exists independently and new SignerInfo structures can be added or an 102 existing one(s) removed without perturbing the remaining 103 signature(s). 105 The concern is that if an attacker successfully attacked a hash or 106 signature algorithm; the attacker could remove all SignerInfo 107 structures except the SignerInfo with the successfully attacked hash 108 or signature algorithm; the relying party is then left with the 109 attacked SignerInfo even though the relying party supported more than 110 just the attacked hash or signature algorithm. 112 A solution is to have signers include a pointer to all the signer's 113 SignerInfo structures. If an attacker removes any SignerInfo, then 114 relying parties will be aware that an attacker has removed one or 115 more SignerInfo. 117 Note this attribute ought not be confused with the countersignature 118 attribute, see 11.4 of [CMS], as this is not intended to sign over an 119 existing signature rather it is to provide a pointer to additional 120 signer's signatures that are all at the same level. That is 121 countersignature provides a serial signature while the attribute 122 defined herein provides pointers to parallel signatures by the same 123 signer. 125 2. Rationale 127 The rationale for this specification is to protect against downgrade 128 attacks that remove the 'strong' signature to leave the 'weak' 129 signature, which has presumably been successfully attacked. If a CMS 130 object has multiple SignerInfos, then the attacker, whether it be 131 Alice, Bob, or Mallory, can remove SignerInfos without the relying 132 party being aware that more than one was generated. 134 Removal of a SignerInfo does not render the signature invalid nor 135 does it constitute an error. In the following scenario: a signer 136 generates a SignedData with two SignerInfo objects one with a 'weak' 137 algorithm and one with a 'strong' algorithm; there are three types of 138 relying parties: 140 1) Those that support only a 'weak' algorithm. If both SignerInfo 141 objects are present, the relying party processes the algorithm it 142 supports. If both SignerInfo objects are not present, the relying 143 party can easily determine that another SignerInfo has been 144 removed, but not changed. In both cases, if the 'weak' signature 145 verifies the relying party MAY consider the signature valid. 147 2) Those that support only a 'strong' algorithm. If both 148 SignerInfo objects are present, the relying party processes the 149 algorithm it supports. If both SignerInfo objects are not present, 150 the relying party can easily determine that another SignerInfo has 151 been removed, but the relying party doesn't care. In both cases, 152 if the 'strong' signature verifies the relying party MAY consider 153 the signature valid. 155 3) Those that support both a 'weak' algorithm and a 'strong' 156 algorithm. If both SignerInfo objects are present, the relying 157 party processes both algorithms. If both SignerInfo objects are 158 not present, the relying party can easily determine that another 159 SignerInfo has been removed. 161 Local policy MAY dictate that the removal of the 'strong' algorithm 162 results in an invalid signature. See section 5 for further 163 processing. 165 2.1. Attribute Design Requirements 167 The attribute will have the following characteristics: 169 1) Use CMS attribute structure; 171 2) Be computable before any signatures are applied; 173 3) Contain enough information to identify individual signatures 174 (i.e., a particular SignerInfo); and, 176 4) Contain enough information to resist collision, preimage, and 177 second premiage attacks. 179 3. Multiple Signature Indication 181 The multiple-signatures attribute type specifies a pointer to a 182 signer's other multiple-signatures attribute(s). For example, if a 183 signer applies three signatures there must be two attribute values 184 for multiple-signatures in each SignerInfo. The 1st SignerInfo 185 points to the 2nd and 3rd SignerInfos. The 2nd SignerInfo points to 186 the 1st and 3rd SignerInfos. The 3rd SignerInfo points to the 1st and 187 2nd SignerInfos. 189 The multiple-signatures attribute MUST be a signed attribute. The 190 number of attribute values included in a SignerInfo is the number of 191 signatures applied by a signer less one. This attribute is multi- 192 valued and there MAY be more than one AttributeValue present. 193 The following object identifier identifies the multiple-signatures 194 attribute: 196 id-aa-multipleSignatures OBJECT IDENTIFIER ::= { 197 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 198 id-aa(16) 51 } 200 multiple-signatures attribute values have the ASN.1 type 201 MultipleSignatures: 203 MultipleSignatures ::= SEQUENCE { 204 bodyHashAlg DigestAlgorithmIdentifier, 205 signAlg SignatureAlgorithmIdentifier, 206 signAttrsHash SignAttrsHash, 207 cert ESSCertIDv2 OPTIONAL} 209 SignAttrsHash ::= SEQUENCE { 210 algID DigestAlgorithmIdentifier, 211 hash OCTET STRING } 213 The fields in MultipleSignatures have the following meaning: 215 - bodyHashAlg includes the digest algorithmIdentifier for the 216 referenced multiple-signatures attribute. 218 - signAlg includes the signature algorithmIdentifier for the 219 referenced multiple-signatures attribute. 221 - signAttrsHash has two fields: 223 -- algId MUST match the digest algorithm for the SignerInfo in 224 which this multiple-signatures attribute value is placed. 226 -- hash is the hash value of the signedAttrs (see section 4.3). 228 - cert is optional. It identities the certificate used to sign the 229 SignerInfo that contains the other multiple-signatures 230 attribute(s). It MUST be present if the fields in the other 231 multiple-signatures attribute(s) are the same. 233 The following is an example: 235 SignedData 236 DigestAlg=sha1,sha256 237 SignerInfo1 SignerInfo2 238 digestAlg=sha1 digestAlg=sha256 239 signatureAlg=dsawithsha1 signatureAlg=ecdsawithsha256 240 signedAttrs= signedAttrs= 241 signingTime1 signingTime1 242 messageDigest1 messageDigest2 243 multiSig1= multiSig2= 244 bodyHash=sha256 bodyHash=sha1 245 signAlg=ecdsawithsha256 signAlg=dsawithsha1 246 signAttrsHash= signAttrsHash= 247 algID=sha1 algID=sha256 248 hash=value1 hash=value2 250 4. Message Generation and Processing 252 The following are the additional procedures for Message Generation 253 when using the multiple-signatures attribute. These paragraphs track 254 with section 5.1-5.6 in [CMS]. 256 4.1. SignedData Type 258 The following steps MUST be followed by a signer when generating 259 SignedData: 261 - The signer MUST indicate the CMS version. 263 - The signer SHOULD include the digest algorithm used in 264 SignedData.digestAlgorithms, if the digest algorithm's identifier 265 is not already present. 267 - The signer MUST include the encapContentInfo. Note the 268 encapContentInfo is the same for all signers in this SignedData. 270 - The signer SHOULD add certificates sufficient to contain 271 certificate paths from a recognized "root" or "top-level 272 certification authority" to the signer, if the signer's 273 certificates are not already present. 275 - The signer MAY include the Certificate Revocation Lists (CRLs) 276 necessary to validate the digital signature, if the CRLs are not 277 already present. 279 - The signer MUST: 281 -- Retain the existing signerInfo(s). 283 -- Include their signerInfo. 285 4.2. EncapsulatedContentInfo Type 287 The procedures for generating EncapsulatedContentInfo are as 288 specified in section 5.2 of [CMS]. 290 4.3. SignerInfo Type 292 The procedures for generating a SignerInfo are as specified in 293 section 4.4.1 of [CMS] with the following addition: 295 The signer MUST include the multiple-signatures attribute in 296 signedAttrs. 298 4.4. Message Digest Calculation Process 300 4.4.1. multiple-signatures Signed Attribute Generation 302 The procedure for generating the multiple-signatures signed attribute 303 is as follows: 305 1) All other signed attributes are placed in the respective 306 SignerInfo structures but the signatures are not yet computed for 307 the SignerInfo. 309 2) The multiple-signatures attributes are added to each of the 310 SignerInfo structures with the SignAttrsHash.hash field containing 311 a zero length octet string. 313 3) The correct SignAttrsHash.hash value is computed for each of the 314 SignerInfo structures. 316 4) After all hash values have been computed, the correct hash 317 values are placed into their respective SignAttrsHash.hash fields. 319 4.4.2. Message Digest calculation Process 321 The remaining procedures for generating the message-digest attribute 322 are as specified in section 5.4 of [CMS]. 324 4.5. Signature Generation Process 326 The procedures for signature generation are as specified in section 327 5.5 of [CMS]. 329 4.6. Signature Verification Process 331 The procedures for signature verification are as specified in section 332 5.6 of [CMS] with the following addition: 334 If the SignedData signerInfo includes the multiple-signatures 335 attribute, the attribute's values must be calculated as described in 336 section 4.4.1. 338 For every SignerInfo to be considered present for a given signer, the 339 number of MultipleSignatures AttributeValue(s) present in a given 340 SignerInfo MUST equal the number of SignerInfos for that signer less 341 one and the hash value present in each of the MultipleSignatures 342 AttributeValue(s) MUST match the output of the message digest 343 calculation from section 4.4.1 for each SignerInfo. 345 The hash corresponding to the n-th SignerInfo must match the value in 346 the multiple-signatures attribute that points to the n-th SignerInfo 347 present in all other SignerInfos. 349 5. Signature Evaluation Processing 351 This section describes recommended processing of signatures when 352 there are more than one SignerInfo present in a message. This may be 353 due to either multiple SignerInfos being present in a single 354 SignedData object, or there are multiple SignerData objects embedded 355 in each other. 357 The text in this section is non-normative. The processing described 358 is highly recommended, but is not forced. Changes in the processing 359 which have the same results with somewhat different orders of 360 processing is sufficient. 362 Order of operations: 364 1) Evaluate each SignerInfo object independently. 366 2) Combine the results of all SignerInfo objects at the same level 367 (i.e. attached to the same SignerData object) 369 3) Combine the results of the nested SignerData objects. Note that 370 this should ignore the presence of other CMS objects between the 371 SignedData objects. 373 5.1. Evaluation of a SignerInfo object 375 When evaluating a SignerInfo object, there are three different pieces 376 that need to be examined. 378 The first piece is the mathematics of the signature itself (i.e., can 379 one actually successfully do the computations and get the correct 380 answer). This result is one of three results. The mathematics 381 succeeds, the mathematics fails, or the mathematics cannot be 382 evaluated. The type of things that lead to the last state are non- 383 implementation of an algorithm or required inputs, such as the public 384 key, are missing. 386 The second piece is the validation of the source of the public key. 387 For CMS, this is generally determined by extracting the public key 388 from a certificate. The certificate needs to be evaluated. This is 389 done by the procedures outlined in [PROFILE]. In addition to the 390 processing described in that document, there may be additional 391 requirements on certification path processing that are required by 392 the application in question. One such set of additional processing 393 is described in [SMIME-CERT]. One piece of information that is part 394 of this additional certificate path processing is local and 395 application policy. The output of this processing can actually be 396 one of four different states: Success, Failure, Indeterminate and 397 Warning. The first three states are described in [PROFILE], Warning 398 would be generated when it is possible that some information is 399 currently acceptable, but may not be acceptable either in the near 400 future or under some circumstances. 402 The third piece of the validation is local and application policy as 403 applied to the contents of the SignerInfo object. This would cover 404 such issues as the requirements on mandatory signed attributes or 405 requirements on signature algorithms. 407 5.2. Evaluation of a SignerInfo Set 409 Combining the results of the individual SignerInfos into a result for 410 a SignedData object requires knowledge of the results for the 411 individual SignerInfo objects, the required application policy and 412 any local policies. The default processing if no other rules are 413 applied should be: 415 1) Group the SignerInfo objects by the signer. 417 2) Take the best result from each signer. 419 3) Take the worst result from all of the different signers; this is 420 the result for the SignedData object. 422 Application and local policy can affect each of the steps outlined 423 above. 425 In Step 1: 427 - If the subject name or subject alternative name(s) cannot be used 428 to determine if two SignerInfo objects were created by the same 429 identity, then applications need to specify how such matching is to 430 be done. As an example, the S/MIME message specification [SMIME- 431 MSG] could say that as long as the same RFC 822 name exists in 432 either the subject name or the subject alt name they are the same 433 identity. This would be true even if other information that did 434 not match existed in these fields. 436 - Some applications may specify that this step should be skipped; 437 this has the effect of making each SignerInfo object independent of 438 all other SignerInfo objects even if the signing identity is the 439 same. Applications that specify this need to be aware that 440 algorithm rollover will not work correctly in this case. 442 In Step 2: 444 - The major policy implication at this step is the treatment of and 445 order for the indeterminate states. In most cases this state would 446 be placed between the failure and warning states. Part of the 447 issue is the question of having a multi-state or a binary answer as 448 to success or failure of an evaluation. Not every application can 449 deal with the statement "try again later". It may also be 450 dependent on what the reason for the indeterminate state is. It 451 makes more sense to try again later if the problem is that a CRL 452 cannot be found than if you are not able to evaluate the algorithm 453 for the signature. 455 In Step 3: 457 - The same policy implications from Step 2 apply here. 459 5.3. Evaluation of a SignedData Set 461 Simple applications will generally use the worst single outcome 462 (success, unknown, failure) as the outcome for a set of SignedData 463 objects (i.e., one failure means the entire item fails). However not 464 all applications will want to have this behavior. 466 A work flow application could work as follows: 468 The second signer will modify the original content, keep the original 469 signature and then sign the message. This means that only the 470 outermost signature is of significance during evaluation. The second 471 signer is asserting that they successfully validated the inner 472 signature as part of its processing. 474 A Signed Mail application could work as follows: 476 If signatures are added for the support of [ESS] features, then the 477 fact that an outer layer signature cannot be validated can be treated 478 as a non-significant failure. The only thing that matters is that 479 the originator signature is valid. This means that all outer layer 480 signatures which fail can be stripped from the message prior to 481 display leaving only the inner-most valid signature to be displayed. 483 6. Security Considerations 485 Security considerations from the hash and signature algorithms used 486 to produce the SignerInfo apply. 488 If the hashing and signing operations are performed by different 489 entities, the entity performing the signature must ensure the hash 490 comes from a "trustworthy" source. This can be partially mitigated by 491 requiring that multiple hashes using different algorithms are 492 provided. 494 This attribute cannot be relied upon in the event that all of the 495 algorithms used in the signer attribute are 'cracked'. It is not 496 possible for a verifier to determine that a collision could not be 497 found that satisfies all of the algorithms. 499 Local policy and applications greatly affects signature processing. 500 The application of local policy and the requirements specific to an 501 application can both affect signature processing. This means that a 502 signature valid in one context or location can fail validation in a 503 different context or location. 505 7. IANA Considerations 507 None: All identifiers are already registered. Please remove this 508 section prior to publication as an RFC. 510 8. References 512 8.1. Normative References 514 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 515 Requirement Levels", RFC 2119, BCP 14, March 1997. 517 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 518 3852, July 2004. 520 [PROFILE] Housley, R., Polk, W., Ford, W., and D. Solo, 521 "Internet X.509 Public Key Infrastructure Certificate 522 and Certificate Revocation List (CRL) Profile", RFC 523 3280, April 2002. 525 [SMIME-CERT] Ramsdell, B., and S. Turner, "Secure Multipurpose 526 Internet Mail Extensions (S/MIME) Version 3.2 527 Certificate Handling", work in progress. 529 [SMIME-MSG] Ramsdell, B., and S. Turner, "Secure Multipurpose 530 Internet Mail Extensions (S/MIME) Version 3.2 Message 531 Specification", work in progress. 533 [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", 534 RFC 2634, June 1999. 536 [ESSCertID] Schaad, J., "ESS Update: Adding CertID Algorithm 537 Agility", RFC 5035, August 2007. 539 8.2. Informative References 541 [ATTACK] Hoffman, P., Schneier, B., "Attacks on Cryptographic 542 Hashes in Internet Protocols", RFC 4270, November 543 2005. 545 Appendix A. ASN.1 Module 547 MultipleSignatures-2008 549 { iso(1) member-body(2) us(840) rsadsi(113549) 550 pkcs(1) pkcs-9(9) smime(16) modules(0) 551 id-mod-multipleSig-2008(34) } 553 DEFINITIONS IMPLICIT TAGS ::= 555 BEGIN 557 -- EXPORTS All 559 -- The types and values defined in this module are exported for use 560 -- in the other ASN.1 modules. Other applications may use them for 561 -- their own purposes. 563 IMPORTS 565 -- Imports from RFC 3852 [CMS], 12.1 567 DigestAlgorithmIdentifier, SignatureAlgorithmIdentifier 568 FROM CryptographicMessageSyntax2004 569 { iso(1) member-body(2) us(840) rsadsi(113549) 570 pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) } 572 -- Imports from RFC 5035 [ESSCertID], Appendix A 574 ESSCertIDv2 575 FROM ExtendedSecurityServices-2006 576 { iso(1) member-body(2) us(840) rsadsi(113549) 577 pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-ess-2006(30) } 579 ; 581 -- Section 3.0 583 id-multipleSignatures OBJECT IDENTIFIER ::= { iso(1) member-body(2) 584 us(840) rsadsi(113549) pkcs(1) pkcs9(9) id-aa(2) 51 } 586 MultipleSignatures ::= SEQUENCE { 587 bodyHashAlg DigestAlgorithmIdentifier, 588 signAlg SignatureAlgorithmIdentifier, 589 signAttrsHash SignAttrsHash, 590 cert ESSCertIDv2 OPTIONAL } 592 SignAttrsHash ::= SEQUENCE { 593 algID DigestAlgorithmIdentifier, 594 hash OCTET STRING } 596 END -- of MultipleSignatures-2008 598 Appendix B. Background 600 This is an informational appendix. This appendix enumerates all 601 locations in CMS where hashes are used and the possible attacks on 602 those hash locations. 604 B.1. Attacks 606 As noted in [ATTACK], the following types of resistance are needed 607 against known attacks: 609 1) Collision Resistance: Find x and y where x != y and H(x) = H(y) 611 2) Preimage Resistance: Given y, find x where H(x) = y 613 3) Second Preimage Resistance: Given y, find x where H(x) = H(y) 615 Note: It is known that a collision resistance attack is simpler than 616 a second preimage resistance attack, and it is presumed that a second 617 preimage resistance attack is simplier than a preimage attack. 619 B.2. Hashes in CMS 621 Within a SignedInfo there are two places where hashes are applied and 622 hence can be attacked: the body and the signed attributes. The 623 following outlines the entity that creates the hash, the entity that 624 attacks the hash, and the type of resistance required: 626 1) Hash of the Body (i.e., the octets comprising the value of the 627 encapContentInfo.eContent OCTET STRING omitting the tag and length 628 octets - as per 5.4 of [CMS]). 630 a) If Alice creates the body to be hashed, then: 632 i) Alice can attack the hash. This attack requires a 633 successful Collision Resistance attack. 635 ii) Mallory can attack the hash. This attack requires a 636 successful Second Preimage Resistance attack. 638 b) If Alice hashes a body provided by Bob, then: 640 i) Alice can attack the hash. This attack requires a 641 successful Second Preimage attack. 643 ii) Bob can attack the hash. This attack requires a successful 644 Collision Resistance attack. If Alice has the ability to 645 "change" the content of the body in some fashion, then this 646 attack requires a successful Second Preimage attack. (One 647 example would be to use a keyed hash function.) 649 iii) Mallory can attack the hash. This attack requires a 650 successful Second Preimage attack. 652 c) If Alice signs using a hash value provided by Bob (in this 653 case Alice is presumed to never see the body in question), then: 655 i) Alice can attack the hash. This attack requires a 656 successful Preimage attack. 658 ii) Bob can attack the hash. This attack requires a successful 659 Collision Resistance attack. Unlike case (b), there is nothing 660 that Alice can do to upgrade the attack. 662 iii) Mallory can attack the hash. This requires a successful 663 Preimage attack if the content is unavailable to Mallory and a 664 successful Second Preimage attack if the content is available 665 to Mallory. 667 2) Hash of signed attributes (i.e., the complete Distinguished 668 Encoding Rules (DER) encoding of the SignedAttrs value contained in 669 the signedAttrs field - as per 5.4 of [CMS]). 671 There is a difference between hashing the body and hashing the 672 SignedAttrs value in that one should not accept a sequence of 673 attributes to be signed from a third party. In fact one should not 674 accept attributes to be included in the signed attributes list from 675 a third party. The attributes are about the signature you are 676 applying and not about the body. If there is meta-information that 677 needs to be attached to the body by a third party then they need to 678 provide their own signature and you need to add a countersignature. 679 (Note: the fact that the signature is to be used as a 680 countersignature is a piece of information that should be accepted, 681 but it does not directly provide an attribute that is inserted in 682 the signed attribute list.) 684 a) Alice can attack the hash: This requires a successful 685 Collision Resistance Attack. 687 b) Mallory can attack the hash: This requires a successful 688 Second Preimage Resistance attack. 690 c) Bob can attack the hash and knows the body hash used: This 691 case is analogous to the current attacks [ATTACK]. Based on 692 prediction of the signed attributes Alice will be using and the 693 provided hash value and function. (It is expected that if 694 Alice uses a keyed hashing function as part of the signature 695 this attack will be more difficult.) 697 It should be noted that both of these attacks are considered to be 698 more difficult than the attack on the body since more structure is 699 designed into the data to be hashed than is frequently found in the 700 body and the data is shorter in length than that of the body. 702 The successful prediction of the signing-time attribute is expected 703 to be more difficult than with certificates as the time would not 704 generally be rounded. Time stamp services can make this more 705 unpredictable by using a random delay before issuing the signature. 707 Allowing a third party to provide a hash value could potentially make 708 an attack simpler when keyed hash functions are used since there is 709 more data than can be modified without changing the overall structure 710 of the signed attribute structure. 712 Author's Addresses 714 Sean Turner 716 IECA, Inc. 717 3057 Nutley Street, Suite 106 718 Fairfax, VA 22031 719 USA 721 Email: turners@ieca.com 723 Jim Schaad 725 Soaring Hawk Consulting 727 Email: jimsch@exmsft.com 729 Full Copyright Statement 731 Copyright (C) The IETF Trust (2008). 733 This document is subject to the rights, licenses and restrictions 734 contained in BCP 78, and except as set forth therein, the authors 735 retain all their rights. 737 This document and the information contained herein are provided on an 738 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 739 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 740 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 741 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 742 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 743 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 745 Intellectual Property 747 The IETF takes no position regarding the validity or scope of any 748 Intellectual Property Rights or other rights that might be claimed to 749 pertain to the implementation or use of the technology described in 750 this document or the extent to which any license under such rights 751 might or might not be available; nor does it represent that it has 752 made any independent effort to identify any such rights. Information 753 on the procedures with respect to rights in RFC documents can be 754 found in BCP 78 and BCP 79. 756 Copies of IPR disclosures made to the IETF Secretariat and any 757 assurances of licenses to be made available, or the result of an 758 attempt made to obtain a general license or permission for the use of 759 such proprietary rights by implementers or users of this 760 specification can be obtained from the IETF on-line IPR repository at 761 http://www.ietf.org/ipr. 763 The IETF invites any interested party to bring to its attention any 764 copyrights, patents or patent applications, or other proprietary 765 rights that may cover technology that may be required to implement 766 this standard. Please address the information to the IETF at 767 ietf-ipr@ietf.org. 769 Acknowledgment 771 Funding for the RFC Editor function is provided by the IETF 772 Administrative Support Activity (IASA).