draft-ietf-smime-multisig-02.txt   draft-ietf-smime-multisig-03.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 July 24, 2007 Intended Status: Standard Track November 16, 2007
Expires: January 24, 2008 Expires: May 16, 2008
Multiple Signatures in S/MIME Multiple Signatures in S/MIME
draft-ietf-smime-multisig-02.txt draft-ietf-smime-multisig-03.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 January 24, 2008. This Internet-Draft will expire on May 16, 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. Attribute Design Requirements....................... 4 2.1. Attribute Design Requirements.............................4
3. Multiple Signature Indication........................... 5 3. Multiple Signature Indication..................................5
4. Message Generation and Processing ....................... 6 4. Message Generation and Processing..............................6
4.1. SignedData Type.................................. 6 4.1. SignedData Type...........................................6
4.2. EncapsulatedContentInfo Type ....................... 7 4.2. EncapsulatedContentInfo Type..............................7
4.3. SignerInfo Type.................................. 7 4.3. SignerInfo Type...........................................7
4.4. Message Digest Calculation Process .................. 7 4.4. Message Digest Calculation Process........................7
4.4.1. multiple-signatures Signed Attribute Generation.... 7 4.4.1. multiple-signatures Signed Attribute Generation......7
4.4.2. Message Digest calculation Process.............. 8 4.4.2. Message Digest calculation Process...................8
4.5. Signature Generation Process ....................... 8 4.5. Signature Generation Process..............................8
4.6. Signature Verification Process...................... 8 4.6. Signature Verification Process............................8
5. Signature Evaluation Processing......................... 8 5. Signature Evaluation Processing................................8
5.1. Evaluation of a SignerInfo object................... 9 5.1. Evaluation of a SignerInfo object.........................9
5.2. Evaluation of a SignerInfo Set..................... 10 5.2. Evaluation of a SignerInfo Set...........................10
5.3. Evaluation of a SignedData Set..................... 11 5.3. Evaluation of a SignedData Set...........................11
6. Security Considerations............................... 11 6. Security Considerations.......................................11
7. IANA Considerations.................................. 11 7. IANA Considerations...........................................12
8. References......................................... 12 8. References....................................................12
8.1. Normative References............................. 12 8.1. Normative References.....................................12
8.2. Informative References........................... 12 8.2. Informative References...................................12
Appendix A. ASN.1 Module................................ 13 Appendix A. ASN.1 Module.........................................13
Appendix B. Background.................................. 15 Appendix B. Background...........................................15
B.1. Attacks........................................ 15 B.1. Attacks..................................................15
B.2. Hashes in CMS................................... 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 9, line 32 skipping to change at page 9, line 32
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 [PKIX-CERT]. 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 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 [PROFILE], 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 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
skipping to change at page 10, line 28 skipping to change at page 10, line 28
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 [MSG] be done. As an example, the S/MIME message specification [SMIME-
could say that as long as the same RFC 822 name exists in either MSG] could say that as long as the same RFC 822 name exists in
the subject name or the subject alt name they are the same either 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:
skipping to change at page 11, line 35 skipping to change at page 11, line 35
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 can be treated as a non- fact that an outer layer signature can be treated as a non-
significant failure. The only thing that matters is that the significant failure. The only thing that matters is that the
originator signature is valid. This means that all outer layer originator signature is valid. This means that all outer layer
signatures which fail can be stripped from the message prior to signatures which 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
If another entity is providing hash to be signed, then ensure it is a Security considerations from the hash and signature algorithms used
"trustworthy" source. to produce the SignerInfo apply.
If the hashing and signing operations are performed by different
entities, the entity performing the signature must ensure the hash
comes from a "trustworthy" source. This can be partially mitigated by
requiring that multiple hashes using different algorithms are
provided.
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 Local policy and applications greatly affects signature processing.
against. The application of local policy and the requirements specific to an
application can both affect signature processing. This means that a
//** Needs more work signature valid in one context or location can fail validation in a
different context or location.
7. IANA Considerations 7. IANA Considerations
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
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[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 [PROFILE] Housley, R., Polk, W., Ford, W., and D. Solo,
Agility", draft-ietf-smime-esscertid-05.txt, work in "Internet X.509 Public Key Infrastructure Certificate
progress, March 2007. and Certificate Revocation List (CRL) Profile", RFC
3280, April 2002.
[PROFILE] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet [SMIME-CERT] Ramsdell, B., and S. Turner, "Secure Multipurpose
X.509 Public Key Infrastructure Certificate and Internet Mail Extensions (S/MIME) Version 3.2
Certificate Revocation List (CRL) Profile", RFC 3280, Certificate Handling", work in progress.
April 2002.
[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", work in progress.
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME",
RFC 2634, June 1999.
[ESSCertID] Schaad, J., "ESS Update: Adding CertID Algorithm
Agility", RFC 5035, August 2007.
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
{ 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 ::=
skipping to change at page 16, line 49 skipping to change at page 16, line 49
but it does not directly provide an attribute that is inserted in the but it does not directly 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 case c) Bob attacks the hash and provides the body hash used: This case
is analogous to the current attacks [Attack]. Based on prediction is analogous to the current attacks [ATTACK]. Based on prediction
of the signed attributes Alice will be using and the provided hash of the signed attributes Alice will be using and the provided hash
value and function. (It is expected that if Alice uses a keyed value and function. (It is expected that if Alice uses a keyed
hashing function as part of the signature this attack will be more hashing function as part of the signature this attack will be more
difficult.) difficult.)
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 that the attack on the body since more structure is 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 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.
 End of changes. 16 change blocks. 
52 lines changed or deleted 69 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/