idnits 2.17.1 draft-ietf-smime-multisig-04.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 746. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 757. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 764. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 770. 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 (January 22, 2008) is 5939 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 January 22, 2008 4 Expires: July 22, 2008 6 Multiple Signatures in S/MIME 7 draft-ietf-smime-multisig-04.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 July 22, 2008. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2008). 38 Abstract 40 CMS SignedData includes the SignerInfo structure to convey per-signer 41 information. SignedData supports multiple signers and multiple 42 signature algorithms per-signer with multiple SignerInfo structures. 43 If a signer attaches more than one SignerInfo, there are concerns 44 that an attacker could perform a downgrade attack by removing the 45 SignerInfo(s) with the 'strong' algorithm(s). This document defines 46 the multiple-signatures attribute, its generation rules, and its 47 processing rules to allow signers to convey multiple SignerInfo while 48 protecting against downgrade attacks. Additionally, this attribute 49 may assist during periods of algorithm migration. 51 Conventions used in this document 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in [RFC2119]. 57 Discussion 59 This draft is being discussed on the 'ietf-smime' mailing list. To 60 subscribe, send a message to ietf-smime-request@imc.org with the 61 single word subscribe in the body of the message. There is a Web site 62 for the mailing list at . 64 Table of Contents 66 1. Introduction...................................................3 67 2. Rationale......................................................3 68 2.1. Attribute Design Requirements.............................4 69 3. Multiple Signature Indication..................................5 70 4. Message Generation and Processing..............................6 71 4.1. SignedData Type...........................................7 72 4.2. EncapsulatedContentInfo Type..............................7 73 4.3. SignerInfo Type...........................................7 74 4.4. Message Digest Calculation Process........................8 75 4.4.1. multiple-signatures Signed Attribute Generation......8 76 4.4.2. Message Digest calculation Process...................8 77 4.5. Signature Generation Process..............................8 78 4.6. Signature Verification Process............................8 79 5. Signature Evaluation Processing................................9 80 5.1. Evaluation of a SignerInfo object.........................9 81 5.2. Evaluation of a SignerInfo Set...........................10 82 5.3. Evaluation of a SignedData Set...........................11 83 6. Security Considerations.......................................12 84 7. IANA Considerations...........................................12 85 8. References....................................................12 86 8.1. Normative References.....................................12 87 8.2. Informative References...................................13 88 Appendix A. ASN.1 Module.........................................14 89 Appendix B. Background...........................................16 90 B.1. Attacks..................................................16 91 B.2. Hashes in CMS............................................16 93 1. Introduction 95 The Cryptographic Message Syntax (CMS), see [CMS], defined SignerInfo 96 to provide data necessary for relying parties to verify the signer's 97 digital signature, which is also include in the SignerInfo structure. 98 Signers include more than one SignerInfo in a SignedData if they use 99 different digest or signature algorithms. Each SignerInfo exists 100 independently and new SignerInfo structures can be added or an 101 existing one(s) removed without perturbing the remaining 102 signature(s). 104 The concern is that if an attacker successfully attacked a hash or 105 signature algorithm; the attacker could remove all SignerInfo 106 structures except the SignerInfo with the successfully attacked hash 107 or signature algorithm; the relying party is then left with the 108 attacked SignerInfo even though the relying party supported more than 109 just the attacked hash or signature algorithm. 111 A solution is to have signers include a pointer to all the signer's 112 SignerInfo structures. If an attacker removes any SignerInfo, then 113 relying parties will be aware that an attacker has removed one or 114 more SignerInfo. 116 Note this attribute ought not be confused with the countersignature 117 attribute, see 11.4 of [CMS], as this is not intended to sign over an 118 existing signature rather it is to provide a pointer to additional 119 signer's signatures that are all at the same level. That is 120 countersignature provides a serial signature while the attribute 121 defined herein provides pointers to parallel signature by the same 122 signer. 124 2. Rationale 126 The rationale for this specification is to protect against downgrade 127 attacks that remove the 'strong' signature to leave the 'weak' 128 signature, which has presumably been successfully attacked. If a CMS 129 object has multiple SignerInfos, then the attacker, whether it be 130 Alice, Bob, or Mallory, can remove SignerInfos without the relying 131 party being aware that more than one was generated. 133 Removal of a SignerInfo does not render the signature invalid nor 134 does it constitute an error. In the following scenario: a signer 135 generates a SignedData with two SignerInfo objects one with a 'weak' 136 algorithm and one with a 'strong' algorithm; there are three types of 137 relying parties: 139 1) Those that support only a 'weak' algorithm. If both SignerInfo 140 objects are present, the relying party processes the algorithm it 141 supports. If both SignerInfo objects are not present, the relying 142 party can easily determine that another SignerInfo has been 143 removed, but not changed. In both cases, if the 'weak' signature 144 verifies the relying party MAY consider the signature valid. 146 2) Those that support only a 'strong' algorithm. If both 147 SignerInfo objects are present, the relying party processes the 148 algorithm it supports. If both SignerInfo objects are not present, 149 the relying party can easily determine that another SignerInfo has 150 been removed, but the relying party doesn't care. In both cases, 151 if the 'strong' signature verifies the relying party MAY consider 152 the signature valid. 154 3) Those that support both a 'weak' algorithm and a 'strong' 155 algorithm. If both SignerInfo objects are present, the relying 156 party processes both algorithms. If both SignerInfo objects are 157 not present, the relying party can easily determine that another 158 SignerInfo has been removed. 160 Local policy MAY dictate that the removal of the 'strong' algorithm 161 results in an invalid signature. See section 5 for further 162 processing. 164 2.1. Attribute Design Requirements 166 The attribute will have the following characteristics: 168 1) Use CMS attribute structure; 170 2) Be computable before any signatures are applied; 172 3) Contain enough information to identify individual signatures 173 (i.e., a particular SignerInfo); and, 175 4) Contain enough information to resist collision, preimage, and 176 second premiage attacks. 178 3. Multiple Signature Indication 180 The multiple-signatures attribute type specifies a pointer to a 181 signer's other multiple-signatures attribute(s). For example, if a 182 signer applies three signatures there must be two attribute values 183 for multiple-signatures in each SignerInfo. The 1st SignerInfo 184 points to the 2nd and 3rd SignerInfos. The 2nd SignerInfo points to 185 the 1st and 3rd SignerInfos. The 3rd SignerInfo points to the 1st and 186 2nd SignerInfos. 188 The multiple-signatures attribute MUST be a signed attribute. The 189 number of attribute values included in a SignerInfo is the number of 190 signatures applied by a signer less one. This attribute is multi- 191 valued and there MAY be more than one AttributeValue present. 192 The following object identifier identifies the multiple-signatures 193 attribute: 195 id-aa-multipleSignatures OBJECT IDENTIFIER ::= { 196 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 197 id-aa(16) 51 } 199 multiple-signatures attribute values have the ASN.1 type 200 MultipleSignatures: 202 MultipleSignatures ::= SEQUENCE { 203 bodyHashAlg DigestAlgorithmIdentifier, 204 signAlg SignatureAlgorithmIdentifier, 205 signAttrsHash SignAttrsHash, 206 cert ESSCertIDv2 OPTIONAL} 208 SignAttrsHash ::= SEQUENCE { 209 algID DigestAlgorithmIdentifier, 210 hash OCTET STRING } 212 The fields in MultipleSignatures have the following meaning: 214 - bodyHashAlg includes the digest algorithmIdentifier for the 215 referenced multiple-signatures attribute. 217 - signAlg includes the signature algorithmIdentifier for the 218 referenced multiple-signatures attribute. 220 - signAttrsHash has two fields: 222 -- aldId MUST match the digest algorithm for the SignerInfo in 223 which this multiple-signatures attribute value is placed. 225 -- hash is the hash value of the signedAttrs (see section 4.3). 227 - cert is optional. It identities the certificate used to sign the 228 SignerInfo that contains the other multiple-signatures 229 attribute(s). It MUST be present if the fields in the other 230 multiple-signatures attribute(s) are the same. 232 The following is an example: 234 SignedData 235 DigestAlg=sha1,sha256 236 SignerInfo1 SignerInfo2 237 digestAlg=sha1 digestAlg=sha256 238 signatureAlg=dsawithsha1 signatureAlg=ecdsawithsha256 239 signedAttrs= signedAttrs= 240 signingTime1 signingTime1 241 messageDigest1 messageDigest2 242 multiSig1= multiSig2= 243 bodyHash=sha256 bodyHash=sha1 244 signAlg=ecdsawithsha256 signAlg=dsawithsha1 245 signAttrsHash= signAttrsHash= 246 algID=sha1 algID=sha256 247 hash=value1 hash=value2 249 4. Message Generation and Processing 251 The following are the additional procedures for Message Generation 252 when using the multiple-signatures attribute. These paragraphs track 253 with section 5.1-5.6 in [CMS]. 255 4.1. SignedData Type 257 The following steps MUST be followed by a signer when generating 258 SignedData: 260 - The signer MUST indicate the CMS version. 262 - The signer SHOULD include the digest algorithm used in 263 SignedData.digestAlgorithms, if the digest algorithm's identifier 264 is not already present. 266 - The signer MUST include the encapContentInfo. Note the 267 encapContentInfo is the same for all signers in this SignedData. 269 - The signer SHOULD add certificates sufficient to contain 270 certificate paths from a recognized "root" or "top-level 271 certification authority" to the signer, if the signer's 272 certificates are not already present. 274 - The signer MAY include the Certificate Revocation Lists (CRLs) 275 necessary to validate the digital signature, if the CRLs are not 276 already present. 278 - The signer MUST: 280 -- Retain the existing signerInfo(s). 282 -- Include their signerInfo. 284 4.2. EncapsulatedContentInfo Type 286 The procedures for generating EncapsulatedContentInfo are as 287 specified in section 5.2 of [CMS]. 289 4.3. SignerInfo Type 291 The procedures for generating a SignerInfo are as specified in 292 section 4.4.1 of [CMS] with the following addition: 294 The signer MUST include the multiple-signatures attribute in 295 signedAttrs. 297 4.4. Message Digest Calculation Process 299 4.4.1. multiple-signatures Signed Attribute Generation 301 The procedure for generating the multiple-signatures signed attribute 302 are as follows: 304 1) All other signed attributes are placed in the respective 305 SignerInfo structures but the signatures are not yet computed for 306 the SignerInfo. 308 2) The multiple-signatures attributes are added to each of the 309 SignerInfo structures with the SignAttrsHash.hash field containing 310 a zero length octet string. 312 3) The correct SignAttrsHash.hash value is computed for each of the 313 SignerInfo structures. 315 4) After all hash values have been computed, the correct hash 316 values are placed into their respective SignAttrsHash.hash fields. 318 4.4.2. Message Digest calculation Process 320 The remaining procedures for generating the message-digest attribute 321 are as specified in section 5.4 of [CMS]. 323 4.5. Signature Generation Process 325 The procedures for signature generation are as specified in section 326 5.5 of [CMS]. 328 4.6. Signature Verification Process 330 The procedures for signature verification are as specified in section 331 5.6 of [CMS] with the following addition: 333 If the SignedData signerInfo includes the multiple-signatures 334 attribute, the attribute's values must be calculated as described in 335 section 4.4.1. 337 For every SignerInfo to be considered present for a given signer, the 338 number of MultipleSignatures AttributeValue(s) present in a given 339 SignerInfo MUST equal the number of SignerInfos for that signer less 340 one and the hash value present in each of the MultipleSignatures 341 AttributeValue(s) MUST match the output of the message digest 342 calculation from section 4.4.1 for each SignerInfo. 344 The hash corresponding to the 1st SignerInfo must match the value in 345 the multiple-signatures attribute that points to the 1st SignerInfo 346 present in the 2nd and 3rd SignerInfos. The hash corresponding to 347 the 2nd SignerInfo must match the value in the multiple-signatures 348 attribute that points to the 2nd SignerInfo present in the 1st and 349 3rd SignerInfos. The hash corresponding to the 3rd SignerInfo must 350 match the value in the multiple-signatures attribute that points to 351 the 3rd SignerInfo present in the 1st and 2nd SignerInfos. 353 5. Signature Evaluation Processing 355 This section describes recommended processing of signatures when 356 there are more than one SignerInfo present in a message. This may be 357 due to either multiple SignerInfos being present in a singled 358 SignedData object, or there are multiple SignerData objects embedded 359 in each other. 361 The text in this section is non-normative. The processing described 362 is highly recommended, but is not forced. Changes in the processing 363 which have the same results with somewhat different orders of 364 processing is sufficient. 366 Order of operations: 368 1) Evaluate each SignerInfo object independently. 370 2) Combine the results of all SignerInfo objects at the same level 371 (i.e. attached to the same SignerData object) 373 3) Combine the results of the nested SignerData objects. Note that 374 this should ignore the presence of other CMS objects between the 375 SignedData objects. 377 5.1. Evaluation of a SignerInfo object 379 When evaluating a SignerInfo object, there are three different pieces 380 that need to be examined. 382 The first piece is the mathematics of the signature itself (i.e., can 383 one actually successfully do the computations and get the correct 384 answer). This result is one of three results. The mathematics 385 succeeds, the mathematics fails, or the mathematics cannot be 386 evaluated. The type of things that lead to the last state are non- 387 implementation of an algorithm or required inputs, such as the public 388 key, are missing. 390 The second piece is the validation of the source of the public key. 391 For CMS, this is generally determined by extracting the public key 392 from a certificate. The certificate needs to be evaluated. This is 393 done by the procedures outlined in [PROFILE]. In addition to the 394 processing described in that document, there may be additional 395 requirements on certification path processing that are required by 396 the application in question. One such set of addition processing is 397 described in [SMIME-CERT]. One piece of information that is part of 398 this additional processing is local and application policy. The 399 output of this processing can actually be one of four different 400 states: Success, Failure, Indeterminate and Warning. The first 401 three states are described in [PROFILE], Warning would be generated 402 when it is possible that some information is currently acceptable, 403 but may not be acceptable either in the near future or under some 404 circumstances. 406 The third piece of the validation is local and application policy as 407 applied to the contents of the SignerInfo object. This would cover 408 such issues as the requirements on mandatory signed attributes or 409 requirements on signature algorithms. 411 5.2. Evaluation of a SignerInfo Set 413 Combining the results of the individual SignerInfos into a result for 414 a SignedData object requires knowledge of the results for the 415 individual SignerInfo objects, the require application policy and any 416 local policies. The default processing if no other rules are applied 417 should be: 419 1) Group the SignerInfo objects by the signer. 421 2) Take the best result from each signer. 423 3) Take the worst result from all of the different signers; this is 424 the result for the SignedData object. 426 Application and local policy can affect each of the steps outlined 427 above. 429 In Step 1: 431 - If the subject name or subject alternative name(s) cannot be used 432 to determine if two SignerInfo objects were created by the same 433 identity, then applications need to specify how such matching is to 434 be done. As an example, the S/MIME message specification [SMIME- 435 MSG] could say that as long as the same RFC 822 name exists in 436 either the subject name or the subject alt name they are the same 437 identity. This would be true even if other information that did 438 not match existed in these fields. 440 - Some applications may specify that this step should be skipped; 441 this has the effect of making each SignerInfo object independent of 442 all other SignerInfo objects even if the signing identity is the 443 same. Applications that specify this need to be aware that 444 algorithm rollover will not work correctly in this case. 446 In Step 2: 448 - The major policy implication at this step is the treatment of and 449 order for the indeterminate states. In most cases this state would 450 be placed between the failure and warning states. Part of the 451 issue is the question of having a multi-state or a binary answer as 452 to success or failure of an evaluation. Not every application can 453 deal with the statement "try again later". It may also be 454 dependent on what the reason for the indeterminate state is. It 455 makes more sense to try again later if the problem is that a CRL 456 cannot be found than if you are not able to evaluate the algorithm 457 for the signature. 459 In Step 3: 461 - The same policy implications from Step 2 apply here. 463 5.3. Evaluation of a SignedData Set 465 For simple applications, the requirement can be made that the result 466 of evaluating a set of SignedData objects is the worst outcome of the 467 items. (I.e. one failure means the entire item fails). However not 468 all applications will want to have this behavior. 470 A work flow application could work as follows: 472 The second signer will modify the original content, keep the 473 original signature and then sign the message. This means that only 474 the outermost signature is of significance during evaluation. The 475 second signer is asserting that they successfully validated the inner 476 signature as part of its processing. 478 A Signed Mail application could work as follows: 480 If signatures are added for the support of [ESS] features, then the 481 fact that an outer layer signature can be treated as a non- 482 significant failure. The only thing that matters is that the 483 originator signature is valid. This means that all outer layer 484 signatures which fail can be stripped from the message prior to 485 display leaving only the inner-most valid signature to be displayed. 487 6. Security Considerations 489 Security considerations from the hash and signature algorithms used 490 to produce the SignerInfo apply. 492 If the hashing and signing operations are performed by different 493 entities, the entity performing the signature must ensure the hash 494 comes from a "trustworthy" source. This can be partially mitigated by 495 requiring that multiple hashes using different algorithms are 496 provided. 498 This attribute cannot be relied upon in the event that all of the 499 algorithms used in the signer attribute are 'cracked'. It is not 500 possible for a verifier to determine that a collision could not be 501 found that satisfies all of the algorithms. 503 Local policy and applications greatly affects signature processing. 504 The application of local policy and the requirements specific to an 505 application can both affect signature processing. This means that a 506 signature valid in one context or location can fail validation in a 507 different context or location. 509 7. IANA Considerations 511 None: All identifiers are already registered. Please remove this 512 section prior to publication as an RFC. 514 8. References 516 8.1. Normative References 518 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 519 Requirement Levels", RFC 2119, BCP 14, March 1997. 521 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 522 3852, July 2004. 524 [PROFILE] Housley, R., Polk, W., Ford, W., and D. Solo, 525 "Internet X.509 Public Key Infrastructure Certificate 526 and Certificate Revocation List (CRL) Profile", RFC 527 3280, April 2002. 529 [SMIME-CERT] Ramsdell, B., and S. Turner, "Secure Multipurpose 530 Internet Mail Extensions (S/MIME) Version 3.2 531 Certificate Handling", work in progress. 533 [SMIME-MSG] Ramsdell, B., and S. Turner, "Secure Multipurpose 534 Internet Mail Extensions (S/MIME) Version 3.2 Message 535 Specification", work in progress. 537 [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", 538 RFC 2634, June 1999. 540 [ESSCertID] Schaad, J., "ESS Update: Adding CertID Algorithm 541 Agility", RFC 5035, August 2007. 543 8.2. Informative References 545 [ATTACK] Hoffman, P., Schneier, B., "Attacks on Cryptographic 546 Hashes in Internet Protocols", RFC 4270, November 547 2005. 549 Appendix A. ASN.1 Module 551 MultipleSignatures-2008 553 { iso(1) member-body(2) us(840) rsadsi(113549) 554 pkcs(1) pkcs-9(9) smime(16) modules(0) 555 id-mod-multipleSig-2008(34) } 557 DEFINITIONS IMPLICIT TAGS ::= 559 BEGIN 561 -- EXPORTS All 563 -- The types and values defined in this module are exported for use 564 -- in the other ASN.1 modules. Other applications may use them for 565 -- their own purposes. 567 IMPORTS 569 -- Imports from RFC 3852 [CMS], 12.1 571 DigestAlgorithmIdentifier, SignatureAlgorithmIdentifier 572 FROM CryptographicMessageSyntax2004 573 { iso(1) member-body(2) us(840) rsadsi(113549) 574 pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) } 576 -- Imports from RFC 5035 [ESSCertID], Appendix A 578 ESSCertIDv2 579 FROM ExtendedSecurityServices-2006 580 { iso(1) member-body(2) us(840) rsadsi(113549) 581 pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-ess-2006(30) } 583 ; 585 -- Section 3.0 587 id-multipleSignatures OBJECT IDENTIFIER ::= { iso(1) member-body(2) 588 us(840) rsadsi(113549) pkcs(1) pkcs9(9) id-aa(2) 51 } 590 MultipleSignatures ::= SEQUENCE { 591 bodyHashAlg DigestAlgorithmIdentifier, 592 signAlg SignatureAlgorithmIdentifier, 593 signAttrsHash SignAttrsHash, 594 cert ESSCertIDv2 OPTIONAL } 596 SignAttrsHash ::= SEQUENCE { 597 algID DigestAlgorithmIdentifier, 598 hash OCTET STRING } 600 END -- of MultipleSignatures-2008 602 Appendix B. Background 604 This is an informative appendix that looks at the locations of hashes 605 CMS and possible attacks against them. 607 B.1. Attacks 609 The following types of resistance against known attacks, see 610 [ATTACK], is needed: 612 1) Collision Resistance: Find x and y where x != y and H(x) = H(y) 614 2) Preimage Resistance: Given y, find x where H(x) = y 616 3) Second Preimage Resistance: Given y, find x where H(x) = H(y) 618 Note: It is known that a collision resistance attack is simpler than 619 a second preimage resistance attack, and it is presumed that a second 620 preimage resistance attack is simplier than a preimage attack. 622 B.2. Hashes in CMS 624 Within a SignedInfo there are two places where hashes are applied and 625 hence can be attacked: the Body and the SignedAttributes. The 626 following outlines the entity that creates the hash, the entity that 627 attacks the hash, and the type of resistance required: 629 1) Hash of the Body (i.e., the octets comprising the value of the 630 encapContentInfo.eContent OCTET STRING omitting the tag and length 631 octets - as per 5.4 of [CMS]). 633 a) Alice creates the Body to be hashed: 635 i) Alice attacks the hash: This would require a successful 636 Collision Resistance attack. 638 ii) Mallory attacks the hash: This would require a successful 639 Second Preimage Reistance attack. 641 b) Alice hashes a body provided by Bob: 643 i) Alice attacks the hash: This would require a successful 644 Second Preimage Attack. 646 ii) Bob attacks the hash: This would require a successful 647 Collision Resistance attack. This can be upgraded to requiring 648 a successful Second Preimage Attack if Alice hash the ability 649 to "change" the content of the body in some fashion. (One 650 example would be to use a keyed hash function.) 652 iii) Mallory attacks the hash: This would require a successful 653 Second Preimage Attack. 655 c) Alice signs using a hash value provided by Bob. (In this case 656 Alice is presumed to never see the body in question.) 658 i) Alice attacks hash: This would require a successful Preimage 659 Attack. 661 ii) Bob attacks hash: This would require a successful Collision 662 Resistance attack. Unlike case (b), there is nothing that 663 Alice can do to upgrade the attack required. 665 iii) Mallory attacks the hash: This would require a success 666 Preimage attack if the content is unavailable to Mallory and a 667 successful Second Preimage attack if the content is available 668 to Mallory. 670 2) Hash of SignedAttributes (i.e., the complete DER encoding of the 671 SignedAttrs value contained in the signedAttrs field - as per 5.4 672 of [CMS]). 674 There is a difference between hashing the body and hashing the 675 SignedAttrs value in that one SHOULD NOT accept a sequence of 676 attributes to be signed from a third party. In fact one SHOULD NOT 677 accept attributes to be included in the signed attributes list from a 678 third party. The attributes are about the signature you are applying 679 and not about the body. If there is meta-information that needs to 680 be attached to the body by a third party then they need to provide 681 their own signature and you need to be doing a countersignature. 682 (Note: the fact that the signature is to be used as a 683 countersignature is a piece of information that should be accepted, 684 but it does not directly provide an attribute that is inserted in the 685 attribute list.) 687 a) Alice attacks the hash: This requires a successful Collision 688 Resistance Attack. 690 b) Mallory attacks the hash: This requires a successful Second 691 Preimage Resistance attack. 693 c) Bob attacks the hash and provides the body hash used: This case 694 is analogous to the current attacks [ATTACK]. Based on prediction 695 of the signed attributes Alice will be using and the provided hash 696 value and function. (It is expected that if Alice uses a keyed 697 hashing function as part of the signature this attack will be more 698 difficult.) 700 It should be noted that both of these attacks are considered to be 701 more difficult that the attack on the body since more structure is 702 designed into the data to be hashed than is frequently found in the 703 body and the data is shorter in length than that of the body. 705 The successful prediction of the Signing-Time attribute is expected 706 to more difficult than with certificates as the time would not 707 generally be rounded. Time stamp services can make this more 708 unpredictable by using a random delay before issuing the signature. 710 Allowing a third party to provide a hash value could potentially make 711 attack simpler when keyed hash functions are used since there is more 712 data than can be modified without changing the overall structure of 713 the Signed Attribute structure. 715 Author's Addresses 717 Sean Turner 719 IECA, Inc. 720 3057 Nutley Street, Suite 106 721 Fairfax, VA 22031 722 USA 724 Email: turners@ieca.com 726 Jim Schaad 728 Soaring Hawk Consulting 730 Email: jimsch@exmsft.com 732 Full Copyright Statement 734 Copyright (C) The IETF Trust (2008). 736 This document is subject to the rights, licenses and restrictions 737 contained in BCP 78, and except as set forth therein, the authors 738 retain all their rights. 740 This document and the information contained herein are provided on an 741 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 742 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 743 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 744 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 745 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 746 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 748 Intellectual Property 750 The IETF takes no position regarding the validity or scope of any 751 Intellectual Property Rights or other rights that might be claimed to 752 pertain to the implementation or use of the technology described in 753 this document or the extent to which any license under such rights 754 might or might not be available; nor does it represent that it has 755 made any independent effort to identify any such rights. Information 756 on the procedures with respect to rights in RFC documents can be 757 found in BCP 78 and BCP 79. 759 Copies of IPR disclosures made to the IETF Secretariat and any 760 assurances of licenses to be made available, or the result of an 761 attempt made to obtain a general license or permission for the use of 762 such proprietary rights by implementers or users of this 763 specification can be obtained from the IETF on-line IPR repository at 764 http://www.ietf.org/ipr. 766 The IETF invites any interested party to bring to its attention any 767 copyrights, patents or patent applications, or other proprietary 768 rights that may cover technology that may be required to implement 769 this standard. Please address the information to the IETF at 770 ietf-ipr@ietf.org. 772 Acknowledgment 774 Funding for the RFC Editor function is provided by the IETF 775 Administrative Support Activity (IASA).