SMIME Working Group Sean Turner, IECA Internet Draft Jim Schaad, Soaring Hawk Expires June 4, 2007 December 4, 2006 Multiple Signatures in S/MIME draft-ietf-smime-multisig-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 4, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract CMS SignedData includes the SignerInfo structure to convey per- signer information. SignedData supports multiple signers and multiple signature algorithms per-signer with multiple SignerInfo structures. If a signer attaches more than one SignerInfo, there are concerns that an attacker could perform a downgrade attack by removing the SignerInfo(s) with the 'stronger' algorithm(s). This document defines a signed attribute, its generation rules, and its processing rules to allow signers to convey multiple SignerInfo while protecting against downgrade attacks. Additionally, this attribute may assist during periods of algorithm migration. Schaad, Turner Expires June 2007 1 Internet-Draft Multiple Signatures in S/MIME December 2006 1 Introduction The Cryptographic Message Syntax (CMS), see [CMS], defined SignerInfo to provide data necessary for relying parties to verify the signer’s digital signature, which is also include in the SignerInfo structure. Signers include more than one SignerInfo in a SignedData if they use different digest or signature algorithms. Each SignerInfo exists independently and new SignerInfo structures can be added or an existing one(s) removed without perturbing the remaining signature(s). The concern is that if an attacker successfully attacked a hash or signature algorithm; the attacker could remove all SignerInfo structures except the SignerInfo with the successfully attacked hash or signature algorithm; the relying party is then left with the attacked SignerInfo even though the relying party supported more than just the attacked hash or signature algorithm. A solution is to have signers include a pointer to all the signer’s SignerInfo structures. If an attacker removes any SignerInfo, then relying parties will be aware that an attacker has removed one or more SignerInfo. Note this attribute ought not be confused with the countersignature attribute, see 11.4 of [CMS], as this is not intended to sign over an existing signature rather it is to provide a pointer to additional signer’s signatures that are all at the same level. That is countersignature provides a serial signature while the attribute defined herein provides pointers to parallel signature by the same signer. 1.1 Requirements Terminology Though this document is not an Internet Draft, we use the convention that the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [MUSTSHOULD]. 1.2 Discussion This draft is being discussed on the 'ietf-smime' mailing list. To subscribe, send a message to ietf-smime-request@imc.org with the single word subscribe in the body of the message. There is a Web site for the mailing list at . Schaad, Turner Expires June 2007 2 Internet-Draft Multiple Signatures in S/MIME December 2006 2. Rationale 2.1 Attacks The following types of resistance against known attacks, see [ATTACK], is needed: 1) Collision Resistance: Find x and y where x != y and H(x) = H(y) 2) Preimage Resistance: Given y, find x where H(x) = y 3) Second Preimage Resistance: Given y, find x where H(x) = H(y) Note: It is known that a collision resistance attack is simpler than a second preimage resistance attack, and it is presumed that a second preimage resistance attack is simplier than a preimage attack. Within a SignedInfo there are two places where hashes are applied and hence can be attacked: the Body and the SignedAttributes. The following outlines the entity that creates the hash, the entity that attacks the hash, and the type of resistance required: 1) Hash of the Body (i.e., the octets comprising the value of the encapContentInfo.eContent OCTET STRING omitting the tag and length octets - as per 5.4 of [CMS]). a) Alice creates the Body to be hashed: i) Alice attacks the hash: This would require a successful Collision Resistance attack. ii) Mallory attacks the hash: This would require a successful Second Preimage Reistance attack. b) Alice hashes a body provided by Bob: i) Alice attacks the hash: This would require a successful Second Preimage Attack. ii) Bob attacks the hash: This would require a successful Collision Resistance attack. This can be upgraded to requiring a successful Second Preimage Attack if Alice hash the ability to "change" the content of the body in some fashion. (One example would be to use a keyed hash function.) iii) Mallory attacks the hash: This would require a successful Second Preimage Attack. Schaad, Turner Expires June 2007 3 Internet-Draft Multiple Signatures in S/MIME December 2006 c) Alice signs using a hash value provided by Bob. (In this case Alice is presumed to never see the body in question.) i) Alice attacks hash: This would require a successful Preimage Attack. ii) Bob attacks hash: This would require a successful Collision Resistance attack. Unlike case (b), there is nothing that Alice can do to upgrade the attack required. iii) Mallory attacks the hash: This would require a success Preimage attack if the content is unavailable to Mallory and a successful Second Preimage attack if the content is available to Mallory. 2) Hash of SignedAttributes (i.e., the complete DER encoding of the SignedAttrs value contained in the signedAttrs field - as per 5.4 of [CMS]). There is a difference between hashing the body and hashing the SignedAttrs value in that one SHOULD NOT accept a sequence of attributes to be signed from a third party. In fact one SHOULD NOT accept attributes to be included in the signed attributes list from a third party. The attributes are about the signature you are applying and not about the body. If there is meta-information that needs to be attached to the body by a third party then they need to provide their own signature and you need to be doing a countersignature. (Note: the fact that the signature is to be used as a countersignature is a piece of information that should be accepted, but it does not directly provide an attribute that is inserted in the attribute list.) a) Alice attacks the hash: This requires a successful Collision Resistance Attack. b) Mallory attacks the hash: This requires a successful Second Preimage Resistance attack. c) Bob attacks the hash and provides the body hash used: This case is analogous to the current attacks [Attack]. Based on prediction of the signed attributes Alice will be using and the provided hash value and function. (It is expected that if Alice uses a keyed hashing function as part of the signature this attack will be more difficult.) It should be noted that both of these attacks are considered to be more difficult that the attack on the body since more structure is designed into the data to be hashed than is frequently found in the body and the data is shorter in length than that of the body. Schaad, Turner Expires June 2007 4 Internet-Draft Multiple Signatures in S/MIME December 2006 The successful prediction of the Signing-Time attribute is expected to more difficult than with certificates as the time would not generally be rounded. Time stamp services can make this more unpredictable by using a random delay before issuing the signature. Allowing a third party to provide a hash value could potentially make attack © simpler when keyed hash functions are used since there is more data than can be modified without changing the overall structure of the Signed Attribute structure. A 3rd type of attack is a generic downgrade attack. The premise is to remove the 'better' signature to leave easier to attack signature. 2.2 Attribute Design The attribute will have the following characteristics: 1. Use CMS attribute structure; 2. Be computable before any signatures are applied; 3. Contain enough information to identify individual signatures (i.e., a particular SignerInfo); and, 4. Contain enough information to resist collision, preimage, and second premiage attacks. 3. Multiple Signature Indication The MultipleSignatures attribute type specifies a pointer to a signer’s other MultipleSignatures attribute(s). For example, if a signer applies three signatures there must be two attribute values for MultipleSignatures in each SignerInfo. The 1st SignerInfo points to the 2nd and 3rd SignerInfos. The 2nd SignerInfo points to the 1st and 3rd SignerInfos. The 3rd SignerInfo points to the 1st and 2nd SignerInfos. The MultipleSignatures attribute MUST be a signed attribute. The number of attributes included in a SignerInfo is the number of signatures applied by a signer less one. This attribute is multi- valued and there MAY be more than one AttributeValue present. The following object identifier identifies the MultipleSignatures attribute: id-aa-multipleSignatures OBJECT IDENTIFIER ::= { iso(1) member- body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD } Schaad, Turner Expires June 2007 5 Internet-Draft Multiple Signatures in S/MIME December 2006 multipleSignatures attribute values have the ASN.1 type MultipleSignature: MultipleSignature ::= SEQUENCE { bodyHashAlg DigestAlgorithIdentifier, signAlg SignatureAlgorithmIdentifier, signAttrsHash SignAttrsHash, cert ESSCertIDv2 OPTIONAL} SignAttrsHash ::= SEQUENCE { algID AlgorithmIdentifier, hash OCTET STRING } bodyHashAlg includes the digest algorithmIdentifier for the referenced MultipleSignatures attribute. signAlg includes the signature algorithmIdentifier for the refrenced MultipleSignatures attribute. signAttrsHash has two fields: - aldId MUST match the digest algorithm for the SignerInfo in which this MultipleSignatures attribute value is placed. - hash is the hash value of the signedAttrs (see section 4.3). cert is optional. It identities the certificate used to sign the SignerInfo that contains the other MultipleSignatures attribute(s). The following is an example: SignedData DigestAlg=sha1,sha256 SignerInfo1 SignerInfo2 digestAlg=sha1 digestAlg=sha256 signatureAlg=dsawithsha1 signatureAlg=ecdsawithsha256 signedAttrs= signedAttrs= signingTime1 signingTime1 messageDigest1 messageDigest2 multiSig1= multiSig2= bodyHash=sha256 bodyHash=sha1 signAlg=ecdsawithsha256 signAlg=dsawithsha1 signAttrsHash= signAttrsHash= algID=sha1 algID=sha256 hash=value1 hash=value2 Schaad, Turner Expires June 2007 6 Internet-Draft Multiple Signatures in S/MIME December 2006 4. Message Generation and Processing The following are the additional procedures for Message Generation when using the MultipleSignatures attribute. These paragraphs track with section 5.1-5.6 in [CMS]. 4.1 SignedData Type The following steps MUST be followed by a signer when generating SignedData: - The signer MUST indicate the CMS version. - The signer SHOULD include the digest algorithm used in SignedData.digestAlgorithms, if the digest algorithm’s identifier is not already present. - The signer MUST include the encapContentInfo. Note the encapContentInfo is the same for all signers in this SignedData. - The signer SHOULD add certificates sufficient to contain certificate paths from a recognized “root” or “top-level certification authority” to the signer, if the signer’s certificates are not already present. - The signer MAY include the Certificate Revocation Lists (CRLs) necessary to validate the digital signature, if the CRLs are not already present. - The signer MUST: - Retain the existing signerInfo(s). - Include their signerInfo. 4.2 EncapsulatedContentInfo Type The procedures for generating EncapsulatedContentInfo are as specified in section 5.2 of [CMS]. 4.3 SignerInfo Type The procedures for generating a SignerInfo are as specified in section 5.3 of [CMS] with the following addition: The signer MUST include the MultipleSignatures attribute in signedAttrs. Schaad, Turner Expires June 2007 7 Internet-Draft Multiple Signatures in S/MIME December 2006 4.4 Message Digest Calculation Process 4.4.1 MultipleSignatures Signed Attribute Generation The procedure for generating the MultipleSignatures signed attribute are as follows: 1. All other signed attributes are placed in the respective SignerInfo structures but the signatures are not yet computed for the SignerInfo. 2. The MultipleSignature attributes are added to each of the SignerInfo structures with the SignAttrsHash.hash field containing a zero length octet string. 3. The correct SignAttrsHash.hash value is computed for each of the SignerInfo structures. 4. After all hash values have been computed, the correct hash values are placed into their respective SignAttrsHash.hash fields. 4.4.2 Message Digest calculation Process The remaining procedures for generating the message-digest attribute are as specified in section 5.4 of [CMS]. 4.5 Signature Generation Process The procedures for signature generation are as specified in section 5.5 of [CMS]. 4.6 Signature Verification Process The procedures for signature verification are as specified in section 5.6 of [CMS] with the following addition: If the SignedData signerInfo includes the MultipleSignatures attribute, the attribute’s values must be calculated as described in section 4.4.1. For every SignerInfo to be considered present for a given signer, the number of MultipleSignatures AttributeValue(s) present in a given SignerInfo MUST equal the number of SignerInfos for that signer less one and the hash value present in each of the Schaad, Turner Expires June 2007 8 Internet-Draft Multiple Signatures in S/MIME December 2006 MultipleSignatures AttributeValue(s) MUST match the output of the message digest calculation from section 4.4.1 for each SignerInfo. . The hash corresponding to the 1st SignerInfo must match the value in the MultipleSignature attribute that points to the 1st SignerInfo present in the 2nd and 3rd SignerInfos. The hash corresponding to the 2nd SignerInfo must match the value in the MultipleSignature attribute that points to the 2nd SignerInfo present in the 1st and 3rd SignerInfos. The hash corresponding to the 3rd SignerInfo must match the value in the MultipleSignature attribute that points to the 3rd SignerInfo present in the 1st and 2nd SignerInfos. 5.0 Signature Evaluation Processing This section describes recommended processing of signatures when there are more than one SignerInfo present in a message. This may be due to either multiple SignerInfos being present in a singled SignedData object, or there are multiple SignerData objects embedded in each other. The text in this section is non-normative. The processing described is highly recommended, but is not forced. Changes in the processing which have the same results with somewhat different orders of processing is sufficient. Order of operations: 1. Evaluate each SignerInfo object independently. 2. Combine the results of all SignerInfo objects at the same level (i.e. attached to the same SignerData object) 3. Combine the results of the nested SignerData objects. Note that this should ignore the presence of other CMS objects between the SignedData objects. 5.1 Evaluation of a SignerInfo object When evaluating a SignerInfo object, there are three different pieces that need to be examined. The first is the mathematics of the signature itself (i.e., can one actually successfully do the computations and get the correct answer). This piece ends up with a binary answer, either it succeeds or it fails there is no middle ground. Not necessaryily true, what about an unevaluatable algorithm - this is nether success nor failure. From the verifiers perspective the answer is still fail since they can’t actuall do the math - so I think it’s still binary. The second is the validation of the source of the public key. For CMS, this is generally determined by extracting the public key from Schaad, Turner Expires June 2007 9 Internet-Draft Multiple Signatures in S/MIME December 2006 a certificate. The certificate needs to be evaluated. This is done by the procedures outlined in [PKIX-CERT]. In addition to the processing described in that document, there may be additional requirements on certification path processing that are required by the application in question. One such set of addition processing is described in [SMIME-CERT]. One piece of information that is part of this additional processing is local and application policy. The output of this processing can actually be one of four different states: Success, Failure, Indeterminate and Warning. The first three states are described in [PKIX-CERT], Warning would be generated when it is possible that some information is currently acceptable, but may not be acceptable either in the near future or under some circumstances. The third part of the validation is local and application policy as applied to the contents of the SignerInfo object. This would cover such issues as the requirements on mandatory signed attributes or requirements on signature algorithms. -- state if you cannot do the math? 5.2 Evaluation of a SignerInfo Set Combining the results of the individual SignerInfos into a result for a SignedData object requires knowledge of the results for the individual SignerInfo objects, the require application policy and any local policies. The default processing if no other rules are applied should be: 1. Segregate SignerInfo objects according to who signed. 2. Take the best result from the items in the grouping; this is the result for the grouping. 3. Take the worst result from all of the groups; this is the result for the SignedData object. Application and local policy can affect each of the steps outlined above. In Step 1: - If the subject name or subject alternative name(s) cannot be used to determine if two SignerInfo objects were created by the same identity, then applications need to specify how such matching is to be done. As an example, the S/MIME message specification could say that as long as the same RFC 822 name exists in either the subject name or the subject alt name they are the same identity. This would be true even if other information that did not match existed in these fields. - Some applications may specify that this step should be skipped; this has the effect of making each SignerInfo object independent of all other SignerInfo objects even if the signing identity is Schaad, Turner Expires June 2007 10 Internet-Draft Multiple Signatures in S/MIME December 2006 the same. Applications that specify this need to be aware that algorithm rollover will not work correctly in this case. In Step 2: - The major policy implication at this step is the treatment of and order for the indeterminate states. In most cases this state would be placed between the failure and warning states. Part of the issue is the question of having a multi-state or a binary answer as to success or failure of an evaluation. Not every application can deal with the statement "try again later". It may also be dependent on what the reason for the indeterminate state is. It makes more sense to try again later if the problem is that a CRL cannot be found than if you are not able to evaluate the algorithm for the signature. In Step 3: - Very application dependent processing other options are: o strip bad sig from the outside in - signed mail. o strip bad sigs from the inside out - work flow. - Modifications of the algorithm due to the presence of other types of layers. I.e. EncryptedData/EnvelopedData or AuthenticatedData. Implications/differences for AuthenticatedData. Schaad, Turner Expires June 2007 11 Internet-Draft Multiple Signatures in S/MIME December 2006 6. Security Considerations If another entity is providing hash to be signed, then ensure it is a “trustworthy” source. //** Needs more work 7 References 7.1 Normative References [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004. [PROFILE] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [ESSCertID] Schaad, J., "ESS Update: Adding CertID Algorithm Agility", draft-ietf-smime-esscertid-01.txt, April 2006. 7.2 Non-Normative References [Attack] Hoffman, P., Schneier, B., “Attacks on Cryptographic Hashes in Internet Protocols”, RFC 4270, November 2005. Schaad, Turner Expires June 2007 12 Internet-Draft Multiple Signatures in S/MIME December 2006 Appendix A. ASN.1 Module MultipleSignatures { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) multisig(TBD) } DEFINITIONS IMPLICIT TAGS ::= BEGIN -- EXPORTS All -- The types and values defined in this module are exported for use -- in the other ASN.1 modules. Other applications may use them for -- their own purposes. IMPORTS -- Imports from RFC 3280 [PROFILE], Appendix A.1 AlgorithmIdentifier FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) pkix1-explicit(18) } -- Imports from RFC 3852 [CMS], 12.1 DigestAlgorithmIdentifier, SignatureAlgorithmIdentifier FROM CryptographicMessageSyntax2004 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) } -- Imports from RFC XXX [ESSCertID], Appendix A ESSCertIDv2 FROM ExtendedSecurityServices-2006 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) ess-2006(TBD) } ; Schaad, Turner Expires June 2007 13 Internet-Draft Multiple Signatures in S/MIME December 2006 -- Section 3.0 id-multipleSignatures OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD } MultipleSignature ::= SEQUENCE { bodyHashAlg DigestAlgorithIdentifier, signAlg SignatureAlgorithmIdentifier, signAttrsHash SignAttrsHash, cert ESSCertIDv2 OPTIONAL } SignAttrsHash ::= SEQUENCE { algID AlgorithmIdentifier, hash OCTET STRING } END – of MultipleSignatures Schaad, Turner Expires June 2007 14 Internet-Draft Multiple Signatures in S/MIME December 2006 Editor’s Address Sean Turner IECA, Inc. Email: turners (at) ieca.com Jim Schaad Soaring Hawk Consulting Email: jimsch (at) exmsft.com Schaad, Turner Expires June 2007 15 Internet-Draft Multiple Signatures in S/MIME December 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Schaad, Turner Expires June 2007 16