draft-ietf-smime-multisig-01.txt   draft-ietf-smime-multisig-02.txt 
S/MIME WG Sean Turner, IECA S/MIME WG Sean Turner, IECA
Internet Draft Jim Schaad, Soaring Hawk Internet Draft Jim Schaad, Soaring Hawk
Intended Status: Standard Track June 26, 2007 Intended Status: Standard Track July 24, 2007
Expires: December 26, 2007 Expires: January 24, 2008
Multiple Signatures in S/MIME Multiple Signatures in S/MIME
draft-ietf-smime-multisig-01.txt draft-ietf-smime-multisig-02.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 Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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.txt 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 December 26, 2007. This Internet-Draft will expire on January 24, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
CMS SignedData includes the SignerInfo structure to convey per-signer CMS SignedData includes the SignerInfo structure to convey per-signer
information. SignedData supports multiple signers and multiple information. SignedData supports multiple signers and multiple
signature algorithms per-signer with multiple SignerInfo structures. signature algorithms per-signer with multiple SignerInfo structures.
skipping to change at page 2, line 24 skipping to change at page 2, line 24
Discussion Discussion
This draft is being discussed on the 'ietf-smime' mailing list. To This draft is being discussed on the 'ietf-smime' mailing list. To
subscribe, send a message to ietf-smime-request@imc.org with the 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 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/>. for the mailing list at <http://www.imc.org/ietf-smime/>.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction......................................... 3
2. Rationale......................................................3 2. Rationale........................................... 3
2.1. Attacks...................................................3 2.1. Attribute Design Requirements....................... 4
2.2. Hashes in CMS.............................................4 3. Multiple Signature Indication........................... 5
2.3. Downgrade Attack..........................................6 4. Message Generation and Processing ....................... 6
2.4. Attribute Design Requirements.............................6 4.1. SignedData Type.................................. 6
3. Multiple Signature Indication..................................7 4.2. EncapsulatedContentInfo Type ....................... 7
4. Message Generation and Processing..............................8 4.3. SignerInfo Type.................................. 7
4.1. SignedData Type...........................................8 4.4. Message Digest Calculation Process .................. 7
4.2. EncapsulatedContentInfo Type..............................9 4.4.1. multiple-signatures Signed Attribute Generation.... 7
4.3. SignerInfo Type...........................................9 4.4.2. Message Digest calculation Process.............. 8
4.4. Message Digest Calculation Process........................9 4.5. Signature Generation Process ....................... 8
4.4.1. multiple-signatures Signed Attribute Generation......9 4.6. Signature Verification Process...................... 8
4.4.2. Message Digest calculation Process..................10 5. Signature Evaluation Processing......................... 8
4.5. Signature Generation Process.............................10 5.1. Evaluation of a SignerInfo object................... 9
4.6. Signature Verification Process...........................10 5.2. Evaluation of a SignerInfo Set..................... 10
5. Signature Evaluation Processing...............................10 5.3. Evaluation of a SignedData Set..................... 11
5.1. Evaluation of a SignerInfo object........................11 6. Security Considerations............................... 11
5.2. Evaluation of a SignerInfo Set...........................12 7. IANA Considerations.................................. 11
6. Security Considerations.......................................13 8. References......................................... 12
7. IANA Considerations...........................................13 8.1. Normative References............................. 12
8. References....................................................14 8.2. Informative References........................... 12
8.1. Normative References.....................................14 Appendix A. ASN.1 Module................................ 13
8.2. Informative References...................................14 Appendix B. Background.................................. 15
Appendix A. ASN.1 Module.........................................15 B.1. Attacks........................................ 15
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 include in the SignerInfo structure. digital signature, which is also include in the SignerInfo structure.
Signers include more than one SignerInfo in a SignedData if they use Signers include more than one SignerInfo in a SignedData if they use
different digest or signature algorithms. Each SignerInfo exists different digest or signature algorithms. Each SignerInfo exists
independently and new SignerInfo structures can be added or an independently and new SignerInfo structures can be added or an
existing one(s) removed without perturbing the remaining existing one(s) removed without perturbing the remaining
skipping to change at page 3, line 38 skipping to change at page 3, line 38
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 an attribute, see 11.4 of [CMS], as this is not intended to sign over an
existing signature rather it is to provide a pointer to additional existing signature rather it is to provide a pointer to additional
signer's signatures that are all at the same level. That is signer's signatures that are all at the same level. That 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.
2. Rationale 2. Rationale
2.1. Attacks The rationale for this specification is to protect against downgrade
attacks that remove the 'strong' signature to leave the 'weak'
The following types of resistance against known attacks, see signature, which has presumably been successfully attacked. If a CMS
[ATTACK], is needed: object has multiple SignerInfos, then the attacker, whether it be
Alice, Bob, or Mallory, can remove SignerInfos without the relying
1) Collision Resistance: Find x and y where x != y and H(x) = H(y) party being aware that more than one was generated.
2) Preimage Resistance: Given y, find x where H(x) = y
3) Second Preimage Resistance: Given y, find x where H(x) = H(y)
Note: It is known that a collision resistance attack is simpler than
a second preimage resistance attack, and it is presumed that a second
preimage resistance attack is simplier than a preimage attack.
2.2. Hashes in CMS
Within a SignedInfo there are two places where hashes are applied and
hence can be attacked: the Body and the SignedAttributes. The
following outlines the entity that creates the hash, the entity that
attacks the hash, and the type of resistance required:
1) Hash of the Body (i.e., the octets comprising the value of the
encapContentInfo.eContent OCTET STRING omitting the tag and length
octets - as per 5.4 of [CMS]).
a) Alice creates the Body to be hashed:
i) Alice attacks the hash: This would require a successful
Collision Resistance attack.
ii) Mallory attacks the hash: This would require a successful
Second Preimage Reistance attack.
b) Alice hashes a body provided by Bob:
i) Alice attacks the hash: This would require a successful
Second Preimage Attack.
ii) Bob attacks the hash: This would require a successful
Collision Resistance attack. This can be upgraded to requiring
a successful Second Preimage Attack if Alice hash the ability
to "change" the content of the body in some fashion. (One
example would be to use a keyed hash function.)
iii) Mallory attacks the hash: This would require a successful
Second Preimage Attack.
c) Alice signs using a hash value provided by Bob. (In this case
Alice is presumed to never see the body in question.)
i) Alice attacks hash: This would require a successful Preimage
Attack.
ii) Bob attacks hash: This would require a successful Collision
Resistance attack. Unlike case (b), there is nothing that
Alice can do to upgrade the attack required.
iii) Mallory attacks the hash: This would require a success
Preimage attack if the content is unavailable to Mallory and a
successful Second Preimage attack if the content is available
to Mallory.
2) Hash of SignedAttributes (i.e., the complete DER encoding of the
SignedAttrs value contained in the signedAttrs field - as per 5.4
of [CMS]).
There is a difference between hashing the body and hashing the
SignedAttrs value in that one SHOULD NOT accept a sequence of
attributes to be signed from a third party. In fact one SHOULD NOT
accept attributes to be included in the signed attributes list from a
third party. The attributes are about the signature you are applying
and not about the body. If there is meta-information that needs to
be attached to the body by a third party then they need to provide
their own signature and you need to be doing a countersignature.
(Note: the fact that the signature is to be used as a
countersignature is a piece of information that should be accepted,
but it does not directly provide an attribute that is inserted in the
attribute list.)
a) Alice attacks the hash: This requires a successful Collision
Resistance Attack.
b) Mallory attacks the hash: This requires a successful Second
Preimage Resistance attack.
c) Bob attacks the hash and provides the body hash used: This case
is analogous to the current attacks [Attack]. Based on prediction
of the signed attributes Alice will be using and the provided hash
value and function. (It is expected that if Alice uses a keyed
hashing function as part of the signature this attack will be more
difficult.)
It should be noted that both of these attacks are considered to be
more difficult that the attack on the body since more structure is
designed into the data to be hashed than is frequently found in the
body and the data is shorter in length than that of the body.
The successful prediction of the Signing-Time attribute is expected
to more difficult than with certificates as the time would not
generally be rounded. Time stamp services can make this more
unpredictable by using a random delay before issuing the signature.
Allowing a third party to provide a hash value could potentially make
attack simpler when keyed hash functions are used since there is more
data than can be modified without changing the overall structure of
the Signed Attribute structure.
2.3. Downgrade Attack
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 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
skipping to change at page 6, line 45 skipping to change at page 4, line 36
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.
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.4. 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 premiage 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
skipping to change at page 7, line 45 skipping to change at page 5, line 40
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: 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:
- aldId MUST match the digest algorithm for the SignerInfo in -- aldId 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
skipping to change at page 11, line 26 skipping to change at page 9, line 19
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. The first is the mathematics of the that need to be examined.
signature itself (i.e., can one actually successfully do the
computations and get the correct answer). This piece ends up with a
binary answer, either it succeeds or it fails there is no middle
ground. Not necessaryily true, what about an unevaluatable
algorithm - this is nether success nor failure. From the verifiers
perspective the answer is still fail since they can't actually do the
math - so I think it's still binary.
The second is the validation of the source of the public key. For The first piece is the mathematics of the signature itself (i.e., can
CMS, this is generally determined by extracting the public key from a one actually successfully do the computations and get the correct
certificate. The certificate needs to be evaluated. This is done by answer). This result is one of three results. The mathematics
the procedures outlined in [PKIX-CERT]. In addition to the succeeds, the mathematics fails, or the mathematics cannot be
evaluated. The type of things that lead to the last state are non-
implementation of an algorithm or required inputs, such as the public
key, are missing.
The second piece is the validation of the source of 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
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 generated three states are described in [PKIX-CERT], Warning would be generated
when it is possible that some information is currently acceptable, when it is possible that some information is currently acceptable,
but may not be acceptable either in the near future or under some but may not be acceptable either in the near future or under some
circumstances. circumstances.
The third part 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.
-- 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 for Combining the results of the individual SignerInfos into a result 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 any individual SignerInfo objects, the require application policy and any
local policies. The default processing if no other rules are applied local policies. The default processing if no other rules are applied
should be: should be:
1) Segregate SignerInfo objects according to who signed. 1) Group the SignerInfo objects by the signer.
2) Take the best result from the items in the grouping; this is the 2) Take the best result from each signer.
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 different signers; this is
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 could say be done. As an example, the S/MIME message specification [MSG]
that as long as the same RFC 822 name exists in either the subject could say that as long as the same RFC 822 name exists in either
name or the subject alt name they are the same identity. This the subject name or the subject alt name they are the same
would be true even if other information that did not match existed identity. This would be true even if other information that did
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
skipping to change at page 13, line 15 skipping to change at page 11, line 7
issue is the question of having a multi-state or a binary answer as issue is the question of having a multi-state or a binary answer as
to success or failure of an evaluation. Not every application can to success or failure of an evaluation. Not every application can
deal with the statement "try again later". It may also be deal with the statement "try again later". It may also be
dependent on what the reason for the indeterminate state is. It dependent on what the reason for the indeterminate state is. It
makes more sense to try again later if the problem is that a CRL makes more sense to try again later if the problem is that a CRL
cannot be found than if you are not able to evaluate the algorithm cannot be found than if you are not able to evaluate the algorithm
for the signature. for the signature.
In Step 3: In Step 3:
- Very application dependent processing other options are: - The same policy implications from Step 2 apply here.
-- strip bad sig from the outside in - signed mail. 5.3. Evaluation of a SignedData Set
-- strip bad sigs from the inside out - work flow. For simple applications, the requirement can be made that the result
of evaluating a set of SignedData objects is the worst outcome of the
items. (I.e. one failure means the entire item fails). However not
all applications will want to have this behavior.
- Modifications of the algorithm due to the presence of other A work flow application could work as follows:
types of layers. I.e. EncryptedData/EnvelopedData or
AuthenticatedData.
Implications/differences for AuthenticatedData. The second signer will modify the original content, keep the
original signature and then sign the message. This means that only
the outermost signature is of significance during evaluation. The
second signer is asserting that they successfully validated the inner
signature as part of its processing.
A Signed Mail application could work as follows:
If signatures are added for the support of [ESS] features, then the
fact that an outer layer signature can be treated as a non-
significant failure. The only thing that matters is that the
originator signature is valid. This means that all outer layer
signatures which fail can be stripped from the message prior to
display leaving only the inner-most valid signature to be displayed.
6. Security Considerations 6. Security Considerations
If another entity is providing hash to be signed, then ensure it is a If another entity is providing hash to be signed, then ensure it is a
"trustworthy" source. "trustworthy" source.
This attribute provides no protection if all of the algorithms used This attribute provides no protection if all of the algorithms used
in the signer attribute are 'cracked'. in the signer attribute are 'cracked'.
Protection against attacks in the future are also not protected Protection against attacks in the future are also not protected
skipping to change at page 14, line 12 skipping to change at page 12, line 12
None: All identifiers are already registered. Please remove this None: All identifiers are already registered. Please remove this
section prior to publication as an RFC. section prior to publication as an RFC.
8. References 8. References
8.1. Normative 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.
[ESSCertID] Schaad, J., "ESS Update: Adding CertID Algorithm
Agility", draft-ietf-smime-esscertid-05.txt, work in
progress, March 2007.
[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 [MSG] Ramsdell, B., and S. Turner, "Secure Multipurpose
Agility", draft-ietf-smime-esscertid-05.txt, work in Internet Mail Extensions (S/MIME) Version 3.2 Message
progress, March 2007. Specification", work in progress.
8.2. Informative 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.
Appendix A. ASN.1 Module Appendix A. ASN.1 Module
MultipleSignatures MultipleSignatures
skipping to change at page 16, line 16 skipping to change at page 15, line 5
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
Appendix B. Background
This is an informative appendix that looks at the locations of hashes
CMS and possible attacks against them.
B.1. Attacks
The following types of resistance against known attacks, see
[ATTACK], is needed:
1) Collision Resistance: Find x and y where x != y and H(x) = H(y)
2) Preimage Resistance: Given y, find x where H(x) = y
3) Second Preimage Resistance: Given y, find x where H(x) = H(y)
Note: It is known that a collision resistance attack is simpler than
a second preimage resistance attack, and it is presumed that a second
preimage resistance attack is simplier than a preimage attack.
B.2. Hashes in CMS
Within a SignedInfo there are two places where hashes are applied and
hence can be attacked: the Body and the SignedAttributes. The
following outlines the entity that creates the hash, the entity that
attacks the hash, and the type of resistance required:
1) Hash of the Body (i.e., the octets comprising the value of the
encapContentInfo.eContent OCTET STRING omitting the tag and length
octets - as per 5.4 of [CMS]).
a) Alice creates the Body to be hashed:
i) Alice attacks the hash: This would require a successful
Collision Resistance attack.
ii) Mallory attacks the hash: This would require a successful
Second Preimage Reistance attack.
b) Alice hashes a body provided by Bob:
i) Alice attacks the hash: This would require a successful
Second Preimage Attack.
ii) Bob attacks the hash: This would require a successful
Collision Resistance attack. This can be upgraded to requiring
a successful Second Preimage Attack if Alice hash the ability
to "change" the content of the body in some fashion. (One
example would be to use a keyed hash function.)
iii) Mallory attacks the hash: This would require a successful
Second Preimage Attack.
c) Alice signs using a hash value provided by Bob. (In this case
Alice is presumed to never see the body in question.)
i) Alice attacks hash: This would require a successful Preimage
Attack.
ii) Bob attacks hash: This would require a successful Collision
Resistance attack. Unlike case (b), there is nothing that
Alice can do to upgrade the attack required.
iii) Mallory attacks the hash: This would require a success
Preimage attack if the content is unavailable to Mallory and a
successful Second Preimage attack if the content is available
to Mallory.
2) Hash of SignedAttributes (i.e., the complete DER encoding of the
SignedAttrs value contained in the signedAttrs field - as per 5.4
of [CMS]).
There is a difference between hashing the body and hashing the
SignedAttrs value in that one SHOULD NOT accept a sequence of
attributes to be signed from a third party. In fact one SHOULD NOT
accept attributes to be included in the signed attributes list from a
third party. The attributes are about the signature you are applying
and not about the body. If there is meta-information that needs to
be attached to the body by a third party then they need to provide
their own signature and you need to be doing a countersignature.
(Note: the fact that the signature is to be used as a
countersignature is a piece of information that should be accepted,
but it does not directly provide an attribute that is inserted in the
attribute list.)
a) Alice attacks the hash: This requires a successful Collision
Resistance Attack.
b) Mallory attacks the hash: This requires a successful Second
Preimage Resistance attack.
c) Bob attacks the hash and provides the body hash used: This case
is analogous to the current attacks [Attack]. Based on prediction
of the signed attributes Alice will be using and the provided hash
value and function. (It is expected that if Alice uses a keyed
hashing function as part of the signature this attack will be more
difficult.)
It should be noted that both of these attacks are considered to be
more difficult that the attack on the body since more structure is
designed into the data to be hashed than is frequently found in the
body and the data is shorter in length than that of the body.
The successful prediction of the Signing-Time attribute is expected
to more difficult than with certificates as the time would not
generally be rounded. Time stamp services can make this more
unpredictable by using a random delay before issuing the signature.
Allowing a third party to provide a hash value could potentially make
attack simpler when keyed hash functions are used since there is more
data than can be modified without changing the overall structure of
the Signed Attribute structure.
Author's Addresses Author's Addresses
Sean Turner Sean Turner
IECA, Inc. IECA, Inc.
Email: turners (at) ieca (dot) com Email: turners (at) ieca (dot) com
Jim Schaad Jim Schaad
Soaring Hawk Consulting Soaring Hawk Consulting
 End of changes. 29 change blocks. 
187 lines changed or deleted 208 lines changed or added

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