Soaring Hawk Consulting

PO Box 675 Gold Bar WA 98251 ietf@augustcellars.com

A new attribute is defined that allows for protection of the digest and signature algorithm structures in an authenticated data or a signer info structure. Using the attribute includes the algorithm definition information in the integrity protection process.

In the current definition of , there are some fields that are not protected in the process of doing either a signature validation or an authentication validation. In this document a new signed or authenticated attribute is defined which permits these fields to be validated. Taking the SignerInfo structure from CMS, let's look at each of the fields 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 { version CMSVersion, sid SignerIdentifier, digestAlgorithm DigestAlgorithmIdentifier, signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, signatureAlgorithm SignatureAlgorithmIdentifier, signature SignatureValue, unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

is not protected by the signature. Many implementations of CMS today actually ignore the value of this field. If the structure decodes then this is considered sufficient to continue processing. Using most decoders on the market the value of this field does not control how the decoding is actually processed. can be protected by the use of either version of the signing certificate authenticated attribute. SigningCertificateV2 is defined in . SigningCertificate is defined in . In addition to allowing for the protection of the signer identifier, the specific certificate is protected by including a hash of the certificate to be used for validation. the digest algorithm used has been implicitly protected by the fact that CMS has only defined one digest algorithm for each hash value length. (The algorithm RIPEM-160 was never standardized). If newer digest algorithms are defined where there are multiple algorithms for a given hash length, or where parameters are defined for a specific algorithm, this implicit protection will no longer exist. are directly protected by the signature when they are present. The DER encoding of this value is what is actually hashed for the signature computation. has been protected by implication in the past. 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 be checked by the internal padding defined. This is no longer 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 was the only possible hash algorithm and the DSA was the public signature algorithm. This is longer true with the addition of the SHA2 signature algorithms. is not directly protected by any other value unless a counter signature is present. However this represents the cryptographically computed value that protects the rest of the signature information. is not protected by the signature value. It is also explicitly designed not to be protected by the signature value. As can be seen above, the digestAlgorithm and signatureAlgorithm fields have been indirectly rather than explicitly protected in the past. With new algorithms that have been or are being defined this will no longer be the case. This document defines and describes a new attribute that will explicitly protect these fields along with the macAlgorithm field of the AuthenticatedData structure.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

The following defines the algorithm protection attribute: The algorithm-protection attribute has the ASN.1 type CMSAlgorithmProtection:

aa-cmsAlgorithmProtection ATTRIBUTE ::= { TYPE CMSAlgorithmProtection IDENTIFIED BY { id-aa-CMSAlgorithmProtection } }

The following object identifier identifies the algorithm-protection attribute:

id-aa-CMSAlgorithmProtection OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 52 }

The algorithm-protection attribute uses the following ASN.1 type:

CMSAlgorithmProtection ::= SEQUENCE { digestAlgorithm DigestAlgorithmIdentifier, signatureAlgorithm [1] SignatureAlgorithmIdentifier OPTIONAL, macAlgorithm [2] MessageAuthenticationCodeAlgorithm OPTIONAL } (WITH COMPONENTS { signatureAlgorithm PRESENT, macAlgorithm ABSENT } | WITH COMPONENTS { signatureAlgorithm ABSENT, macAlgorithm PRESENT })

The fields are defined as follows: contains a copy of the SignerInfo.digestAlgorithm field or the AuthenticatedData.digestAlgorithm field including any parameters associated with it. contains a copy of the signature algorithm identifier and any parameters associated with it. This field is only populated if the attribute is placed in a SignerInfo.signedAttrs sequence. contains a copy of the message authentication code algorithm identifier and any parameters associated with it. This field is only populated if the attribute is placed in an AuthenticatedData.authAttrs sequence. Exactly one of signatureAlgorithm and macAlgorithm SHALL be present. An algorithm-protection attribute MUST have a single attribute value, even though the syntax is defined as a SET OF AttributeValue. There MUST NOT be zero or multiple instances of AttributeValue present. The algorithm-protection attribute MUST be a signed attribute or an authenticated attribute; it MUST NOT be an unsigned attribute, an unauthenticated attribute or an unprotected attribute. The SignedAttributes and AuthAttributes syntax are each defined as a SET of Attributes. The SignedAttributes in a signerInfo MUST include only one instance of the algorithm protection attribute. Similarly, the AuthAttributes in an AuthenticatedData MUST include only one instance of the algorithm protection attribute.

The exact verification process depends on the structure being dealt with. When doing comparisons of the fields, a field whose value is a default value and one which is explicitly provided MUST compare as equivalent. It is not required that a field which is absent in one case and present in another case be compared as equivalent. (This means that an algorithm identifier with absent parameters and one with NULL parameters are not expected to compare as equivalent.)

If a CMS validator supports this attribute, the following additional verification steps MUST be performed: 1. The SignerInfo.digestAlgorithm field MUST be compared to the digestAlgorithm field in the attribute. If the fields are not the same (modulo encoding) then signature validation MUST fail. 2. The SignerInfo.signatureAlgorithm field MUST be compared to the signatureAlgorithm field in the attribute. If the fields are not the same (modulo encoding) then the signature validation MUST fail.

If a CMS validator supports this attribute, the following additional verification steps MUST be performed: 1. The AuthenticatedData.digestAlgorithm field MUST be compared to the digestAlgorithm field in the attribute. If the fields are not same (modulo encoding) then signature validation MUST fail. 2. The AuthenticatedData.macAlgorithm field MUST be compared to the macAlgorithm field in the attribute. If the fields are not the same (modulo encoding) then the signature validation MUST fail.

This document is designed to address the security issue of algorithm substitutions of the algorithms used by the validator. At this time there is no known method to exploit this type of attack. If the attack could be successful, then either a weaker algorithm could be substituted for a stronger algorithm or the parameters could be modified by an attacker to change the behavior of the hashing algorithm used. (One example would be changing the initial parameter value for .) The attribute defined in this document is to be placed in a location that is protected by the signature or message authentication code. This attribute does not provide any additional security if placed in an un-signed or un-authenticated location.

Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Note that the force of these words is modified by the requirement level of the document in which they are used. Internet Mail Consortium

127 Segre Place Santa Cruz CA 95060 US phoffman@imc.org

In the original Enhanced Security Services for S/MIME document (RFC 2634), a structure for cryptographically linking the certificate to be used in validation with the signature was introduced; this structure was hardwired to use SHA-1. This document allows for the structure to have algorithm agility and defines a new attribute for this purpose. [STANDARDS TRACK] This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS TRACK] The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes. New hash algorithms are being developed and these algorithms may include parameters. CMS has not currently defined any hash algorithms with parameters, but anecdotic evidence suggests that defining one could cause major problems. In this document we define just such an algorithm and describe how to use it so that we can run experiments to find out how bad including hash parameters will be.

CMSAlgorithmProtectionAttribute { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-algorithmProtect(52) } DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS -- Cryptographic Message Syntax (CMS) [RFC5652] DigestAlgorithmIdentifier, MessageAuthenticationCodeAlgorithm, SignatureAlgorithmIdentifier FROM CryptographicMessageSyntax-2009 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41) } -- Common PKIX structures [RFC5912] ATTRIBUTE FROM PKIX-CommonTypes-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)}; -- -- The CMS Algorithm Protection attribute is a Signed Attribute or -- an Authenticated Attribute. -- -- Add this attribute to SignedAttributesSet in [RFC5652] -- Add this attribute to AuthAttriuteSet in [RFC5652] -- aa-cmsAlgorithmProtection ATTRIBUTE ::= { TYPE CMSAlgorithmProtection IDENTIFIED BY { id-aa-cmsAlgorithmProtect } } id-aa-cmsAlgorithmProtect OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 52 } CMSAlgorithmProtection ::= SEQUENCE { digestAlgorithm DigestAlgorithmIdentifier, signatureAlgorithm [1] SignatureAlgorithmIdentifier OPTIONAL, macAlgorithm [2] MessageAuthenticationCodeAlgorithm OPTIONAL } (WITH COMPONENTS { signatureAlgorithm PRESENT, macAlgorithm ABSENT } | WITH COMPONENTS { signatureAlgorithm ABSENT, macAlgorithm PRESENT }) END