< draft-schaad-smime-algorithm-attribute-04.txt   draft-schaad-smime-algorithm-attribute-05.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 January 6, 2011 Intended status: Standards Track January 24, 2011
Expires: July 10, 2011 Expires: July 28, 2011
Signer Info Algorithm Protection Attribute Cryptographic Messages Syntax (CMS) Algorithm Identifier Protection
draft-schaad-smime-algorithm-attribute-04 Attribute
draft-schaad-smime-algorithm-attribute-05
Abstract Abstract
A new attribute is defined that allows for protection of the digest The Cryptographic Message Syntax (CMS) unlike X.509/PKIX
and signature algorithm structures in an authenticated data or a certificates, are venerable to algorithm substitution attacks. In an
signer info structure. Using the attribute includes the algorithm algorithm substitution attack, the attacker changes either the
definition information in the integrity protection process. algorithm being used or parameters of the algorithm in order to
change the result of a signature verification process. In X.509
certificates, the signature algorithm is protected because it is
duplicated in the TBSCertificate.signature field with the proviso
that the validater is to compare both fields as part of the signature
validation process. This document defines a new attribute that
contains a copy of the relevant algorithm identifiers so that they
are protected by the signature or authentication process.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 July 10, 2011. This Internet-Draft will expire on July 28, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
skipping to change at page 2, line 18 skipping to change at page 2, line 25
1.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Attribute Structure . . . . . . . . . . . . . . . . . . . . . 6 2. Attribute Structure . . . . . . . . . . . . . . . . . . . . . 6
3. Verification Process . . . . . . . . . . . . . . . . . . . . . 8 3. Verification Process . . . . . . . . . . . . . . . . . . . . . 8
3.1. Signed Data Verification Changes . . . . . . . . . . . . . 8 3.1. Signed Data Verification Changes . . . . . . . . . . . . . 8
3.2. Authenticated Data Verification Changes . . . . . . . . . 8 3.2. Authenticated Data Verification Changes . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11
6.2. Informational References . . . . . . . . . . . . . . . . . 11 6.2. Informational References . . . . . . . . . . . . . . . . . 11
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 12 Appendix A. 2008 ASN.1 Module . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
Over past 20 years since the original definition of CMS as PKCS #7 in The Cryptographic Message Syntax (CMS) [CMS] unlike X.509/PKIX
1991, the number of signature and digest algorithms has grown from a certificates [RFC5280], are venerable to algorithm substitution
small number to a fairly substantial number and the trend is expected attacks. In an algorithm substitution attack, the attacker changes
to accelerate in the future. This has led to a new possible attack either the algorithm being used or parameters of the algorithm in
that was not addressed at the time, the algorithm substitution order to change the result of a signature verification process. In
attack. In the algorithm substitution attack, the attacker looks for X.509 certificates, the signature algorithm is protected because it
collisions not only within the same algorithm as the creator of the is duplicated in the TBSCertificate.signature field with the proviso
message used, but in all algorithms that have similar that the validater is to compare both fields as part of the signature
characteristics. Thus if the creator of the message used SHA-1 as validation process. This document defines a new attribute that
the digest algorithm to hash the content, an attacker could look for contains a copy of the relevant algorithm identifiers so that they
collisions in SHA-1, SHA-0 or RIPEMD-160 if those algorithms were in are protected by the signature or authentication process.
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.
If one looks at parameterized algorithms, then attacker could also In an algorithm substitution attack, the attacker looks for a
potentially attack the set of parameters that are chosen by the different algorithm that produces the same result as the algorithm
message creator. We currently have RSASSA-PSS as a parameterized used by the signer. As an example, if the creator of the message
signature algorithm and a number different hash algorithms have been used SHA-1 as the digest algorithm to hash the message content then
proposed (such as randomized hashing in [RANDOM-HASH]). Part of the the attacker looks for a different hash algorithm that produces a
security proof for these algorithms assumes that the attacker does result that is the same length, but with which it is easier to find
not have the ability to select the parameters, although in the case collisions. Examples of other algorithms that produce a hash value
of a choice of digest algorithms it may influence them. of the same length would be SHA-0 or RIPEMD-160. Similar attacks can
be mounted against parameterized algorithm identifiers. When looking
at some of the proposed randomized hashing functions, such as that in
[RANDOM-HASH], the associated security proofs assume that the
parameters are solely under the control of the originator and not
subject to selection by the attacker.
Algorithm substitution attacks are of greater interest to situations Some algorithms have been internally designed to be more resistant to
where messages are expected to be long-lived than for very short term this type of attack. Thus an RSA PKCS #1 v.15 signature [RFC3447]
messages. It is much simpler to prove what the current set of cannot have the associated hash algorithm changed because it is
constraints of a system are in the present time than it is for a encoded as part of the signature. DSA was originally defined so that
great deal of time in the past. Thus this attribute is expected to it would only work with SHA-1 as a hash algorithm, thus by knowing
be of greater interest in the timestamping and archiving communities the public key from the certificate, a validator can be assured that
than in the S/MIME community. the hash algorithm can not be changed. There is a convention,
undocumented as far as I can tell, that the same hash algorithm
should be used for both the content digest and the signature digest.
There are cases, such as third party signers that are only given a
content digest, where such a convention cannot be enforced.
In the current definition of [CMS], there are fields that are not As with all attacks, the attack is going to be desirable on items
protected for either signature or authentication validation. In this that are both long term and high value. One would expect that these
document a new signed or authenticated attribute is defined which attacks are more likely to be made on older documents as the
permits these fields to be protected as part of the validation algorithms being used when the message was signed would be more
process. likely to have degraded over time. Countersigning, the classic
method of protecting a signature does not provide any additional
protection against an algorithm substitution attack because
countersignatures sign just the signature, but the algorithm
substitution attacks leave the signature value alone while changing
the algorithms being used.
Using the SignerInfo structure from CMS, let's take a more detailed
look at each of the fields in the structure and discuss what fields
are and are not protected by the signature. I have included a copy
of the ASN.1 here for convenience. A similar analysis of the
AuthenticatedData structure is left to the reader, but it can be done
in much the same way.
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. As many implementations
CMS today just ignore the value of this field. If the structure of CMS today ignore the value of this field that is not a problem.
decodes then this is considered sufficient to continue processing. If the value is increased, then no changes in the processing are
Using most decoders on the market the value of this field does not expected. If the value is decreased, implementations that respect
control how the decoding is processed. the structure would fail to decode, but an erroneous signature
validation would not be completed successfully.
sid can be protected by the use of either version of the signing sid can be protected using either version of the signing certificate
certificate authenticated attribute. SigningCertificateV2 is authenticated attribute. SigningCertificateV2 is defined in
defined in [RFC5035]. SigningCertificate is defined in [RFC5035]. SigningCertificate is defined in [ESS-BASE]. In
[ESS-BASE]. In addition to allowing for the protection of the addition to allowing for the protection of the signer identifier,
signer identifier, the specific certificate is protected by the specific certificate is protected by including a hash of the
including a hash of the certificate to be used for validation. 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). There is also an unwritten convention
where there are multiple algorithms for a given hash length, or that the same digest algorithm should be used both here and for
where parameters are defined for a specific algorithm, this the signature algorithm. If newer digest algorithms are defined
implicit protection will no longer exist. so that there are multiple algorithms for a given hash length (it
is expected that the SHA-3 project will do so), or that parameters
are defined for a specific algorithm, much of the implicit
protection will be lost.
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 hashed for are present. The DER encoding of this value is what is 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 still somewhat true as there is an
SHA2 signature algorithms. implicit tie between the length of the DSA public key and the
length of the hash algorithm to be used, but this is known by
convention and there is no explicit enforcement for this.
signature is not directly protected by any other value unless a signature is not directly protected by any other value unless a
counter signature is present. However this represents the counter signature is present. However this represents the
cryptographically computed value that protects the rest of the cryptographically computed value that protects the rest of the
signature information. signature information.
unsignedAttrs is not protected by the signature value. It is also unsignedAttrs is not protected by the signature value. It is also
explicitly designed not to be protected by the signature value. explicitly designed that they not to be protected by the signature
value.
As can be seen above, the digestAlgorithm and signatureAlgorithm As can be seen above, the digestAlgorithm and signatureAlgorithm
fields have been indirectly rather than explicitly protected in the fields have been indirectly rather than explicitly protected in the
past. With new algorithms that have been or are being defined this past. With new algorithms that have been or are being defined this
will no longer be the case. This document defines and describes a will no longer be the case. This document defines and describes a
new attribute that will explicitly protect these fields along with new attribute that will explicitly protect these fields along with
the macAlgorithm field of the AuthenticatedData structure. the macAlgorithm field of the AuthenticatedData structure.
1.1. Notation 1.1. Notation
skipping to change at page 8, line 7 skipping to change at page 8, line 7
unauthenticated attribute or an unprotected attribute. unauthenticated attribute or an unprotected attribute.
The SignedAttributes and AuthAttributes syntax are each defined as a The SignedAttributes and AuthAttributes syntax are each defined as a
SET of Attributes. The SignedAttributes in a signerInfo MUST include SET of Attributes. The SignedAttributes in a signerInfo MUST include
only one instance of the algorithm protection attribute. Similarly, only one instance of the algorithm protection attribute. Similarly,
the AuthAttributes in an AuthenticatedData MUST include only one the AuthAttributes in an AuthenticatedData MUST include only one
instance of the algorithm protection attribute. instance of the algorithm protection attribute.
3. Verification Process 3. Verification Process
The exact verification process depends on the structure being dealt While the exact verification steps depends on the structure that is
with. being validated, there are some common rules that are to be followed
when comparing the two algorithm structures:
When doing comparisons of the fields, a field whose value is a o A field with a default value MUST compare as being the same
default value and one which is explicitly provided MUST compare as independent of whether the value is defaulted or is explicitly
equivalent. It is not required that a field which is absent in one provided.
case and present in another case be compared as equivalent. (This
means that an algorithm identifier with absent parameters and one o It is implementation dependent if, for some algorithms, the
with NULL parameters are not expected to compare as equivalent.) absence of a parameter and the presence of a NULL parameter are
compared as being equivalent. This behavior SHOULD NOT be
expected. This is an issue because some implementations will omit
a NULL element, while other will encode a NULL element for some
digest algorithms such as SHA-1 (see the comments in section 2.1
of [RFC3370]). The issue is even worse because the NULL is absent
in some cases ([RFC3370]), but is required in other cases (for
example see [RFC4056]).
3.1. Signed Data Verification Changes 3.1. Signed 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 SignerInfo.digestAlgorithm field MUST be compared to the 1. The SignerInfo.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 the
same (modulo encoding) then signature validation MUST fail. same (modulo encoding) then signature validation MUST fail.
skipping to change at page 11, line 26 skipping to change at page 11, line 26
[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.
[ASN.1-2008]
ITU-T, "ITU-T Recommendations X.680, X.681, X.682, and
X.683", 2008.
6.2. Informational References 6.2. Informational References
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, August 2002.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.
[RFC4056] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in
Cryptographic Message Syntax (CMS)", RFC 4056, June 2005.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[XOR-HASH] [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-06
(work in progress), December 2009. (work in progress), January 2011.
[RANDOM-HASH] [RANDOM-HASH]
Halevi, S. and H. Krawczyk, "Randomized Hashing: Secure Halevi, S. and H. Krawczyk, "Randomized Hashing: Secure
Digital Signatures without Collision Resistance", IETF 74. Digital Signatures without Collision Resistance", IETF 74.
Appendix A. ASN.1 Module Appendix A. 2008 ASN.1 Module
The ASN.1 module defined uses the 2008 ASN.1 definitions found in
[ASN.1-2008]. This module contains the ASN.1 module which contains
the required defintions for the types and values defined in this
document. The module uses the ATTRIBUTE class defined in [RFC5912].
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
-- Cryptographic Message Syntax (CMS) [CMS] -- Cryptographic Message Syntax (CMS) [CMS]
skipping to change at page 13, line 4 skipping to change at page 14, line 10
id-aa-cmsAlgorithmProtect OBJECT IDENTIFIER ::= { id-aa-cmsAlgorithmProtect OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs9(9) 52 } pkcs9(9) 52 }
CMSAlgorithmProtection ::= SEQUENCE { CMSAlgorithmProtection ::= SEQUENCE {
digestAlgorithm DigestAlgorithmIdentifier, digestAlgorithm DigestAlgorithmIdentifier,
signatureAlgorithm [1] SignatureAlgorithmIdentifier OPTIONAL, signatureAlgorithm [1] SignatureAlgorithmIdentifier OPTIONAL,
macAlgorithm [2] MessageAuthenticationCodeAlgorithm macAlgorithm [2] MessageAuthenticationCodeAlgorithm
OPTIONAL OPTIONAL
} }
(WITH COMPONENTS { signatureAlgorithm PRESENT, (WITH COMPONENTS { signatureAlgorithm PRESENT,
macAlgorithm ABSENT } | macAlgorithm ABSENT } |
WITH COMPONENTS { signatureAlgorithm ABSENT, WITH COMPONENTS { signatureAlgorithm ABSENT,
macAlgorithm PRESENT }) macAlgorithm PRESENT })
END END
Author's Address Author's Address
Jim Schaad Jim Schaad
Soaring Hawk Consulting Soaring Hawk Consulting
PO Box 675
Gold Bar, WA 98251
Email: ietf@augustcellars.com Email: ietf@augustcellars.com
 End of changes. 23 change blocks. 
81 lines changed or deleted 139 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/