< draft-schaad-smime-algorithm-attribute-03.txt   draft-schaad-smime-algorithm-attribute-04.txt >
Network Working Group J. Schaad Network Working Group J. Schaad
Internet-Draft Soaring Hawk Consulting Internet-Draft Soaring Hawk Consulting
Intended status: Standards Track November 22, 2010 Intended status: Standards Track January 6, 2011
Expires: May 26, 2011 Expires: July 10, 2011
Signer Info Algorithm Protection Attribute Signer Info Algorithm Protection Attribute
draft-schaad-smime-algorithm-attribute-03 draft-schaad-smime-algorithm-attribute-04
Abstract Abstract
A new attribute is defined that allows for protection of the digest A new attribute is defined that allows for protection of the digest
and signature algorithm structures in an authenticated data or a and signature algorithm structures in an authenticated data or a
signer info structure. Using the attribute includes the algorithm signer info structure. Using the attribute includes the algorithm
definition information in the integrity protection process. definition information in the integrity protection process.
Status of this Memo Status of this Memo
skipping to change at page 1, line 33 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on May 26, 2011. This Internet-Draft will expire on July 10, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Attribute Structure . . . . . . . . . . . . . . . . . . . . . 5 2. Attribute Structure . . . . . . . . . . . . . . . . . . . . . 6
3. Verification Process . . . . . . . . . . . . . . . . . . . . . 7 3. Verification Process . . . . . . . . . . . . . . . . . . . . . 8
3.1. Signed Data Verification Changes . . . . . . . . . . . . . 7 3.1. Signed Data Verification Changes . . . . . . . . . . . . . 8
3.2. Authenticated Data Verification Changes . . . . . . . . . 7 3.2. Authenticated Data Verification Changes . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11
6.2. Informational References . . . . . . . . . . . . . . . . . 10 6.2. Informational References . . . . . . . . . . . . . . . . . 11
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 11 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
In the current definition of [CMS], there are some fields that are Over past 20 years since the original definition of CMS as PKCS #7 in
not protected in the process of doing either a signature validation 1991, the number of signature and digest algorithms has grown from a
or an authentication validation. In this document a new signed or small number to a fairly substantial number and the trend is expected
authenticated attribute is defined which permits these fields to be to accelerate in the future. This has led to a new possible attack
validated. that was not addressed at the time, the algorithm substitution
attack. In the algorithm substitution attack, the attacker looks for
collisions not only within the same algorithm as the creator of the
message used, but in all algorithms that have similar
characteristics. Thus if the creator of the message used SHA-1 as
the digest algorithm to hash the content, an attacker could look for
collisions in SHA-1, SHA-0 or RIPEMD-160 if those algorithms were in
use at the time the message was created. Once a collision had been
found, the attacker would change both the message content and the
digest identifier in the message.
Taking the SignerInfo structure from CMS, let's look at each of the If one looks at parameterized algorithms, then attacker could also
fields and discuss what is and is not protected by the signature. potentially attack the set of parameters that are chosen by the
The ASN.1 is included here for convenience. (The analysis of message creator. We currently have RSASSA-PSS as a parameterized
AuthenticatedData is similar.) signature algorithm and a number different hash algorithms have been
proposed (such as randomized hashing in [RANDOM-HASH]). Part of the
security proof for these algorithms assumes that the attacker does
not have the ability to select the parameters, although in the case
of a choice of digest algorithms it may influence them.
Algorithm substitution attacks are of greater interest to situations
where messages are expected to be long-lived than for very short term
messages. It is much simpler to prove what the current set of
constraints of a system are in the present time than it is for a
great deal of time in the past. Thus this attribute is expected to
be of greater interest in the timestamping and archiving communities
than in the S/MIME community.
In the current definition of [CMS], there are fields that are not
protected for either signature or authentication validation. In this
document a new signed or authenticated attribute is defined which
permits these fields to be protected as part of the validation
process.
Using the SignerInfo structure from CMS, let's look at each of the
fields in that structure and discuss what is and is not protected by
the signature. The ASN.1 is included here for convenience. (The
analysis of AuthenticatedData is similar.)
SignerInfo ::= SEQUENCE { SignerInfo ::= SEQUENCE {
version CMSVersion, version CMSVersion,
sid SignerIdentifier, sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier, digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier, signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue, signature SignatureValue,
unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
version is not protected by the signature. Many implementations of version is not protected by the signature. Many implementations of
CMS today actually ignore the value of this field. If the CMS today just ignore the value of this field. If the structure
structure decodes then this is considered sufficient to continue decodes then this is considered sufficient to continue processing.
processing. Using most decoders on the market the value of this Using most decoders on the market the value of this field does not
field does not control how the decoding is actually processed. control how the decoding is processed.
sid can be protected by the use of either version of the signing sid can be protected by the use of either version of the signing
certificate authenticated attribute. SigningCertificateV2 is certificate authenticated attribute. SigningCertificateV2 is
defined in [RFC5035]. SigningCertificate is defined in [RFC2634]. defined in [RFC5035]. SigningCertificate is defined in
In addition to allowing for the protection of the signer [ESS-BASE]. In addition to allowing for the protection of the
identifier, the specific certificate is protected by including a signer identifier, the specific certificate is protected by
hash of the certificate to be used for validation. including a hash of the certificate to be used for validation.
digestAlgorithm the digest algorithm used has been implicitly digestAlgorithm the digest algorithm used has been implicitly
protected by the fact that CMS has only defined one digest protected by the fact that CMS has only defined one digest
algorithm for each hash value length. (The algorithm RIPEM-160 algorithm for each hash value length. (The algorithm RIPEM-160
was never standardized). If newer digest algorithms are defined was never standardized). If newer digest algorithms are defined
where there are multiple algorithms for a given hash length, or where there are multiple algorithms for a given hash length, or
where parameters are defined for a specific algorithm, this where parameters are defined for a specific algorithm, this
implicit protection will no longer exist. implicit protection will no longer exist.
signedAttributes are directly protected by the signature when they signedAttributes are directly protected by the signature when they
are present. The DER encoding of this value is what is actually are present. The DER encoding of this value is what is hashed for
hashed for the signature computation. the signature computation.
signatureAlgorithm has been protected by implication in the past. signatureAlgorithm has been protected by implication in the past.
The use of an RSA public key implied that the RSA v 1.5 signature The use of an RSA public key implied that the RSA v 1.5 signature
algorithm was being used. The hash algorithm and this fact could algorithm was being used. The hash algorithm and this fact could
be checked by the internal padding defined. This is no longer be checked by the internal padding defined. This is no longer
true with the addition of the RSA-PSS signature algorithms. The true with the addition of the RSA-PSS signature algorithms. The
use of a DSA public key implied the SHA-1 hash algorithm as that use of a DSA public key implied the SHA-1 hash algorithm as that
was the only possible hash algorithm and the DSA was the public was the only possible hash algorithm and the DSA was the public
signature algorithm. This is longer true with the addition of the signature algorithm. This is longer true with the addition of the
SHA2 signature algorithms. SHA2 signature algorithms.
skipping to change at page 5, line 43 skipping to change at page 6, line 43
WITH COMPONENTS { signatureAlgorithm ABSENT, WITH COMPONENTS { signatureAlgorithm ABSENT,
macAlgorithm PRESENT }) macAlgorithm PRESENT })
The fields are defined as follows: The fields are defined as follows:
digestAlgorithm contains a copy of the SignerInfo.digestAlgorithm digestAlgorithm contains a copy of the SignerInfo.digestAlgorithm
field or the AuthenticatedData.digestAlgorithm field including any field or the AuthenticatedData.digestAlgorithm field including any
parameters associated with it. parameters associated with it.
signatureAlgorithm contains a copy of the signature algorithm signatureAlgorithm contains a copy of the signature algorithm
identifier and any parameters associated with it. This field is identifier and any parameters associated with it
only populated if the attribute is placed in a (SignerInfo.signatureAlgorithm). This field is only populated if
SignerInfo.signedAttrs sequence. the attribute is placed in a SignerInfo.signedAttrs sequence.
macAlgorithm contains a copy of the message authentication code macAlgorithm contains a copy of the message authentication code
algorithm identifier and any parameters associated with it. This algorithm identifier and any parameters associated with it
field is only populated if the attribute is placed in an (AuthenticatedData.macAlgorithm). This field is only populated if
AuthenticatedData.authAttrs sequence. the attribute is placed in an AuthenticatedData.authAttrs
sequence.
Exactly one of signatureAlgorithm and macAlgorithm SHALL be present. Exactly one of signatureAlgorithm and macAlgorithm SHALL be present.
An algorithm-protection attribute MUST have a single attribute value, An algorithm-protection attribute MUST have a single attribute value,
even though the syntax is defined as a SET OF AttributeValue. There even though the syntax is defined as a SET OF AttributeValue. There
MUST NOT be zero or multiple instances of AttributeValue present. MUST NOT be zero or multiple instances of AttributeValue present.
The algorithm-protection attribute MUST be a signed attribute or an The algorithm-protection attribute MUST be a signed attribute or an
authenticated attribute; it MUST NOT be an unsigned attribute, an authenticated attribute; it MUST NOT be an unsigned attribute, an
unauthenticated attribute or an unprotected attribute. unauthenticated attribute or an unprotected attribute.
skipping to change at page 7, line 37 skipping to change at page 8, line 37
signatureAlgorithm field in the attribute. If the fields are not the signatureAlgorithm field in the attribute. If the fields are not the
same (modulo encoding) then the signature validation MUST fail. same (modulo encoding) then the signature validation MUST fail.
3.2. Authenticated Data Verification Changes 3.2. Authenticated Data Verification Changes
If a CMS validator supports this attribute, the following additional If a CMS validator supports this attribute, the following additional
verification steps MUST be performed: verification steps MUST be performed:
1. The AuthenticatedData.digestAlgorithm field MUST be compared to 1. The AuthenticatedData.digestAlgorithm field MUST be compared to
the digestAlgorithm field in the attribute. If the fields are not the digestAlgorithm field in the attribute. If the fields are not
same (modulo encoding) then signature validation MUST fail. same (modulo encoding) then authentication MUST fail.
2. The AuthenticatedData.macAlgorithm field MUST be compared to the 2. The AuthenticatedData.macAlgorithm field MUST be compared to the
macAlgorithm field in the attribute. If the fields are not the same macAlgorithm field in the attribute. If the fields are not the same
(modulo encoding) then the signature validation MUST fail. (modulo encoding) then the authentication MUST fail.
4. IANA Considerations 4. IANA Considerations
There are no IANA considerations. All identifiers are assigned out There are no IANA considerations. All identifiers are assigned out
of the S/MIME OID arc. of the S/MIME OID arc.
5. Security Considerations 5. Security Considerations
This document is designed to address the security issue of algorithm This document is designed to address the security issue of algorithm
substitutions of the algorithms used by the validator. At this time substitutions of the algorithms used by the validator. At this time
there is no known method to exploit this type of attack. If the there is no known method to exploit this type of attack. If the
attack could be successful, then either a weaker algorithm could be attack could be successful, then either a weaker algorithm could be
substituted for a stronger algorithm or the parameters could be substituted for a stronger algorithm or the parameters could be
modified by an attacker to change the behavior of the hashing modified by an attacker to change the behavior of the hashing
algorithm used. (One example would be changing the initial parameter algorithm used. (One example would be changing the initial parameter
value for [I-D.schaad-smime-hash-experiment].) value for [XOR-HASH].)
The attribute defined in this document is to be placed in a location The attribute defined in this document is to be placed in a location
that is protected by the signature or message authentication code. that is protected by the signature or message authentication code.
This attribute does not provide any additional security if placed in This attribute does not provide any additional security if placed in
an un-signed or un-authenticated location. an un-signed or un-authenticated location.
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2634] Hoffman, P., "Enhanced Security Services for S/MIME", [ESS-BASE]
Hoffman, P., "Enhanced Security Services for S/MIME",
RFC 2634, June 1999. RFC 2634, June 1999.
[RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update: [RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update:
Adding CertID Algorithm Agility", RFC 5035, August 2007. Adding CertID Algorithm Agility", RFC 5035, August 2007.
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", [CMS] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 5652, September 2009. RFC 5652, September 2009.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
June 2010. June 2010.
6.2. Informational References 6.2. Informational References
[I-D.schaad-smime-hash-experiment] [XOR-HASH]
Schaad, J., "Experiment: Hash functions with parameters in Schaad, J., "Experiment: Hash functions with parameters in
CMS and S/MIME", draft-schaad-smime-hash-experiment-01 CMS and S/MIME", draft-schaad-smime-hash-experiment-01
(work in progress), December 2009. (work in progress), December 2009.
[RANDOM-HASH]
Halevi, S. and H. Krawczyk, "Randomized Hashing: Secure
Digital Signatures without Collision Resistance", IETF 74.
Appendix A. ASN.1 Module Appendix A. ASN.1 Module
CMSAlgorithmProtectionAttribute CMSAlgorithmProtectionAttribute
{ 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) pkcs(1) pkcs-9(9) smime(16) modules(0)
id-mod-cms-algorithmProtect(52) } id-mod-cms-algorithmProtect(52) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
IMPORTS IMPORTS
 End of changes. 19 change blocks. 
47 lines changed or deleted 84 lines changed or added

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