S/MIME WG                                             Sean Turner, IECA
Internet Draft                                 Jim Schaad, Soaring Hawk
Intended Status: Standard Track                           June 26,                           July 24, 2007
Expires: December 26, 2007 January 24, 2008

                      Multiple Signatures in S/MIME
                     draft-ietf-smime-multisig-01.txt
                     draft-ietf-smime-multisig-02.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.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on December 26, 2007. January 24, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

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 'strong' algorithm(s). This document defines
   the multiple-signatures 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.

Conventions used in this document

   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 [RFC2119].

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 <http://www.imc.org/ietf-smime/>.

Table of Contents

   1. Introduction...................................................3 Introduction......................................... 3
   2. Rationale......................................................3 Rationale........................................... 3
      2.1. Attacks...................................................3
      2.2. Hashes in CMS.............................................4
      2.3. Downgrade Attack..........................................6
      2.4. Attribute Design Requirements.............................6 Requirements....................... 4
   3. Multiple Signature Indication..................................7 Indication........................... 5
   4. Message Generation and Processing..............................8 Processing ....................... 6
      4.1. SignedData Type...........................................8 Type.................................. 6
      4.2. EncapsulatedContentInfo Type..............................9 Type ....................... 7
      4.3. SignerInfo Type...........................................9 Type.................................. 7
      4.4. Message Digest Calculation Process........................9 Process .................. 7
         4.4.1. multiple-signatures Signed Attribute Generation......9 Generation.... 7
         4.4.2. Message Digest calculation Process..................10 Process.............. 8
      4.5. Signature Generation Process.............................10 Process ....................... 8
      4.6. Signature Verification Process...........................10 Process...................... 8
   5. Signature Evaluation Processing...............................10 Processing......................... 8
      5.1. Evaluation of a SignerInfo object........................11 object................... 9
      5.2. Evaluation of a SignerInfo Set...........................12 Set..................... 10
      5.3. Evaluation of a SignedData Set..................... 11
   6. Security Considerations.......................................13 Considerations............................... 11
   7. IANA Considerations...........................................13 Considerations.................................. 11
   8. References....................................................14 References......................................... 12
      8.1. Normative References.....................................14 References............................. 12
      8.2. Informative References...................................14 References........................... 12
   Appendix A. ASN.1 Module.........................................15 Module................................ 13
   Appendix B. Background.................................. 15
      B.1. Attacks........................................ 15
      B.2. Hashes in CMS................................... 15

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.

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 rationale for this specification is known to protect against downgrade
   attacks that remove the 'strong' signature to leave the 'weak'
   signature, which has presumably been successfully attacked.  If a collision resistance attack is simpler CMS
   object has multiple SignerInfos, then the attacker, whether it be
   Alice, Bob, or Mallory, can remove SignerInfos without the relying
   party being aware that more than one was generated.

   Removal of a second preimage resistance attack, and SignerInfo does not render the signature invalid nor
   does it is presumed that constitute an error.  In the following scenario: a second
   preimage resistance attack is simplier than signer
   generates a preimage attack.

2.2. Hashes in CMS

   Within SignedData with two SignerInfo objects one with a SignedInfo 'weak'
   algorithm and one with a 'strong' algorithm; there are two places where hashes three types of
   relying parties:

     1) Those that support only a 'weak' algorithm.  If both SignerInfo
     objects are applied and
   hence can be attacked: present, the Body and relying party processes the SignedAttributes.  The
   following outlines algorithm it
     supports.  If both SignerInfo objects are not present, the entity relying
     party can easily determine that creates the hash, another SignerInfo has been
     removed, but not changed. In both cases, if the entity that
   attacks the hash, and 'weak' signature
     verifies the type of resistance required:

     1) Hash of relying party MAY consider the Body (i.e., signature valid.

     2) Those that support only a 'strong' algorithm.  If both
     SignerInfo objects are present, the octets comprising relying party processes the value of
     algorithm it supports.  If both SignerInfo objects are not present,
     the
     encapContentInfo.eContent OCTET STRING omitting relying party can easily determine that another SignerInfo has
     been removed, but the tag and length
     octets - as per 5.4 of [CMS]).

      a) Alice creates relying party doesn't care.  In both cases,
     if the Body to be hashed:

        i) Alice attacks 'strong' signature verifies the hash: This would require a successful
        Collision Resistance attack.

        ii) Mallory attacks relying party MAY consider
     the hash: This would require signature valid.

     3) Those that support both a successful
        Second Preimage Reistance attack.

      b) Alice hashes 'weak' algorithm and a body provided by Bob:

        i) Alice attacks 'strong'
     algorithm.  If both SignerInfo objects are present, the hash:  This would require a successful
        Second Preimage Attack.

        ii) Bob attacks relying
     party processes both algorithms.  If both SignerInfo objects are
     not present, the hash:  This would require a successful
        Collision Resistance attack.  This relying party can be upgraded to requiring
        a successful Second Preimage Attack if Alice hash the ability
        to "change" easily determine that another
     SignerInfo has been removed.

   Local policy MAY dictate that the content removal of the body 'strong' algorithm
   results 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.

      c) Alice signs using a hash value provided by Bob.  (In this case
      Alice is presumed to never see an invalid signature.  See section 5 for further
   processing.

2.1. Attribute Design Requirements

   The attribute will have the body in question.)

        i) Alice attacks hash: This would require 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 successful Preimage
        Attack.

        ii) Bob attacks hash: This would require particular SignerInfo); and,

     4) Contain enough information to resist collision, preimage, and
     second premiage attacks.

3. Multiple Signature Indication

   The multiple-signatures attribute type specifies a successful Collision
        Resistance attack.  Unlike case (b), there is nothing that
        Alice can do pointer to upgrade the attack required.

        iii) Mallory attacks the hash:  This would require a success
        Preimage attack
   signer's other multiple-signatures attribute(s). For example, if the content is unavailable a
   signer applies three signatures there must be two attribute values
   for multiple-signatures in each SignerInfo.  The 1st SignerInfo
   points to Mallory the 2nd and a
        successful Second Preimage attack if 3rd SignerInfos.  The 2nd SignerInfo points to
   the content is available 1st and 3rd SignerInfos. The 3rd SignerInfo points to Mallory.

     2) Hash of SignedAttributes (i.e., the complete DER encoding 1st and
   2nd SignerInfos.

   The multiple-signatures attribute MUST be a signed attribute. The
   number of the
     SignedAttrs value contained attributes included in a SignerInfo is the signedAttrs field - as per 5.4 number of [CMS]).

   There is
   signatures applied by a difference between hashing the body signer less one. This attribute is multi-
   valued and hashing the
   SignedAttrs value in that there MAY be more than 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. AttributeValue present.
   The attributes are about following object identifier identifies the signature you are applying
   and not about multiple-signatures
   attribute:

     id-aa-multipleSignatures OBJECT IDENTIFIER ::= { iso(1)
     member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD }

   multiple-signatures attribute values have the body.  If there is meta-information that needs to
   be attached to ASN.1 type
   MultipleSignatures:

     MultipleSignatures ::= SEQUENCE {
       bodyHashAlg     DigestAlgorithIdentifier,
       signAlg         SignatureAlgorithmIdentifier,
       signAttrsHash   SignAttrsHash,
       cert            ESSCertIDv2 OPTIONAL}

     SignAttrsHash ::= SEQUENCE {
       algID            AlgorithmIdentifier,
       hash             OCTET STRING }

   The fields in MultipleSignatures have the body by a third party then they need to provide
   their own signature and you need to be doing a countersignature.
   (Note: following meaning:

     - bodyHashAlg includes the fact that digest algorithmIdentifier for 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
     referenced multiple-signatures attribute.

     - signAlg includes the
   attribute list.)

     a) Alice attacks signature algorithmIdentifier for the hash: This requires a successful Collision
     Resistance Attack.

     b) Mallory attacks
     referenced multiple-signatures attribute.

     - signAttrsHash has two fields:

      -- aldId MUST match the hash: This requires a successful Second
     Preimage Resistance attack.

     c) Bob attacks digest algorithm for the SignerInfo in
      which this multiple-signatures attribute value is placed.

      -- hash and provides is the body hash used:  This case value of the signedAttrs (see section 4.3).

     - cert is analogous optional. It identities the certificate used to sign 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
     SignerInfo that if Alice uses a keyed
     hashing function as part of contains the signature this attack will be more
     difficult.) other multiple-signatures
     attribute(s).  It should be noted that both of these attacks are considered to MUST be
   more difficult that present if the attack on fields in the body since more structure is
   designed into other
     multiple-signatures attribute(s) are the data to be hashed than same.

   The following is frequently found 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

4. Message Generation and Processing

   The following are the additional procedures for Message Generation
   when using the multiple-signatures 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
   body and CMS version.

     - The signer SHOULD include the data is shorter digest algorithm used in length than that of
     SignedData.digestAlgorithms, if the body. digest algorithm's identifier
     is not already present.

     - The successful prediction of signer MUST include the Signing-Time attribute encapContentInfo. Note the
     encapContentInfo is expected
   to more difficult than with certificates as the time would not
   generally be rounded.  Time stamp services can make same for all signers in this more
   unpredictable by using a random delay before issuing the signature.

   Allowing a third party SignedData.

     - The signer SHOULD add certificates sufficient to provide contain
     certificate paths from 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 recognized "root" or "top-level
     certification authority" to the Signed Attribute structure.

2.3. Downgrade Attack

   For a generic downgrade attack: signer, if the premise is to remove signer's
     certificates are not already present.

     - The signer MAY include the 'strong'
   signature Certificate Revocation Lists (CRLs)
     necessary to leave validate the 'weak' digital signature, which has presumably been
   successfully attacked.  If a CMS object has multiple SignerInfos,
   then if the attacker, whether it be Alice, Bob, or Mallory, can remove
   SignerInfos without CRLs are not
     already present.

     - The signer MUST:

       -- Retain the relying party being aware that more than one
   was generated.

   Removal 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 does not render the signature invalid nor
   does it constitute an error.  In are as specified in
   section 5.3 of [CMS] with the following scenario: a addition:

   The signer
   generates a SignedData with two SignerInfo objects one with a 'weak'
   algorithm and one with a 'strong' algorithm; there MUST include the multiple-signatures attribute in
   signedAttrs.

4.4. Message Digest Calculation Process

4.4.1. multiple-signatures Signed Attribute Generation

   The procedure for generating the multiple-signatures signed attribute
   are three types of
   relying parties: as follows:

     1) Those that support only a 'weak' algorithm.  If both SignerInfo
     objects All other signed attributes are present, the relying party processes placed in the algorithm it
     supports.  If both respective
     SignerInfo objects structures but the signatures are not present, the relying
     party can easily determine that another SignerInfo has been
     removed, but not changed. In both cases, if the 'weak' signature
     verifies the relying party MAY consider yet computed for
     the signature valid. SignerInfo.

     2) Those that support only a 'strong' algorithm.  If both
     SignerInfo objects The multiple-signatures attributes are present, the relying party processes added to each of the
     algorithm it supports.  If both
     SignerInfo objects are not present, structures with the SignAttrsHash.hash field containing
     a zero length octet string.

     3) The correct SignAttrsHash.hash value is computed for each of the relying party can easily determine that another
     SignerInfo has structures.

     4) After all hash values have been removed, but computed, the relying party doesn't care.  In both cases,
     if correct hash
     values are placed into their respective SignAttrsHash.hash fields.

4.4.2. Message Digest calculation Process

   The remaining procedures for generating the 'strong' message-digest attribute
   are as specified in section 5.4 of [CMS].

4.5. Signature Generation Process

   The procedures for signature verifies the relying party MAY consider
     the generation are as specified in section
   5.5 of [CMS].

4.6. Signature Verification Process

   The procedures for signature valid.

     3) Those that support both a 'weak' algorithm and a 'strong'
     algorithm.  If both SignerInfo objects verification are present, as specified in section
   5.6 of [CMS] with the relying
     party processes both algorithms. following addition:

   If both SignerInfo objects are
     not present, the relying party can easily determine that another
     SignerInfo has been removed.

   Local policy MAY dictate that SignedData signerInfo includes the removal of multiple-signatures
   attribute, the 'strong' algorithm
   results attribute's values must be calculated as described in an invalid signature.  See
   section 5 for further
   processing.

2.4. Attribute Design Requirements

   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 multiple-signatures attribute type specifies a pointer 4.4.1.

   For every SignerInfo to be considered present for a
   signer's other multiple-signatures attribute(s). For example, if given signer, the
   number of MultipleSignatures AttributeValue(s) present in a
   signer applies three signatures there must be two attribute values given
   SignerInfo MUST equal the number of SignerInfos for multiple-signatures that signer less
   one and the hash value present in each of the 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 multiple-signatures 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 multiple-signatures
   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 multiple-signatures attribute that points to
   the 3rd SignerInfo present in the 1st and 2nd SignerInfos.

   The multiple-signatures attribute MUST be a signed attribute. The
   number of attributes included in a SignerInfo is the number

5. Signature Evaluation Processing

   This section describes recommended processing of signatures applied by a signer less one. This attribute is multi-
   valued and when
   there MAY be are more than one AttributeValue present.
   The following object identifier identifies the multiple-signatures
   attribute:

     id-aa-multipleSignatures OBJECT IDENTIFIER ::= { iso(1)
     member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD }

   multiple-signatures attribute values have the ASN.1 type
   MultipleSignatures:

     MultipleSignatures ::= SEQUENCE {
       bodyHashAlg     DigestAlgorithIdentifier,
       signAlg         SignatureAlgorithmIdentifier,
       signAttrsHash   SignAttrsHash,
       cert            ESSCertIDv2 OPTIONAL}

     SignAttrsHash ::= SEQUENCE {
       algID            AlgorithmIdentifier,
       hash             OCTET STRING } 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 fields text in this section is non-normative.  The processing described
   is highly recommended, but is not forced.  Changes in MultipleSignatures have the following meaning:

     bodyHashAlg includes processing
   which have the digest algorithmIdentifier for same results with somewhat different orders of
   processing is sufficient.

   Order of operations:

     1) Evaluate each SignerInfo object independently.

     2) Combine the
     referenced multiple-signatures attribute.

     signAlg includes results of all SignerInfo objects at the signature algorithmIdentifier for same level
     (i.e. attached to the
     referenced multiple-signatures attribute.

     signAttrsHash has two fields:

      - aldId MUST match same SignerData object)

     3) Combine the digest algorithm for results of the SignerInfo in
      which nested SignerData objects.  Note that
     this multiple-signatures attribute value is placed.

      - hash is should ignore the hash value presence of other CMS objects between the signedAttrs (see section 4.3).

     cert
     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 piece is optional. It identities the certificate used to sign mathematics of the
     SignerInfo that contains signature itself (i.e., can
   one actually successfully do the other multiple-signatures
     attribute(s).  It MUST be present if computations and get the fields in correct
   answer).  This result is one of three results.  The mathematics
   succeeds, the other
     multiple-signatures attribute(s) are mathematics fails, or the same. mathematics cannot be
   evaluated.  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

4. Message Generation and Processing

   The following are the additional procedures for Message Generation
   when using the multiple-signatures 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 type of things that lead to the digest last state are non-
   implementation of an algorithm used in
     SignedData.digestAlgorithms, if or required inputs, such as the digest algorithm's identifier
     is not already present.

     - public
   key, are missing.

   The signer MUST include second piece is the encapContentInfo. Note validation of the
     encapContentInfo is source of the same for all signers in public key.
   For CMS, this SignedData.

     - The signer SHOULD add certificates sufficient to contain
     certificate paths is generally determined by extracting the public key
   from a recognized "root" or "top-level
     certification authority" to the signer, if the signer's
     certificates are not already present.

     - certificate.  The signer MAY include the Certificate Revocation Lists (CRLs)
     necessary certificate needs to validate be evaluated.  This is
   done by the digital signature, if procedures outlined in [PKIX-CERT].  In addition to the CRLs
   processing described in that document, there may be additional
   requirements on certification path processing that are not
     already present.

     - The signer MUST:

       -- Retain required by
   the existing signerInfo(s).

       -- Include their signerInfo.

4.2. EncapsulatedContentInfo Type

   The procedures for generating EncapsulatedContentInfo are as
   specified application in section 5.2 question.  One such set of [CMS].

4.3. SignerInfo Type

   The procedures for generating a SignerInfo are as specified addition processing is
   described in
   section 5.3 [SMIME-CERT].  One piece of [CMS] with the following addition: information that is part of
   this additional processing is local and application policy.  The signer MUST include the multiple-signatures attribute in
   signedAttrs.

4.4. Message Digest Calculation Process

4.4.1. multiple-signatures Signed Attribute Generation
   output of this processing can actually be one of four different
   states:  Success, Failure, Indeterminate and Warning.  The procedure for generating the multiple-signatures signed attribute
   are as follows:

     1) All other signed attributes first
   three states are placed described in the respective
     SignerInfo structures [PKIX-CERT], Warning would be generated
   when it is possible that some information is currently acceptable,
   but the signatures are may not yet computed for be acceptable either in the SignerInfo.

     2) near future or under some
   circumstances.

   The multiple-signatures attributes are added third piece of the validation is local and application policy as
   applied to each the contents of the SignerInfo structures with object.  This would cover
   such issues as the SignAttrsHash.hash field containing requirements on mandatory signed attributes or
   requirements on signature algorithms.

5.2. Evaluation of a zero length octet string.

     3) The correct SignAttrsHash.hash value is computed SignerInfo Set

   Combining the results of the individual SignerInfos into a result for each
   a SignedData object requires knowledge of the results for the
   individual SignerInfo structures.

     4) After all hash values have been computed, objects, the correct hash
     values are placed into their respective SignAttrsHash.hash fields.

4.4.2. Message Digest calculation Process require application policy and any
   local policies.  The remaining procedures for generating the message-digest attribute default processing if no other rules 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 applied
   should be:

     1) Group the SignedData signerInfo includes SignerInfo objects by the multiple-signatures
   attribute, signer.

     2) Take 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, best result from each signer.

     3) Take the
   number worst result from all of MultipleSignatures AttributeValue(s) present in a given
   SignerInfo MUST equal the number of SignerInfos different signers; this is
     the result for that signer less
   one and the hash value present in SignedData object.

   Application and local policy can affect each of the MultipleSignatures
   AttributeValue(s) MUST match the output of steps outlined
   above.

   In Step 1:

     - If the message digest
   calculation from section 4.4.1 for each SignerInfo.

   The hash corresponding subject name or subject alternative name(s) cannot be used
     to the 1st determine if two SignerInfo must match the value in objects were created by the multiple-signatures attribute that points same
     identity, then applications need to the 1st SignerInfo
   present in the 2nd and 3rd SignerInfos.  The hash corresponding specify how such matching is to
     be done.  As an example, the 2nd SignerInfo must match the value in the multiple-signatures
   attribute S/MIME message specification [MSG]
     could say that points to as long as the 2nd SignerInfo present same RFC 822 name exists in either
     the 1st and
   3rd SignerInfos. The hash corresponding to subject name or the 3rd SignerInfo must
   match subject alt name they are the value in the multiple-signatures attribute that points to
   the 3rd SignerInfo present in the 1st and 2nd SignerInfos.

5. Signature Evaluation Processing same
     identity.  This section describes recommended processing of signatures when
   there are more than one SignerInfo present would be true even if other information that did
     not match existed in a message.  This these fields.

     - Some applications may specify that this step should 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 skipped;
     this section is non-normative.  The processing described
   is highly recommended, but is not forced.  Changes in the processing
   which have has the same results with somewhat different orders of
   processing is sufficient.

   Order effect of operations:

     1) Evaluate making each SignerInfo object independently.

     2) Combine the results independent of
     all other SignerInfo objects at the same level
     (i.e. attached to the same SignerData object)

     3) Combine even if the results of signing identity is the nested SignerData objects.  Note
     same.  Applications that specify 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. aware that
     algorithm rollover will not work correctly in this case.

   In Step 2:

     - The first major policy implication at this step is the mathematics treatment of and
     order for the
   signature itself (i.e., can one actually successfully do indeterminate states.  In most cases this state would
     be placed between the
   computations failure and get warning states.  Part of the correct answer).  This piece ends up with
     issue is the question of having a
   binary answer, either it succeeds multi-state or it fails there is no middle
   ground. a binary answer as
     to success or failure of an evaluation.  Not necessaryily true, every application can
     deal with the statement "try again later".  It may also be
     dependent on what about an unevaluatable
   algorithm - this is nether success nor failure. From the verifiers
   perspective reason for the answer indeterminate state is.  It
     makes more sense to try again later if the problem is still fail since they can't actually do that a CRL
     cannot be found than if you are not able to evaluate the
   math algorithm
     for the signature.

   In Step 3:

     - so I think it's still binary. The second is same policy implications from Step 2 apply here.

5.3. Evaluation of a SignedData Set

   For simple applications, the validation requirement can be made that the result
   of evaluating a set of SignedData objects is the source worst outcome of the public key.  For
   CMS, this is generally determined by extracting
   items.  (I.e. one failure means the public key from a
   certificate.  The certificate needs entire item fails).  However not
   all applications will want to be evaluated.  This is done by have this behavior.

   A work flow application could work as follows:

      The second signer will modify the procedures outlined in [PKIX-CERT].  In addition to original content, keep the
   processing described in that document, there may be additional
   requirements on certification path processing
   original signature and then sign the message.  This means that are required by only
   the application in question.  One such set of addition processing outermost signature is
   described in [SMIME-CERT].  One piece of information that significance during evaluation.  The
   second signer is asserting that they successfully validated the inner
   signature as part of
   this additional processing is local and its processing.

   A Signed Mail application policy.  The
   output could work as follows:

   If signatures are added for the support of this processing [ESS] features, then the
   fact that an outer layer signature can actually be one of four different
   states:  Success, Failure, Indeterminate and Warning. treated as a non-
   significant failure.  The first
   three states are described in [PKIX-CERT], Warning would be generated
   when it only thing that matters is possible that some information the
   originator signature is currently acceptable,
   but may not valid.  This means that all outer layer
   signatures which fail can be acceptable either in stripped from the near future or under some
   circumstances.

   The third part of message prior to
   display leaving only the validation inner-most valid signature to be displayed.

6. Security Considerations

   If another entity is local and application policy as
   applied providing hash to the contents of the SignerInfo object. be signed, then ensure it is a
   "trustworthy" source.

   This would cover
   such issues as the requirements on mandatory signed attributes or
   requirements on signature algorithms.

   -- state attribute provides no protection 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 all of the results for the
   individual SignerInfo objects, algorithms used
   in the require application policy and any
   local policies.  The default processing if no other rules signer attribute are applied
   should be:

     1) Segregate SignerInfo objects according to who signed.

     2) Take the best result from the items 'cracked'.

   Protection against attacks in the grouping; this is the
     result for the grouping.

     3) Take the worst result from all of the groups; future are also not protected
   against.

   //** Needs more work

7. IANA Considerations

   None: All identifiers are already registered.  Please remove 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
   section prior 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 publication as the same an RFC.

8. References

8.1. Normative References

   [CMS]       Housley, R., "Cryptographic Message Syntax (CMS)", 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
               3852, July 2004.

   [ESSCertID] Schaad, J., "ESS Update: Adding CertID Algorithm
               Agility", draft-ietf-smime-esscertid-05.txt, work 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 the
     same.  Applications that specify this need to be aware that
     algorithm rollover will not
               progress, March 2007.

   [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.

   [MSG]       Ramsdell, B., and S. Turner, "Secure Multipurpose
               Internet Mail Extensions (S/MIME) Version 3.2 Message
               Specification", work correctly in this case.

   In Step 2:

     - progress.

8.2. Informative References

   [Attack]    Hoffman, P., Schneier, B., "Attacks on Cryptographic
               Hashes in Internet Protocols", RFC 4270, November 2005.

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 major policy implication at this step is the treatment of types and
     order values defined in this module are exported for use
   -- in 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 other ASN.1 modules.  Other applications 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 use them for the signature.

   In Step 3:

     - Very application dependent processing other options are:
   -- strip bad sig their own purposes.

   IMPORTS

   -- Imports from the outside in - signed  mail. 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) }

   -- strip bad sigs Imports from the inside out - work flow. 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) }

   ;

   -- Section 3.0

   id-multipleSignatures OBJECT IDENTIFIER ::= { iso(1) member-body(2)
   us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD }
   MultipleSignatures ::= SEQUENCE {
     bodyHashAlg     DigestAlgorithIdentifier,
     signAlg         SignatureAlgorithmIdentifier,
     signAttrsHash   SignAttrsHash,
     cert            ESSCertIDv2 OPTIONAL }

   SignAttrsHash ::= SEQUENCE {
     algID            AlgorithmIdentifier,
     hash             OCTET STRING }

   END -  Modifications of MultipleSignatures

Appendix B. Background

   This is an informative appendix that looks at the algorithm due to the presence locations of other hashes
   CMS and possible attacks against them.

B.1. Attacks

   The following types of layers.  I.e. EncryptedData/EnvelopedData or
     AuthenticatedData.

   Implications/differences for AuthenticatedData.

6. Security Considerations

   If another entity resistance against known attacks, see
   [ATTACK], is providing hash to be signed, then ensure 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
   "trustworthy" source.

   This attribute provides no protection if all of the algorithms used
   in the signer attribute are 'cracked'.

   Protection against attacks preimage attack.

B.2. Hashes in the future CMS

   Within a SignedInfo there are also not protected
   against.

   //** Needs more work

7. IANA Considerations

   None: All identifiers two places where hashes are already registered.  Please remove this
   section prior to publication as an RFC.

8. References

8.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 applied and
               Certificate Revocation List (CRL) Profile", RFC 3280,
               April 2002.

   [ESSCertID] Schaad, J., "ESS Update: Adding CertID Algorithm
               Agility", draft-ietf-smime-esscertid-05.txt, work in
               progress, March 2007.

8.2. Informative References

   [Attack]    Hoffman, P., Schneier, B., "Attacks on Cryptographic
               Hashes in Internet Protocols", RFC 4270, November 2005.

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
   hence can be attacked: the Body 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) }

   ;

   -- Section 3.0

   id-multipleSignatures OBJECT IDENTIFIER ::= { iso(1) member-body(2)
   us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD }
   MultipleSignatures ::= SEQUENCE {
     bodyHashAlg     DigestAlgorithIdentifier,
     signAlg         SignatureAlgorithmIdentifier,
     signAttrsHash   SignAttrsHash,
     cert            ESSCertIDv2 OPTIONAL }

   SignAttrsHash ::= SEQUENCE {
     algID            AlgorithmIdentifier,
     hash 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 }

   END omitting the tag and length
     octets - as per 5.4 of MultipleSignatures [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.

      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.

   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.

Author's Addresses

   Sean Turner
   IECA, Inc.

   Email: turners (at) ieca (dot) com

   Jim Schaad
   Soaring Hawk Consulting

   Email: jimsch (at) exmsft (dot) com

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.

   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, THE IETF TRUST 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.

Intellectual Property

   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.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).