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

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