idnits 2.17.1 draft-ietf-smime-multisig-00.txt: -(69): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(77): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(207): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(230): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(310): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(317): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(382): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(434): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(542): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(543): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 on line 647. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 624. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 631. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 637. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 16 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 212 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 168: '...alue in that one SHOULD NOT accept a s...' RFC 2119 keyword, line 169: '...rom a third party. In fact one SHOULD...' RFC 2119 keyword, line 237: '...atures attribute MUST be a signed attr...' RFC 2119 keyword, line 240: '...valued and there MAY be more than one ...' RFC 2119 keyword, line 270: '... - aldId MUST match the digest...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 510 has weird spacing: '... signed mail....' -- 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 (June 4, 2007) is 6164 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'MUSTSHOULD' is mentioned on line 88, but not defined == Missing Reference: 'ATTACK' is mentioned on line 102, but not defined == Missing Reference: 'PKIX-CERT' is mentioned on line 450, but not defined == Missing Reference: 'SMIME-CERT' is mentioned on line 446, but not defined ** Obsolete normative reference: RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) ** Obsolete normative reference: RFC 3280 (ref. 'PROFILE') (Obsoleted by RFC 5280) -- No information found for draft-ietf-smime-esscertid - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ESSCertID' Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SMIME Working Group Sean Turner, IECA 2 Internet Draft Jim Schaad, Soaring Hawk 3 Expires June 4, 2007 4 December 4, 2006 6 Multiple Signatures in S/MIME 7 draft-ietf-smime-multisig-00.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 other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on June 4, 2007. 33 Copyright Notice 35 Copyright (C) The Internet Society (2006). 37 Abstract 39 CMS SignedData includes the SignerInfo structure to convey per- 40 signer information. SignedData supports multiple signers and 41 multiple signature algorithms per-signer with multiple SignerInfo 42 structures. If a signer attaches more than one SignerInfo, there are 43 concerns that an attacker could perform a downgrade attack by 44 removing the SignerInfo(s) with the 'stronger' algorithm(s). This 45 document defines a signed attribute, its generation rules, and its 46 processing rules to allow signers to convey multiple SignerInfo 47 while protecting against downgrade attacks. Additionally, this 48 attribute may assist during periods of algorithm migration. 50 Schaad, Turner Expires June 2007 1 51 1 Introduction 53 The Cryptographic Message Syntax (CMS), see [CMS], defined 54 SignerInfo to provide data necessary for relying parties to verify 55 the signer�s digital signature, which is also include in the 56 SignerInfo structure. Signers include more than one SignerInfo in a 57 SignedData if they use different digest or signature algorithms. 58 Each SignerInfo exists independently and new SignerInfo structures 59 can be added or an existing one(s) removed without perturbing the 60 remaining signature(s). 62 The concern is that if an attacker successfully attacked a hash or 63 signature algorithm; the attacker could remove all SignerInfo 64 structures except the SignerInfo with the successfully attacked hash 65 or signature algorithm; the relying party is then left with the 66 attacked SignerInfo even though the relying party supported more 67 than just the attacked hash or signature algorithm. 69 A solution is to have signers include a pointer to all the signer�s 70 SignerInfo structures. If an attacker removes any SignerInfo, then 71 relying parties will be aware that an attacker has removed one or 72 more SignerInfo. 74 Note this attribute ought not be confused with the countersignature 75 attribute, see 11.4 of [CMS], as this is not intended to sign over 76 an existing signature rather it is to provide a pointer to 77 additional signer�s signatures that are all at the same level. That 78 is countersignature provides a serial signature while the attribute 79 defined herein provides pointers to parallel signature by the same 80 signer. 82 1.1 Requirements Terminology 84 Though this document is not an Internet Draft, we use the convention 85 that the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 86 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 87 this document are to be interpreted as described in [MUSTSHOULD]. 89 1.2 Discussion 91 This draft is being discussed on the 'ietf-smime' mailing list. To 92 subscribe, send a message to ietf-smime-request@imc.org with the 93 single word subscribe in the body of the message. There is a Web 94 site for the mailing list at . 96 Schaad, Turner Expires June 2007 2 97 2. Rationale 99 2.1 Attacks 101 The following types of resistance against known attacks, see 102 [ATTACK], is needed: 104 1) Collision Resistance: Find x and y where x != y and H(x) = H(y) 106 2) Preimage Resistance: Given y, find x where H(x) = y 108 3) Second Preimage Resistance: Given y, find x where H(x) = H(y) 110 Note: It is known that a collision resistance attack is simpler 111 than a second preimage resistance attack, and it is presumed that a 112 second preimage resistance attack is simplier than a preimage 113 attack. 115 Within a SignedInfo there are two places where hashes are applied 116 and hence can be attacked: the Body and the SignedAttributes. The 117 following outlines the entity that creates the hash, the entity that 118 attacks the hash, and the type of resistance required: 120 1) Hash of the Body (i.e., the octets comprising the value of the 121 encapContentInfo.eContent OCTET STRING omitting the tag and 122 length octets - as per 5.4 of [CMS]). 124 a) Alice creates the Body to be hashed: 126 i) Alice attacks the hash: This would require a successful 127 Collision Resistance attack. 129 ii) Mallory attacks the hash: This would require a 130 successful Second Preimage Reistance attack. 132 b) Alice hashes a body provided by Bob: 134 i) Alice attacks the hash: This would require a successful 135 Second Preimage Attack. 137 ii) Bob attacks the hash: This would require a successful 138 Collision Resistance attack. This can be upgraded to 139 requiring a successful Second Preimage Attack if Alice hash 140 the ability to "change" the content of the body in some 141 fashion. (One example would be to use a keyed hash 142 function.) 144 iii) Mallory attacks the hash: This would require a 145 successful Second Preimage Attack. 147 Schaad, Turner Expires June 2007 3 148 c) Alice signs using a hash value provided by Bob. (In this 149 case Alice is presumed to never see the body in question.) 151 i) Alice attacks hash: This would require a successful 152 Preimage Attack. 154 ii) Bob attacks hash: This would require a successful 155 Collision Resistance attack. Unlike case (b), there is 156 nothing that Alice can do to upgrade the attack required. 158 iii) Mallory attacks the hash: This would require a success 159 Preimage attack if the content is unavailable to Mallory and 160 a successful Second Preimage attack if the content is 161 available to Mallory. 163 2) Hash of SignedAttributes (i.e., the complete DER encoding of 164 the SignedAttrs value contained in the signedAttrs field - as 165 per 5.4 of [CMS]). 167 There is a difference between hashing the body and hashing the 168 SignedAttrs value in that one SHOULD NOT accept a sequence of 169 attributes to be signed from a third party. In fact one SHOULD 170 NOT accept attributes to be included in the signed attributes 171 list from a third party. The attributes are about the 172 signature you are applying and not about the body. If there is 173 meta-information that needs to be attached to the body by a 174 third party then they need to provide their own signature and 175 you need to be doing a countersignature. (Note: the fact that 176 the signature is to be used as a countersignature is a piece of 177 information that should be accepted, but it does not directly 178 provide an attribute that is inserted in the attribute list.) 180 a) Alice attacks the hash: This requires a successful Collision 181 Resistance Attack. 183 b) Mallory attacks the hash: This requires a successful Second 184 Preimage Resistance attack. 186 c) Bob attacks the hash and provides the body hash used: This 187 case is analogous to the current attacks [Attack]. Based on 188 prediction of the signed attributes Alice will be using and the 189 provided hash value and function. (It is expected that if 190 Alice uses a keyed hashing function as part of the signature 191 this attack will be more difficult.) 193 It should be noted that both of these attacks are considered to 194 be more difficult that the attack on the body since more 195 structure is designed into the data to be hashed than is 196 frequently found in the body and the data is shorter in length 197 than that of the body. 199 Schaad, Turner Expires June 2007 4 200 The successful prediction of the Signing-Time attribute is 201 expected to more difficult than with certificates as the time 202 would not generally be rounded. Time stamp services can make 203 this more unpredictable by using a random delay before issuing 204 the signature. 206 Allowing a third party to provide a hash value could 207 potentially make attack � simpler when keyed hash functions are 208 used since there is more data than can be modified without 209 changing the overall structure of the Signed Attribute 210 structure. 212 A 3rd type of attack is a generic downgrade attack. The premise is 213 to remove the 'better' signature to leave easier to attack 214 signature. 216 2.2 Attribute Design 218 The attribute will have the following characteristics: 220 1. Use CMS attribute structure; 221 2. Be computable before any signatures are applied; 222 3. Contain enough information to identify individual signatures 223 (i.e., a particular SignerInfo); and, 224 4. Contain enough information to resist collision, preimage, and 225 second premiage attacks. 227 3. Multiple Signature Indication 229 The MultipleSignatures attribute type specifies a pointer to a 230 signer�s other MultipleSignatures attribute(s). For example, if a 231 signer applies three signatures there must be two attribute values 232 for MultipleSignatures in each SignerInfo. The 1st SignerInfo 233 points to the 2nd and 3rd SignerInfos. The 2nd SignerInfo points to 234 the 1st and 3rd SignerInfos. The 3rd SignerInfo points to the 1st 235 and 2nd SignerInfos. 237 The MultipleSignatures attribute MUST be a signed attribute. The 238 number of attributes included in a SignerInfo is the number of 239 signatures applied by a signer less one. This attribute is multi- 240 valued and there MAY be more than one AttributeValue present. 242 The following object identifier identifies the 243 MultipleSignatures attribute: 245 id-aa-multipleSignatures OBJECT IDENTIFIER ::= { iso(1) member- 246 body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD } 248 Schaad, Turner Expires June 2007 5 249 multipleSignatures attribute values have the ASN.1 type 250 MultipleSignature: 252 MultipleSignature ::= SEQUENCE { 253 bodyHashAlg DigestAlgorithIdentifier, 254 signAlg SignatureAlgorithmIdentifier, 255 signAttrsHash SignAttrsHash, 256 cert ESSCertIDv2 OPTIONAL} 258 SignAttrsHash ::= SEQUENCE { 259 algID AlgorithmIdentifier, 260 hash OCTET STRING } 262 bodyHashAlg includes the digest algorithmIdentifier for the 263 referenced MultipleSignatures attribute. 265 signAlg includes the signature algorithmIdentifier for the refrenced 266 MultipleSignatures attribute. 268 signAttrsHash has two fields: 270 - aldId MUST match the digest algorithm for the SignerInfo in 271 which this MultipleSignatures attribute value is placed. 273 - hash is the hash value of the signedAttrs (see section 4.3). 275 cert is optional. It identities the certificate used to sign the 276 SignerInfo that contains the other MultipleSignatures attribute(s). 278 The following is an example: 280 SignedData 281 DigestAlg=sha1,sha256 282 SignerInfo1 SignerInfo2 283 digestAlg=sha1 digestAlg=sha256 284 signatureAlg=dsawithsha1 signatureAlg=ecdsawithsha256 285 signedAttrs= signedAttrs= 286 signingTime1 signingTime1 287 messageDigest1 messageDigest2 288 multiSig1= multiSig2= 289 bodyHash=sha256 bodyHash=sha1 290 signAlg=ecdsawithsha256 signAlg=dsawithsha1 291 signAttrsHash= signAttrsHash= 292 algID=sha1 algID=sha256 293 hash=value1 hash=value2 295 Schaad, Turner Expires June 2007 6 296 4. Message Generation and Processing 298 The following are the additional procedures for Message Generation 299 when using the MultipleSignatures attribute. These paragraphs track 300 with section 5.1-5.6 in [CMS]. 302 4.1 SignedData Type 304 The following steps MUST be followed by a signer when generating 305 SignedData: 307 - The signer MUST indicate the CMS version. 309 - The signer SHOULD include the digest algorithm used in 310 SignedData.digestAlgorithms, if the digest algorithm�s identifier 311 is not already present. 313 - The signer MUST include the encapContentInfo. Note the 314 encapContentInfo is the same for all signers in this SignedData. 316 - The signer SHOULD add certificates sufficient to contain 317 certificate paths from a recognized �root� or �top-level 318 certification authority� to the signer, if the signer�s 319 certificates are not already present. 321 - The signer MAY include the Certificate Revocation Lists (CRLs) 322 necessary to validate the digital signature, if the CRLs are not 323 already present. 325 - The signer MUST: 327 - Retain the existing signerInfo(s). 329 - Include their signerInfo. 331 4.2 EncapsulatedContentInfo Type 333 The procedures for generating EncapsulatedContentInfo are as 334 specified in section 5.2 of [CMS]. 336 4.3 SignerInfo Type 338 The procedures for generating a SignerInfo are as specified in 339 section 5.3 of [CMS] with the following addition: 341 The signer MUST include the MultipleSignatures attribute in 342 signedAttrs. 344 Schaad, Turner Expires June 2007 7 345 4.4 Message Digest Calculation Process 347 4.4.1 MultipleSignatures Signed Attribute Generation 349 The procedure for generating the MultipleSignatures signed attribute 350 are as follows: 352 1. All other signed attributes are placed in the respective 353 SignerInfo structures but the signatures are not yet computed for 354 the SignerInfo. 356 2. The MultipleSignature attributes are added to each of the 357 SignerInfo structures with the SignAttrsHash.hash field containing a 358 zero length octet string. 360 3. The correct SignAttrsHash.hash value is computed for each of the 361 SignerInfo structures. 363 4. After all hash values have been computed, the correct hash 364 values are placed into their respective SignAttrsHash.hash fields. 366 4.4.2 Message Digest calculation Process 368 The remaining procedures for generating the message-digest attribute 369 are as specified in section 5.4 of [CMS]. 371 4.5 Signature Generation Process 373 The procedures for signature generation are as specified in 374 section 5.5 of [CMS]. 376 4.6 Signature Verification Process 378 The procedures for signature verification are as specified in 379 section 5.6 of [CMS] with the following addition: 381 If the SignedData signerInfo includes the MultipleSignatures 382 attribute, the attribute�s values must be calculated as described in 383 section 4.4.1. 385 For every SignerInfo to be considered present for a given signer, 386 the number of MultipleSignatures AttributeValue(s) present in a 387 given SignerInfo MUST equal the number of SignerInfos for that 388 signer less one and the hash value present in each of the 390 Schaad, Turner Expires June 2007 8 391 MultipleSignatures AttributeValue(s) MUST match the output of the 392 message digest calculation from section 4.4.1 for each SignerInfo. 394 . The hash corresponding to the 1st SignerInfo must match the value 395 in the MultipleSignature attribute that points to the 1st SignerInfo 396 present in the 2nd and 3rd SignerInfos. The hash corresponding to 397 the 2nd SignerInfo must match the value in the MultipleSignature 398 attribute that points to the 2nd SignerInfo present in the 1st and 399 3rd SignerInfos. The hash corresponding to the 3rd SignerInfo must 400 match the value in the MultipleSignature attribute that points to 401 the 3rd SignerInfo present in the 1st and 2nd SignerInfos. 403 5.0 Signature Evaluation Processing 405 This section describes recommended processing of signatures when 406 there are more than one SignerInfo present in a message. This may 407 be due to either multiple SignerInfos being present in a singled 408 SignedData object, or there are multiple SignerData objects embedded 409 in each other. 411 The text in this section is non-normative. The processing described 412 is highly recommended, but is not forced. Changes in the processing 413 which have the same results with somewhat different orders of 414 processing is sufficient. 416 Order of operations: 418 1. Evaluate each SignerInfo object independently. 419 2. Combine the results of all SignerInfo objects at the same level 420 (i.e. attached to the same SignerData object) 421 3. Combine the results of the nested SignerData objects. Note that 422 this should ignore the presence of other CMS objects between the 423 SignedData objects. 425 5.1 Evaluation of a SignerInfo object 427 When evaluating a SignerInfo object, there are three different 428 pieces that need to be examined. The first is the mathematics of 429 the signature itself (i.e., can one actually successfully do the 430 computations and get the correct answer). This piece ends up with a 431 binary answer, either it succeeds or it fails there is no middle 432 ground. Not necessaryily true, what about an unevaluatable 433 algorithm - this is nether success nor failure. From the verifiers 434 perspective the answer is still fail since they can�t actuall do the 435 math - so I think it�s still binary. 437 The second is the validation of the source of the public key. For 438 CMS, this is generally determined by extracting the public key from 440 Schaad, Turner Expires June 2007 9 441 a certificate. The certificate needs to be evaluated. This is done 442 by the procedures outlined in [PKIX-CERT]. In addition to the 443 processing described in that document, there may be additional 444 requirements on certification path processing that are required by 445 the application in question. One such set of addition processing is 446 described in [SMIME-CERT]. One piece of information that is part of 447 this additional processing is local and application policy. The 448 output of this processing can actually be one of four different 449 states: Success, Failure, Indeterminate and Warning. The first 450 three states are described in [PKIX-CERT], Warning would be 451 generated when it is possible that some information is currently 452 acceptable, but may not be acceptable either in the near future or 453 under some circumstances. 455 The third part of the validation is local and application policy as 456 applied to the contents of the SignerInfo object. This would cover 457 such issues as the requirements on mandatory signed attributes or 458 requirements on signature algorithms. 460 -- state if you cannot do the math? 462 5.2 Evaluation of a SignerInfo Set 464 Combining the results of the individual SignerInfos into a result 465 for a SignedData object requires knowledge of the results for the 466 individual SignerInfo objects, the require application policy and 467 any local policies. The default processing if no other rules are 468 applied should be: 470 1. Segregate SignerInfo objects according to who signed. 471 2. Take the best result from the items in the grouping; this is the 472 result for the grouping. 473 3. Take the worst result from all of the groups; this is the result 474 for the SignedData object. 476 Application and local policy can affect each of the steps outlined 477 above. 479 In Step 1: 480 - If the subject name or subject alternative name(s) cannot be used 481 to determine if two SignerInfo objects were created by the same 482 identity, then applications need to specify how such matching is 483 to be done. As an example, the S/MIME message specification could 484 say that as long as the same RFC 822 name exists in either the 485 subject name or the subject alt name they are the same identity. 486 This would be true even if other information that did not match 487 existed in these fields. 488 - Some applications may specify that this step should be skipped; 489 this has the effect of making each SignerInfo object independent 490 of all other SignerInfo objects even if the signing identity is 492 Schaad, Turner Expires June 2007 10 493 the same. Applications that specify this need to be aware that 494 algorithm rollover will not work correctly in this case. 496 In Step 2: 497 - The major policy implication at this step is the treatment of and 498 order for the indeterminate states. In most cases this state 499 would be placed between the failure and warning states. Part of 500 the issue is the question of having a multi-state or a binary 501 answer as to success or failure of an evaluation. Not every 502 application can deal with the statement "try again later". It may 503 also be dependent on what the reason for the indeterminate state 504 is. It makes more sense to try again later if the problem is that 505 a CRL cannot be found than if you are not able to evaluate the 506 algorithm for the signature. 508 In Step 3: 509 - Very application dependent processing other options are: 510 o strip bad sig from the outside in - signed mail. 511 o strip bad sigs from the inside out - work flow. 512 - Modifications of the algorithm due to the presence of other types 513 of layers. I.e. EncryptedData/EnvelopedData or AuthenticatedData. 515 Implications/differences for AuthenticatedData. 517 Schaad, Turner Expires June 2007 11 518 6. Security Considerations 520 If another entity is providing hash to be signed, then ensure it is 521 a �trustworthy� source. 523 //** Needs more work 525 7 References 527 7.1 Normative References 529 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 530 3852, July 2004. 532 [PROFILE] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 533 X.509 Public Key Infrastructure Certificate and 534 Certificate Revocation List (CRL) Profile", RFC 3280, 535 April 2002. 537 [ESSCertID] Schaad, J., "ESS Update: Adding CertID Algorithm 538 Agility", draft-ietf-smime-esscertid-01.txt, April 2006. 540 7.2 Non-Normative References 542 [Attack] Hoffman, P., Schneier, B., �Attacks on Cryptographic 543 Hashes in Internet Protocols�, RFC 4270, November 2005. 545 Schaad, Turner Expires June 2007 12 546 Appendix A. ASN.1 Module 548 MultipleSignatures 549 { iso(1) member-body(2) us(840) rsadsi(113549) 550 pkcs(1) pkcs-9(9) smime(16) modules(0) multisig(TBD) } 552 DEFINITIONS IMPLICIT TAGS ::= 553 BEGIN 555 -- EXPORTS All 556 -- The types and values defined in this module are exported for use 557 -- in the other ASN.1 modules. Other applications may use them for 558 -- their own purposes. 560 IMPORTS 562 -- Imports from RFC 3280 [PROFILE], Appendix A.1 563 AlgorithmIdentifier 564 FROM PKIX1Explicit88 565 { iso(1) identified-organization(3) dod(6) 566 internet(1) security(5) mechanisms(5) pkix(7) 567 mod(0) pkix1-explicit(18) } 569 -- Imports from RFC 3852 [CMS], 12.1 570 DigestAlgorithmIdentifier, SignatureAlgorithmIdentifier 571 FROM CryptographicMessageSyntax2004 572 { iso(1) member-body(2) us(840) rsadsi(113549) 573 pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) } 575 -- Imports from RFC XXX [ESSCertID], Appendix A 576 ESSCertIDv2 577 FROM ExtendedSecurityServices-2006 578 { iso(1) member-body(2) us(840) rsadsi(113549) 579 pkcs(1) pkcs-9(9) smime(16) modules(0) ess-2006(TBD) } 581 ; 583 Schaad, Turner Expires June 2007 13 584 -- Section 3.0 586 id-multipleSignatures OBJECT IDENTIFIER ::= { iso(1) member-body(2) 587 us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD } 589 MultipleSignature ::= SEQUENCE { 590 bodyHashAlg DigestAlgorithIdentifier, 591 signAlg SignatureAlgorithmIdentifier, 592 signAttrsHash SignAttrsHash, 593 cert ESSCertIDv2 OPTIONAL } 595 SignAttrsHash ::= SEQUENCE { 596 algID AlgorithmIdentifier, 597 hash OCTET STRING } 599 END � of MultipleSignatures 601 Schaad, Turner Expires June 2007 14 602 Editor�s Address 604 Sean Turner 605 IECA, Inc. 607 Email: turners (at) ieca.com 609 Jim Schaad 610 Soaring Hawk Consulting 612 Email: jimsch (at) exmsft.com 614 Schaad, Turner Expires June 2007 15 615 Intellectual Property Statement 617 The IETF takes no position regarding the validity or scope of any 618 Intellectual Property Rights or other rights that might be claimed 619 to pertain to the implementation or use of the technology described 620 in this document or the extent to which any license under such 621 rights might or might not be available; nor does it represent that 622 it has made any independent effort to identify any such rights. 623 Information on the procedures with respect to rights in RFC 624 documents can be found in BCP 78 and BCP 79. 626 Copies of IPR disclosures made to the IETF Secretariat and any 627 assurances of licenses to be made available, or the result of an 628 attempt made to obtain a general license or permission for the use 629 of such proprietary rights by implementers or users of this 630 specification can be obtained from the IETF on-line IPR repository 631 at http://www.ietf.org/ipr. 633 The IETF invites any interested party to bring to its attention any 634 copyrights, patents or patent applications, or other proprietary 635 rights that may cover technology that may be required to implement 636 this standard. Please address the information to the IETF at ietf- 637 ipr@ietf.org. 639 Disclaimer of Validity 641 This document and the information contained herein are provided on 642 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 643 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 644 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 645 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 646 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 647 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 649 Copyright Statement 651 Copyright (C) The Internet Society (2006). 653 This document is subject to the rights, licenses and restrictions 654 contained in BCP 78, and except as set forth therein, the authors 655 retain all their rights. 657 Acknowledgment 659 Funding for the RFC Editor function is currently provided by the 660 Internet Society. 662 Schaad, Turner Expires June 2007 16