draft-ietf-smime-multisig-05.txt   rfc5752.txt 
S/MIME WG Sean Turner, IECA
Internet Draft Jim Schaad, Soaring Hawk
Intended Status: Standard Track March 11, 2008
Expires: September 11, 2008
Multiple Signatures in S/MIME
draft-ietf-smime-multisig-05.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 Internet Engineering Task Force (IETF) S. Turner
Task Force (IETF), its areas, and its working groups. Note that Request for Comments: 5752 IECA
other groups may also distribute working documents as Internet- Category: Standards Track J. Schaad
Drafts. ISSN: 2070-1721 Soaring Hawk
January 2010
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 September 11, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008). Multiple Signatures in Cryptographic Message Syntax (CMS)
Abstract Abstract
Cryptographic Message Syntax (CMS) SignedData includes the SignerInfo Cryptographic Message Syntax (CMS) SignedData includes the SignerInfo
structure to convey per-signer information. SignedData supports structure to convey per-signer information. SignedData supports
multiple signers and multiple signature algorithms per-signer with multiple signers and multiple signature algorithms per signer with
multiple SignerInfo structures. If a signer attaches more than one multiple SignerInfo structures. If a signer attaches more than one
SignerInfo, there are concerns that an attacker could perform a SignerInfo, there are concerns that an attacker could perform a
downgrade attack by removing the SignerInfo(s) with the 'strong' downgrade attack by removing the SignerInfo(s) with the 'strong'
algorithm(s). This document defines the multiple-signatures algorithm(s). This document defines the multiple-signatures
attribute, its generation rules, and its processing rules to allow attribute, its generation rules, and its processing rules to allow
signers to convey multiple SignerInfo while protecting against signers to convey multiple SignerInfo objects while protecting
downgrade attacks. Additionally, this attribute may assist during against downgrade attacks. Additionally, this attribute may assist
periods of algorithm migration. during periods of algorithm migration.
Conventions used in this document Status of This Memo
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This is an Internet Standards Track document.
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Discussion This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This draft is being discussed on the 'ietf-smime' mailing list. To Information about the current status of this document, any errata,
subscribe, send a message to ietf-smime-request@imc.org with the and how to provide feedback on it may be obtained at
single word subscribe in the body of the message. There is a Web site http://www.rfc-editor.org/info/rfc5752.
for the mailing list at <http://www.imc.org/ietf-smime/>.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction ....................................................3
2. Rationale......................................................3 1.1. Conventions Used in This Document ..........................3
2.1. Attribute Design Requirements.............................4 2. Rationale .......................................................3
3. Multiple Signature Indication..................................5 2.1. Attribute Design Requirements ..............................4
4. Message Generation and Processing..............................6 3. Multiple Signature Indication ...................................5
4.1. SignedData Type...........................................7 4. Message Generation and Processing ...............................6
4.2. EncapsulatedContentInfo Type..............................7 4.1. SignedData Type ............................................6
4.3. SignerInfo Type...........................................7 4.2. EncapsulatedContentInfo Type ...............................7
4.4. Message Digest Calculation Process........................8 4.3. SignerInfo Type ............................................7
4.4.1. multiple-signatures Signed Attribute Generation......8 4.4. Message Digest Calculation Process .........................7
4.4.2. Message Digest calculation Process...................8 4.4.1. multiple-signatures Signed Attribute Generation .....7
4.5. Signature Generation Process..............................8 4.4.2. Message Digest Calculation Process ..................7
4.6. Signature Verification Process............................8 4.5. Signature Generation Process ...............................8
5. Signature Evaluation Processing................................9 4.6. Signature Verification Process .............................8
5.1. Evaluation of a SignerInfo object.........................9 5. Signature Evaluation Processing .................................8
5.2. Evaluation of a SignerInfo Set...........................10 5.1. Evaluation of a SignerInfo Object ..........................9
5.3. Evaluation of a SignedData Set...........................11 5.2. Evaluation of a SignerInfo Set .............................9
6. Security Considerations.......................................12 5.3. Evaluation of a SignedData Set ............................10
7. IANA Considerations...........................................12 6. Security Considerations ........................................11
8. References....................................................12 7. References .....................................................11
8.1. Normative References.....................................12 7.1. Normative References ......................................11
8.2. Informative References...................................13 7.2. Informative References ....................................12
Appendix A. ASN.1 Module.........................................14 Appendix A. ASN.1 Module...........................................13
Appendix B. Background...........................................16 Appendix B. Background.............................................15
B.1. Attacks..................................................16 B.1. Attacks....................................................15
B.2. Hashes in CMS............................................16 B.2. Hashes in CMS..............................................15
1. Introduction 1. Introduction
The Cryptographic Message Syntax (CMS), see [CMS], defined SignerInfo The Cryptographic Message Syntax (CMS; see [CMS]) defined SignerInfo
to provide data necessary for relying parties to verify the signer's to provide data necessary for relying parties to verify the signer's
digital signature, which is also included in the SignerInfo digital signature, which is also included in the SignerInfo
structure. Signers include more than one SignerInfo in a SignedData structure. Signers include more than one SignerInfo in a SignedData
if they use different digest or signature algorithms. Each SignerInfo if they use different digest or signature algorithms. Each
exists independently and new SignerInfo structures can be added or an SignerInfo exists independently and new SignerInfo structures can be
existing one(s) removed without perturbing the remaining added or existing ones removed without perturbing the remaining
signature(s). signatures.
The concern is that if an attacker successfully attacked a hash or The concern is that if an attacker successfully attacked a hash or
signature algorithm; the attacker could remove all SignerInfo signature algorithm, the attacker could remove all SignerInfo
structures except the SignerInfo with the successfully attacked hash structures except the SignerInfo with the successfully attacked hash
or signature algorithm; the relying party is then left with the or signature algorithm. The relying party is then left with the
attacked SignerInfo even though the relying party supported more than attacked SignerInfo even though the relying party supported more than
just the attacked hash or signature algorithm. just the attacked hash or signature algorithm.
A solution is to have signers include a pointer to all the signer's A solution is to have signers include a pointer to all the signer's
SignerInfo structures. If an attacker removes any SignerInfo, then SignerInfo structures. If an attacker removes any SignerInfo, then
relying parties will be aware that an attacker has removed one or relying parties will be aware that an attacker has removed one or
more SignerInfo. more SignerInfo objects.
Note this attribute ought not be confused with the countersignature Note that this attribute ought not be confused with the
attribute, see 11.4 of [CMS], as this is not intended to sign over an countersignature attribute (see Section 11.4 of [CMS]) as this is not
existing signature rather it is to provide a pointer to additional intended to sign over an existing signature. Rather, it is to
signer's signatures that are all at the same level. That is provide a pointer to additional signatures by the signer that are all
countersignature provides a serial signature while the attribute at the same level. That is, countersignature provides a serial
defined herein provides pointers to parallel signatures by the same signature while the attribute defined herein provides pointers to
signer. parallel signatures by the same signer.
2. Rationale 1.1. 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].
2. Rationale
The rationale for this specification is to protect against downgrade The rationale for this specification is to protect against downgrade
attacks that remove the 'strong' signature to leave the 'weak' attacks that remove the 'strong' signature to leave the 'weak'
signature, which has presumably been successfully attacked. If a CMS signature, which has presumably been successfully attacked. If a CMS
object has multiple SignerInfos, then the attacker, whether it be SignedData object has multiple SignerInfo objects, then the attacker,
Alice, Bob, or Mallory, can remove SignerInfos without the relying whether it be Alice, Bob, or Mallory, can remove a SignerInfo object
party being aware that more than one was generated. without the relying party being aware that more than one was
generated.
Removal of a SignerInfo does not render the signature invalid nor Removal of a SignerInfo does not render the signature invalid nor
does it constitute an error. In the following scenario: a signer does it constitute an error. In the following scenario, a signer
generates a SignedData with two SignerInfo objects one with a 'weak' generates a SignedData with two SignerInfo objects, one with a 'weak'
algorithm and one with a 'strong' algorithm; there are three types of algorithm and one with a 'strong' algorithm; there are three types of
relying parties: relying parties:
1) Those that support only a 'weak' algorithm. If both SignerInfo 1) Those that support only a 'weak' algorithm. If both SignerInfo
objects are present, the relying party processes the algorithm it objects are present, the relying party processes the algorithm it
supports. If both SignerInfo objects are not present, the relying supports. If both SignerInfo objects are not present, the relying
party can easily determine that another SignerInfo has been party can easily determine that another SignerInfo has been
removed, but not changed. In both cases, if the 'weak' signature removed, but not changed. In both cases, if the 'weak' signature
verifies the relying party MAY consider the signature valid. verifies, the relying party MAY consider the signature valid.
2) Those that support only a 'strong' algorithm. If both 2) Those that support only a 'strong' algorithm. If both SignerInfo
SignerInfo objects are present, the relying party processes the objects are present, the relying party processes the algorithm it
algorithm it supports. If both SignerInfo objects are not present, supports. If both SignerInfo objects are not present, the relying
the relying party can easily determine that another SignerInfo has party can easily determine that another SignerInfo has been
been removed, but the relying party doesn't care. In both cases, removed, but the relying party doesn't care. In both cases, if
if the 'strong' signature verifies the relying party MAY consider the 'strong' signature verifies, the relying party MAY consider
the signature valid. the signature valid.
3) Those that support both a 'weak' algorithm and a 'strong' 3) Those that support both a 'weak' algorithm and a 'strong'
algorithm. If both SignerInfo objects are present, the relying algorithm. If both SignerInfo objects are present, the relying
party processes both algorithms. If both SignerInfo objects are party processes both algorithms. If both SignerInfo objects are
not present, the relying party can easily determine that another not present, the relying party can easily determine that another
SignerInfo has been removed. SignerInfo has been removed. In both cases, if the 'strong'
and/or 'weak' signatures verify, the relying party MAY consider
the signature valid. (Policy may dictate that both signatures are
required to validate if present.)
Local policy MAY dictate that the removal of the 'strong' algorithm Local policy MAY dictate that the removal of the 'strong' algorithm
results in an invalid signature. See section 5 for further results in an invalid signature. See Section 5 for further
processing. processing.
2.1. Attribute Design Requirements 2.1. Attribute Design Requirements
The attribute will have the following characteristics: The attribute will have the following characteristics:
1) Use CMS attribute structure; 1) Use CMS attribute structure;
2) Be computable before any signatures are applied; 2) Be computable before any signatures are applied;
3) Contain enough information to identify individual signatures 3) Contain enough information to identify individual signatures
(i.e., a particular SignerInfo); and, (i.e., a particular SignerInfo); and
4) Contain enough information to resist collision, preimage, and 4) Contain enough information to resist collision, preimage, and
second premiage attacks. second preimage attacks.
3. Multiple Signature Indication 3. Multiple Signature Indication
The multiple-signatures attribute type specifies a pointer to a The multiple-signatures attribute type specifies a pointer to a
signer's other multiple-signatures attribute(s). For example, if a signer's other multiple-signatures attribute(s). For example, if a
signer applies three signatures there must be two attribute values signer applies three signatures, there must be two attribute values
for multiple-signatures in each SignerInfo. The 1st SignerInfo for multiple-signatures in each SignerInfo. The 1st SignerInfo
points to the 2nd and 3rd SignerInfos. The 2nd SignerInfo points to object points to the 2nd and 3rd SignerInfo objects. The 2nd
the 1st and 3rd SignerInfos. The 3rd SignerInfo points to the 1st and SignerInfo object points to the 1st and 3rd SignerInfo objects. The
2nd SignerInfos. 3rd SignerInfo object points to the 1st and 2nd SignerInfo objects.
The multiple-signatures attribute MUST be a signed attribute. The The multiple-signatures attribute MUST be a signed attribute. The
number of attribute values included in a SignerInfo is the number of number of attribute values included in a SignerInfo is the number of
signatures applied by a signer less one. This attribute is multi- signatures applied by a signer less one. This attribute is multi-
valued and there MAY be more than one AttributeValue present. valued, and there MAY be more than one AttributeValue present. The
The following object identifier identifies the multiple-signatures following object identifier identifies the multiple-signatures
attribute: attribute:
id-aa-multipleSignatures OBJECT IDENTIFIER ::= { id-aa-multipleSignatures OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
id-aa(16) 51 } id-aa(16) 51 }
multiple-signatures attribute values have the ASN.1 type multiple-signatures attribute values have the ASN.1 type
MultipleSignatures: MultipleSignatures:
MultipleSignatures ::= SEQUENCE { MultipleSignatures ::= SEQUENCE {
bodyHashAlg DigestAlgorithmIdentifier, bodyHashAlg DigestAlgorithmIdentifier,
signAlg SignatureAlgorithmIdentifier, signAlg SignatureAlgorithmIdentifier,
signAttrsHash SignAttrsHash, signAttrsHash SignAttrsHash,
cert ESSCertIDv2 OPTIONAL} cert ESSCertIDv2 OPTIONAL}
SignAttrsHash ::= SEQUENCE { SignAttrsHash ::= SEQUENCE {
algID DigestAlgorithmIdentifier, algID DigestAlgorithmIdentifier,
hash OCTET STRING } hash OCTET STRING }
The fields in MultipleSignatures have the following meaning: The fields in MultipleSignatures have the following meaning:
- bodyHashAlg includes the digest algorithmIdentifier for the - bodyHashAlg includes the digest algorithmIdentifier for the
referenced multiple-signatures attribute. referenced multiple-signatures attribute.
- signAlg includes the signature algorithmIdentifier for the - signAlg includes the signature algorithmIdentifier for the
referenced multiple-signatures attribute. referenced multiple-signatures attribute.
- signAttrsHash has two fields: - signAttrsHash has two fields:
-- algId MUST match the digest algorithm for the SignerInfo in -- algId MUST match the digest algorithm for the SignerInfo in
which this multiple-signatures attribute value is placed. which this multiple-signatures attribute value is placed.
-- hash is the hash value of the signedAttrs (see section 4.3). -- hash is the hash value of the signedAttrs (see Section 4.3).
- cert is optional. It identities the certificate used to sign the - cert is optional. It identities the certificate used to sign the
SignerInfo that contains the other multiple-signatures SignerInfo that contains the other multiple-signatures
attribute(s). It MUST be present if the fields in the other attribute(s). It MUST be present if the fields in the other
multiple-signatures attribute(s) are the same. multiple-signatures attribute(s) are the same.
The following is an example: The following is an example:
SignedData SignedData
DigestAlg=sha1,sha256 DigestAlg=sha1,sha256
SignerInfo1 SignerInfo2 SignerInfo1 SignerInfo2
digestAlg=sha1 digestAlg=sha256 digestAlg=sha1 digestAlg=sha256
signatureAlg=dsawithsha1 signatureAlg=ecdsawithsha256 signatureAlg=dsawithsha1 signatureAlg=ecdsawithsha256
signedAttrs= signedAttrs= signedAttrs= signedAttrs=
signingTime1 signingTime1 signingTime1 signingTime1
messageDigest1 messageDigest2 messageDigest1 messageDigest2
multiSig1= multiSig2= multiSig1= multiSig2=
bodyHash=sha256 bodyHash=sha1 bodyHash=sha256 bodyHash=sha1
signAlg=ecdsawithsha256 signAlg=dsawithsha1 signAlg=ecdsawithsha256 signAlg=dsawithsha1
signAttrsHash= signAttrsHash= signAttrsHash= signAttrsHash=
algID=sha1 algID=sha256 algID=sha1 algID=sha256
hash=value1 hash=value2 hash=value1 hash=value2
4. Message Generation and Processing 4. Message Generation and Processing
The following are the additional procedures for Message Generation The following are the additional procedures for message generation
when using the multiple-signatures attribute. These paragraphs track when using the multiple-signatures attribute. These paragraphs track
with section 5.1-5.6 in [CMS]. with Sections 5.1-5.6 in [CMS].
4.1. SignedData Type 4.1. SignedData Type
The following steps MUST be followed by a signer when generating The following steps MUST be followed by a signer when generating
SignedData: SignedData:
- The signer MUST indicate the CMS version. - The signer MUST indicate the CMS version.
- The signer SHOULD include the digest algorithm used in - The signer SHOULD include the digest algorithm used in
SignedData.digestAlgorithms, if the digest algorithm's identifier SignedData.digestAlgorithms, if the digest algorithm's identifier
is not already present. is not already present.
- The signer MUST include the encapContentInfo. Note the - The signer MUST include the encapContentInfo. Note that the
encapContentInfo is the same for all signers in this SignedData. encapContentInfo is the same for all signers in this SignedData.
- The signer SHOULD add certificates sufficient to contain - The signer SHOULD add certificates sufficient to contain
certificate paths from a recognized "root" or "top-level certificate paths from a recognized "root" or "top-level
certification authority" to the signer, if the signer's certification authority" to the signer, if the signer's
certificates are not already present. certificates are not already present.
- The signer MAY include the Certificate Revocation Lists (CRLs) - The signer MAY include the Certificate Revocation Lists (CRLs)
necessary to validate the digital signature, if the CRLs are not necessary to validate the digital signature, if the CRLs are not
already present. already present.
- The signer MUST: - The signer MUST:
-- Retain the existing signerInfo(s). -- Retain the existing signerInfo objects.
-- Include their signerInfo. -- Include their signerInfo object(s).
4.2. EncapsulatedContentInfo Type 4.2. EncapsulatedContentInfo Type
The procedures for generating EncapsulatedContentInfo are as The procedures for generating EncapsulatedContentInfo are as
specified in section 5.2 of [CMS]. specified in Section 5.2 of [CMS].
4.3. SignerInfo Type 4.3. SignerInfo Type
The procedures for generating a SignerInfo are as specified in The procedures for generating SignerInfo are as specified in Section
section 4.4.1 of [CMS] with the following addition: 4.4.1 of [CMS] with the following addition:
The signer MUST include the multiple-signatures attribute in The signer MUST include the multiple-signatures attribute in
signedAttrs. signedAttrs.
4.4. Message Digest Calculation Process 4.4. Message Digest Calculation Process
4.4.1. multiple-signatures Signed Attribute Generation 4.4.1. multiple-signatures Signed Attribute Generation
The procedure for generating the multiple-signatures signed attribute The procedure for generating the multiple-signatures signed attribute
is as follows: is as follows:
1) All other signed attributes are placed in the respective 1) All other signed attributes are placed in the respective
SignerInfo structures but the signatures are not yet computed for SignerInfo structures, but the signatures are not yet computed for
the SignerInfo. the SignerInfo.
2) The multiple-signatures attributes are added to each of the 2) The multiple-signatures attributes are added to each of the
SignerInfo structures with the SignAttrsHash.hash field containing SignerInfo structures with the SignAttrsHash.hash field containing
a zero length octet string. a zero-length octet string.
3) The correct SignAttrsHash.hash value is computed for each of the 3) The correct SignAttrsHash.hash value is computed for each of the
SignerInfo structures. SignerInfo structures.
4) After all hash values have been computed, the correct hash 4) After all hash values have been computed, the correct hash values
values are placed into their respective SignAttrsHash.hash fields. are placed into their respective SignAttrsHash.hash fields.
4.4.2. Message Digest calculation Process 4.4.2. Message Digest Calculation Process
The remaining procedures for generating the message-digest attribute The remaining procedures for generating the message-digest attribute
are as specified in section 5.4 of [CMS]. are as specified in Section 5.4 of [CMS].
4.5. Signature Generation Process 4.5. Signature Generation Process
The procedures for signature generation are as specified in section The procedures for signature generation are as specified in Section
5.5 of [CMS]. 5.5 of [CMS].
4.6. Signature Verification Process 4.6. Signature Verification Process
The procedures for signature verification are as specified in section The procedures for signature verification are as specified in Section
5.6 of [CMS] with the following addition: 5.6 of [CMS] with the following addition:
If the SignedData signerInfo includes the multiple-signatures If the SignedData signerInfo includes the multiple-signatures
attribute, the attribute's values must be calculated as described in attribute, the attribute's values must be calculated as described in
section 4.4.1. Section 4.4.1.
For every SignerInfo to be considered present for a given signer, the For every SignerInfo to be considered present for a given signer, the
number of MultipleSignatures AttributeValue(s) present in a given number of MultipleSignatures AttributeValue(s) present in a given
SignerInfo MUST equal the number of SignerInfos for that signer less SignerInfo MUST equal the number of SignerInfo objects for that
one and the hash value present in each of the MultipleSignatures signer less one and the hash value present in each of the
AttributeValue(s) MUST match the output of the message digest MultipleSignatures AttributeValue(s) MUST match the output of the
calculation from section 4.4.1 for each SignerInfo. message digest calculation from Section 4.4.1 for each SignerInfo.
The hash corresponding to the n-th SignerInfo must match the value in The hash corresponding to the n-th SignerInfo must match the value in
the multiple-signatures attribute that points to the n-th SignerInfo the multiple-signatures attribute that points to the n-th SignerInfo
present in all other SignerInfos. present in all other SignerInfo objects.
5. Signature Evaluation Processing 5. Signature Evaluation Processing
This section describes recommended processing of signatures when This section describes recommended processing of signatures when
there are more than one SignerInfo present in a message. This may be there are more than one SignerInfo present in a message. This may be
due to either multiple SignerInfos being present in a single due to either multiple SignerInfo objects being present in a single
SignedData object, or there are multiple SignerData objects embedded SignedData object or multiple SignerData objects embedded in each
in each other. other.
The text in this section is non-normative. The processing described The text in this section is non-normative. The processing described
is highly recommended, but is not forced. Changes in the processing is highly recommended, but is not forced. Changes in the processing
which have the same results with somewhat different orders of that have the same results with somewhat different orders of
processing is sufficient. processing is sufficient.
Order of operations: Order of operations:
1) Evaluate each SignerInfo object independently. 1) Evaluate each SignerInfo object independently.
2) Combine the results of all SignerInfo objects at the same level 2) Combine the results of all SignerInfo objects at the same level
(i.e. attached to the same SignerData object) (i.e., attached to the same SignerData object).
3) Combine the results of the nested SignerData objects. Note that 3) Combine the results of the nested SignerData objects. Note that
this should ignore the presence of other CMS objects between the this should ignore the presence of other CMS objects between the
SignedData objects. SignedData objects.
5.1. Evaluation of a SignerInfo object 5.1. Evaluation of a SignerInfo Object
When evaluating a SignerInfo object, there are three different pieces When evaluating a SignerInfo object, there are three different pieces
that need to be examined. that need to be examined.
The first piece is the mathematics of the signature itself (i.e., can The first piece is the mathematics of the signature itself (i.e., can
one actually successfully do the computations and get the correct one actually successfully do the computations and get the correct
answer). This result is one of three results. The mathematics answer?). This result is one of three results. The mathematics
succeeds, the mathematics fails, or the mathematics cannot be succeeds, the mathematics fails, or the mathematics cannot be
evaluated. The type of things that lead to the last state are non- evaluated. The type of things that lead to the last state are non-
implementation of an algorithm or required inputs, such as the public implementation of an algorithm or required inputs, such as the public
key, are missing. key, are missing.
The second piece is the validation of the source of the public key. The second piece is the validation of the source of the public key.
For CMS, this is generally determined by extracting the public key For CMS, this is generally determined by extracting the public key
from a certificate. The certificate needs to be evaluated. This is from a certificate. The certificate needs to be evaluated. This is
done by the procedures outlined in [PROFILE]. In addition to the done by the procedures outlined in [PROFILE]. In addition to the
processing described in that document, there may be additional processing described in that document, there may be additional
requirements on certification path processing that are required by requirements on certification path processing that are required by
the application in question. One such set of additional processing the application in question. One such set of additional processing
is described in [SMIME-CERT]. One piece of information that is part is described in [SMIME-CERT]. One piece of information that is part
of this additional certificate path processing is local and of this additional certificate path processing is local and
application policy. The output of this processing can actually be application policy. The output of this processing can actually be
one of four different states: Success, Failure, Indeterminate and one of four different states: Success, Failure, Indeterminate, and
Warning. The first three states are described in [PROFILE], Warning Warning. The first three states are described in [PROFILE]; Warning
would be generated when it is possible that some information is would be generated when it is possible that some information is
currently acceptable, but may not be acceptable either in the near currently acceptable, but may not be acceptable either in the near
future or under some circumstances. future or under some circumstances.
The third piece of the validation is local and application policy as The third piece of the validation is local and application policy as
applied to the contents of the SignerInfo object. This would cover applied to the contents of the SignerInfo object. This would cover
such issues as the requirements on mandatory signed attributes or such issues as the requirements on mandatory signed attributes or
requirements on signature algorithms. requirements on signature algorithms.
5.2. Evaluation of a SignerInfo Set 5.2. Evaluation of a SignerInfo Set
Combining the results of the individual SignerInfos into a result for Combining the results of the individual SignerInfo objects into a
a SignedData object requires knowledge of the results for the result for a SignedData object requires knowledge of the results for
individual SignerInfo objects, the required application policy and the individual SignerInfo objects, the required application policy,
any local policies. The default processing if no other rules are and any local policies. The default processing if no other rules are
applied should be: applied should be:
1) Group the SignerInfo objects by the signer. 1) Group the SignerInfo objects by the signer.
2) Take the best result from each signer. 2) Take the best result from each signer.
3) Take the worst result from all of the different signers; this is 3) Take the worst result from all of the different signers; this is
the result for the SignedData object. the result for the SignedData object.
Application and local policy can affect each of the steps outlined Application and local policy can affect each of the steps outlined
above. above.
In Step 1: In Step 1:
- If the subject name or subject alternative name(s) cannot be used - If the subject name or subject alternative name(s) cannot be used
to determine if two SignerInfo objects were created by the same to determine if two SignerInfo objects were created by the same
identity, then applications need to specify how such matching is to identity, then applications need to specify how such matching is to
be done. As an example, the S/MIME message specification [SMIME- be done. As an example, the S/MIME message specification [SMIME-
MSG] could say that as long as the same RFC 822 name exists in MSG] could say that as long as the same rfc822Name exists in either
either the subject name or the subject alt name they are the same the subject name or the subject alt name they are the same
identity. This would be true even if other information that did identity. This would be true even if other information that did
not match existed in these fields. not match existed in these fields.
- Some applications may specify that this step should be skipped; - Some applications may specify that this step should be skipped;
this has the effect of making each SignerInfo object independent of this has the effect of making each SignerInfo object independent of
all other SignerInfo objects even if the signing identity is the all other SignerInfo objects even if the signing identity is the
same. Applications that specify this need to be aware that same. Applications that specify this need to be aware that
algorithm rollover will not work correctly in this case. algorithm rollover will not work correctly in this case.
In Step 2: In Step 2:
- The major policy implication at this step is the treatment of and - The major policy implication at this step is the treatment of and
order for the indeterminate states. In most cases this state would order for the indeterminate states. In most cases, this state
be placed between the failure and warning states. Part of the would be placed between the failure and warning states. Part of
issue is the question of having a multi-state or a binary answer as the issue is the question of having a multi-state or a binary
to success or failure of an evaluation. Not every application can answer as to success or failure of an evaluation. Not every
deal with the statement "try again later". It may also be application can deal with the statement "try again later". It may
dependent on what the reason for the indeterminate state is. It also be dependent on what the reason for the indeterminate state
makes more sense to try again later if the problem is that a CRL is. It makes more sense to try again later if the problem is that
cannot be found than if you are not able to evaluate the algorithm a CRL cannot be found than if you are not able to evaluate the
for the signature. algorithm for the signature.
In Step 3: In Step 3:
- The same policy implications from Step 2 apply here. - The same policy implications from Step 2 apply here.
5.3. Evaluation of a SignedData Set 5.3. Evaluation of a SignedData Set
Simple applications will generally use the worst single outcome Simple applications will generally use the worst single outcome
(success, unknown, failure) as the outcome for a set of SignedData (success, unknown, failure) as the outcome for a set of SignedData
objects (i.e., one failure means the entire item fails). However not objects (i.e., one failure means the entire item fails). However,
all applications will want to have this behavior. not all applications will want to have this behavior.
A work flow application could work as follows: A work flow application could work as follows:
The second signer will modify the original content, keep the original The second signer will modify the original content, keep the original
signature and then sign the message. This means that only the signature, and then sign the message. This means that only the
outermost signature is of significance during evaluation. The second outermost signature is of significance during evaluation. The second
signer is asserting that they successfully validated the inner signer is asserting that they successfully validated the inner
signature as part of its processing. signature as part of its processing.
A Signed Mail application could work as follows: A Signed Mail application could work as follows:
If signatures are added for the support of [ESS] features, then the If signatures are added for the support of [ESS] features, then the
fact that an outer layer signature cannot be validated can be treated fact that an outer layer signature cannot be validated can be treated
as a non-significant failure. The only thing that matters is that as a non-significant failure. The only thing that matters is that
the originator signature is valid. This means that all outer layer the originator signature is valid. This means that all outer layer
signatures which fail can be stripped from the message prior to signatures that fail can be stripped from the message prior to
display leaving only the inner-most valid signature to be displayed. display leaving only the inner-most valid signature to be displayed.
6. Security Considerations 6. Security Considerations
Security considerations from the hash and signature algorithms used Security considerations from the hash and signature algorithms used
to produce the SignerInfo apply. to produce the SignerInfo apply.
If the hashing and signing operations are performed by different If the hashing and signing operations are performed by different
entities, the entity performing the signature must ensure the hash entities, the entity creating the signature must ensure that the hash
comes from a "trustworthy" source. This can be partially mitigated by comes from a "trustworthy" source. This can be partially mitigated
requiring that multiple hashes using different algorithms are by requiring that multiple hashes using different algorithms are
provided. provided.
This attribute cannot be relied upon in the event that all of the This attribute cannot be relied upon in the event that all of the
algorithms used in the signer attribute are 'cracked'. It is not algorithms used in the signer attribute are 'cracked'. It is not
possible for a verifier to determine that a collision could not be possible for a verifier to determine that a collision could not be
found that satisfies all of the algorithms. found that satisfies all of the algorithms.
Local policy and applications greatly affects signature processing. Local policy and applications greatly affect signature processing.
The application of local policy and the requirements specific to an The application of local policy and the requirements specific to an
application can both affect signature processing. This means that a application can both affect signature processing. This means that a
signature valid in one context or location can fail validation in a signature valid in one context or location can fail validation in a
different context or location. different context or location.
7. IANA Considerations 7. References
None: All identifiers are already registered. Please remove this
section prior to publication as an RFC.
8. References
8.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
3852, July 2004. 5652, September 2009.
[PROFILE] Housley, R., Polk, W., Ford, W., and D. Solo, [PROFILE] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
"Internet X.509 Public Key Infrastructure Certificate Housley, R., and W. Polk, "Internet X.509 Public Key
and Certificate Revocation List (CRL) Profile", RFC Infrastructure Certificate and Certificate Revocation
3280, April 2002. List (CRL) Profile", RFC 5280, May 2008.
[SMIME-CERT] Ramsdell, B., and S. Turner, "Secure Multipurpose [SMIME-CERT] Ramsdell, B. and S. Turner, "Secure/Multipurpose
Internet Mail Extensions (S/MIME) Version 3.2 Internet Mail Extensions (S/MIME) Version 3.2
Certificate Handling", work in progress. Certificate Handling", RFC 5750, January 2010.
[SMIME-MSG] Ramsdell, B., and S. Turner, "Secure Multipurpose [SMIME-MSG] Ramsdell, B. and S. Turner, "Secure/Multipurpose
Internet Mail Extensions (S/MIME) Version 3.2 Message Internet Mail Extensions (S/MIME) Version 3.2 Message
Specification", work in progress. Specification", RFC 5751, January 2010.
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME",
RFC 2634, June 1999.
[ESSCertID] Schaad, J., "ESS Update: Adding CertID Algorithm [ESS] Hoffman, P., Ed., "Enhanced Security Services for
Agility", RFC 5035, August 2007. S/MIME", RFC 2634, June 1999.
8.2. Informative References [ESSCertID] Schaad, J., "Enhanced Security Services (ESS) Update:
Adding CertID Algorithm Agility", RFC 5035, August
2007.
[ATTACK] Hoffman, P., Schneier, B., "Attacks on Cryptographic 7.2. Informative References
Hashes in Internet Protocols", RFC 4270, November
2005.
Appendix A. ASN.1 Module [ATTACK] Hoffman, P. and B. Schneier, "Attacks on Cryptographic
Hashes in Internet Protocols", RFC 4270, November 2005.
MultipleSignatures-2008 Appendix A. ASN.1 Module
{ iso(1) member-body(2) us(840) rsadsi(113549) MultipleSignatures-2008
pkcs(1) pkcs-9(9) smime(16) modules(0)
id-mod-multipleSig-2008(34) }
DEFINITIONS IMPLICIT TAGS ::= { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs9(9) smime(16) modules(0)
id-mod-multipleSig-2008(34) }
BEGIN DEFINITIONS IMPLICIT TAGS ::=
-- EXPORTS All BEGIN
-- The types and values defined in this module are exported for use -- EXPORTS All
-- in the other ASN.1 modules. Other applications may use them for
-- their own purposes.
- <span class="insert">EXPORTS All</span> -- The types and values defined in this module are exported for use
IMPORTS -- in the other ASN.1 modules. Other applications may use them for
-- their own purposes.
-- Imports from RFC 3852 [CMS], 12.1 IMPORTS
DigestAlgorithmIdentifier, SignatureAlgorithmIdentifier -- Imports from RFC 5652 [CMS], 12.1
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 5035 [ESSCertID], Appendix A DigestAlgorithmIdentifier, SignatureAlgorithmIdentifier
FROM CryptographicMessageSyntax2004
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs9(9) smime(16) modules(0) cms-2004(24) }
ESSCertIDv2 -- Imports from RFC 5035 [ESSCertID], Appendix A
FROM ExtendedSecurityServices-2006
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-ess-2006(30) }
; ESSCertIDv2
FROM ExtendedSecurityServices-2006
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs9(9) smime(16) modules(0) id-mod-ess-2006(30) }
-- Section 3.0 ;
id-multipleSignatures OBJECT IDENTIFIER ::= { iso(1) member-body(2) -- Section 3.0
us(840) rsadsi(113549) pkcs(1) pkcs9(9) id-aa(2) 51 }
MultipleSignatures ::= SEQUENCE { id-aa-multipleSignatures OBJECT IDENTIFIER ::= { iso(1) member-body(2)
bodyHashAlg DigestAlgorithmIdentifier, us(840) rsadsi(113549) pkcs(1) pkcs9(9) id-aa(2) 51 }
signAlg SignatureAlgorithmIdentifier,
signAttrsHash SignAttrsHash,
cert ESSCertIDv2 OPTIONAL }
SignAttrsHash ::= SEQUENCE { MultipleSignatures ::= SEQUENCE {
algID DigestAlgorithmIdentifier, bodyHashAlg DigestAlgorithmIdentifier,
hash OCTET STRING } signAlg SignatureAlgorithmIdentifier,
signAttrsHash SignAttrsHash,
cert ESSCertIDv2 OPTIONAL }
END -- of MultipleSignatures-2008 SignAttrsHash ::= SEQUENCE {
algID DigestAlgorithmIdentifier,
hash OCTET STRING }
Appendix B. Background END -- of MultipleSignatures-2008
Appendix B. Background
This is an informational appendix. This appendix enumerates all This is an informational appendix. This appendix enumerates all
locations in CMS where hashes are used and the possible attacks on locations in CMS where hashes are used and the possible attacks on
those hash locations. those hash locations.
B.1. Attacks B.1. Attacks
As noted in [ATTACK], the following types of resistance are needed As noted in [ATTACK], the following types of resistance are needed
against known attacks: against known attacks:
1) Collision Resistance: Find x and y where x != y and H(x) = H(y) 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 2) Preimage Resistance: Given y, find x where H(x) = y
3) Second Preimage Resistance: Given y, find x where H(x) = H(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 Note: It is known that a collision resistance attack is simpler than
a second preimage resistance attack, and it is presumed that a second a second preimage resistance attack, and it is presumed that a second
preimage resistance attack is simplier than a preimage attack. preimage resistance attack is simpler than a preimage attack.
B.2. Hashes in CMS B.2. Hashes in CMS
Within a SignedInfo there are two places where hashes are applied and Within a SignerInfo there are two places where hashes are applied and
hence can be attacked: the body and the signed attributes. The hence can be attacked: the body and the signed attributes. The
following outlines the entity that creates the hash, the entity that following outlines the entity that creates the hash, the entity that
attacks the hash, and the type of resistance required: attacks the hash, and the type of resistance required:
1) Hash of the Body (i.e., the octets comprising the value of the 1) Hash of the Body (i.e., the octets comprising the value of the
encapContentInfo.eContent OCTET STRING omitting the tag and length encapContentInfo.eContent OCTET STRING omitting the tag and length
octets - as per 5.4 of [CMS]). octets, as per 5.4 of [CMS]).
a) If Alice creates the body to be hashed, then: a) If Alice creates the body to be hashed, then:
i) Alice can attack the hash. This attack requires a i) Alice can attack the hash. This attack requires a
successful Collision Resistance attack. successful collision resistance attack.
ii) Mallory can attack the hash. This attack requires a ii) Mallory can attack the hash. This attack requires a
successful Second Preimage Resistance attack. successful second preimage resistance attack.
b) If Alice hashes a body provided by Bob, then: b) If Alice hashes a body provided by Bob, then:
i) Alice can attack the hash. This attack requires a i) Alice can attack the hash. This attack requires a
successful Second Preimage attack. successful second preimage attack.
ii) Bob can attack the hash. This attack requires a successful ii) Bob can attack the hash. This attack requires a successful
Collision Resistance attack. If Alice has the ability to Collision Resistance attack. If Alice has the ability to
"change" the content of the body in some fashion, then this "change" the content of the body in some fashion, then this
attack requires a successful Second Preimage attack. (One attack requires a successful second preimage attack. (One
example would be to use a keyed hash function.) example would be to use a keyed hash function.)
iii) Mallory can attack the hash. This attack requires a iii) Mallory can attack the hash. This attack requires a
successful Second Preimage attack. successful second preimage attack.
c) If Alice signs using a hash value provided by Bob (in this c) If Alice signs using a hash value provided by Bob (in this
case Alice is presumed to never see the body in question), then: case, Alice is presumed to never see the body in question),
then:
i) Alice can attack the hash. This attack requires a i) Alice can attack the hash. This attack requires a
successful Preimage attack. successful preimage attack.
ii) Bob can attack the hash. This attack requires a successful ii) Bob can attack the hash. This attack requires a successful
Collision Resistance attack. Unlike case (b), there is nothing collision resistance attack. Unlike case (b), there is
that Alice can do to upgrade the attack. nothing that Alice can do to upgrade the attack.
iii) Mallory can attack the hash. This requires a successful iii) Mallory can attack the hash. This requires a successful
Preimage attack if the content is unavailable to Mallory and a preimage attack if the content is unavailable to Mallory and
successful Second Preimage attack if the content is available a successful second preimage attack if the content is
to Mallory. available to Mallory.
2) Hash of signed attributes (i.e., the complete Distinguished 2) Hash of signed attributes (i.e., the complete Distinguished
Encoding Rules (DER) encoding of the SignedAttrs value contained in Encoding Rules (DER) encoding of the SignedAttrs value contained
the signedAttrs field - as per 5.4 of [CMS]). in the signedAttrs field, as per 5.4 of [CMS]).
There is a difference between hashing the body and hashing the There is a difference between hashing the body and hashing the
SignedAttrs value in that one should not accept a sequence of SignedAttrs value in that one should not accept a sequence of
attributes to be signed from a third party. In fact one should not attributes to be signed from a third party. In fact, one should
accept attributes to be included in the signed attributes list from not accept attributes to be included in the signed attributes list
a third party. The attributes are about the signature you are from a third party. The attributes are about the signature you
applying and not about the body. If there is meta-information that are applying and not about the body. If there is meta-information
needs to be attached to the body by a third party then they need to that needs to be attached to the body by a third party, then they
provide their own signature and you need to add a countersignature. need to provide their own signature and you need to add a
(Note: the fact that the signature is to be used as a countersignature. (Note: The fact that the signature is to be
countersignature is a piece of information that should be accepted, used as a countersignature is a piece of information that should
but it does not directly provide an attribute that is inserted in be accepted, but it does not directly provide an attribute that is
the signed attribute list.) inserted in the signed attribute list.)
a) Alice can attack the hash: This requires a successful a) Alice can attack the hash. This requires a successful
Collision Resistance Attack. collision resistance attack.
b) Mallory can attack the hash: This requires a successful b) Mallory can attack the hash. This requires a successful second
Second Preimage Resistance attack. preimage resistance attack.
c) Bob can attack the hash and knows the body hash used: This c) Bob can attack the hash and Bob controls the value of the
case is analogous to the current attacks [ATTACK]. Based on message digest attribute used. This case is analogous to the
prediction of the signed attributes Alice will be using and the current attacks [ATTACK]. Bob can attack the hash value
provided hash value and function. (It is expected that if generated by Alice based on a prediction of the signed
Alice uses a keyed hashing function as part of the signature attributes and the hash algorithm Alice will be using to create
this attack will be more difficult.) the signature. If Bob successfully predicts these items, the
attack requires a successful collision resistance attack. (It
is expected that if Alice uses a keyed hashing function as part
of the signature, this attack will be more difficult as Bob
would have a harder time prediction the key value.)
It should be noted that both of these attacks are considered to be It should be noted that both of these attacks are considered to be
more difficult than the attack on the body since more structure is more difficult than the attack on the body since more structure is
designed into the data to be hashed than is frequently found in the 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. body and the data is shorter in length than that of the body.
The successful prediction of the signing-time attribute is expected The successful prediction of the signing-time attribute is expected
to be more difficult than with certificates as the time would not to be more difficult than with certificates as the time would not
generally be rounded. Time stamp services can make this more generally be rounded. Time stamp services can make this more
unpredictable by using a random delay before issuing the signature. unpredictable by using a random delay before issuing the signature.
Allowing a third party to provide a hash value could potentially make Allowing a third party to provide a hash value could potentially make
an attack simpler when keyed hash functions are used since there is an attack simpler when keyed hash functions are used since there is
more data than can be modified without changing the overall structure more data than can be modified without changing the overall structure
of the signed attribute structure. of the signed attribute structure.
Author's Addresses Authors' Addresses
Sean Turner Sean Turner
IECA, Inc. IECA, Inc.
3057 Nutley Street, Suite 106 3057 Nutley Street, Suite 106
Fairfax, VA 22031 Fairfax, VA 22031
USA USA
Email: turners@ieca.com EMail: turners@ieca.com
Jim Schaad Jim Schaad
Soaring Hawk Consulting Soaring Hawk Consulting
Email: jimsch@exmsft.com EMail: jimsch@exmsft.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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).
 End of changes. 160 change blocks. 
381 lines changed or deleted 387 lines changed or added

This html diff was produced by rfcdiff 1.37c. The latest version is available from http://tools.ietf.org/tools/rfcdiff/