<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<rfc ipr="trust200811" docName="draft-schaad-smime-algorithm-attribute-00.txt" category="std">
	<front>
		<title abbrev="Algorithm Attribute">Signer Info Algorithm Protection Attribute</title>
		<author initials="J." surname="Schaad" fullname="Jim Schaad">
			<organization>Soaring Hawk Consulting</organization>
			<address>
				<postal>
					<street>PO Box 675</street>
					<city>Gold Bar</city>
					<region>WA</region>
					<code>98251</code>
				</postal>
				<email>jimsch@exmsft.com</email>
			</address>
		</author>
		<date year="2009" month="May"/>
		<abstract>
			<t>A new signed attribute is defined that allows for protection of the algorithm structures in an authenticated data or a signer info structure.  By placing the information into a signed or authenticated attribute its value is then covered by the validation process.</t>
		</abstract>
	</front>
	<middle>
	  <section title="Introduction">
			<t>In the current definition of <xref target="RFC3852"/> 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.</t>
      <t>Taking the SignerInfo structure from CMS, lets look at each of the fields for and discuss what is and is not protected by the signature.  The ASN.1 is included here for convience.  (The analysis of AuthenticedData is similar.)</t>
<figure>
<artwork>
      SignerInfo ::= SEQUENCE {
        version CMSVersion,
        sid SignerIdentifier,
        digestAlgorithm DigestAlgorithmIdentifier,
        signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
        signatureAlgorithm SignatureAlgorithmIdentifier,
        signature SignatureValue,
        unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

</artwork>
</figure>
      <list style="hanging">
        <t hangText="version"> 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.</t>
        <t hangText="sid"> can be protected by the use of either signing certificate authenticated attribute.  SigningCertificateV2 is defined in <xref target="RFC5035"/>.  SigningCertificate is defined in <xref target="RFC2634"/>.  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.</t>
        <t hangText="digestAlgorithm"> 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 algorthms for a given hash length, or where parameters are defined for a specific algorithm, this implicit protection will no longer exist.</t>
        <t hangText="signedAttributes"> 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.</t>
        <t hangText="signatureAlgorithm"> has been protected by implication in the past.  For RSA v 1.5 signatures, the fact that the RSA algorithm was known from the public key and the digest algorithm used is included in the formatted value over which the RSA computation is done.  For DSA signature, the fact that a DSA public key was sufficient to know that SHA-1 was the digest algorithm as it was the only acceptable digest algorithm.  With the advent of newer signature algorithms, especially those such as RSA-PSS which have parameters, this implicit protection of the signature algorithm is no longer possible. </t>
        <t hangText="signature"> is not directly protected by any other value unless a counter signature is present.  However this represents the crytographically computed value to protected the rest of the signature information.</t>
        <t hangText="unsignedAttrs"> is not protected by the signature value.  It is also explicitly designed not to be protected by the signature value.</t>
      </list>

      <t>As can be seen above, the digestAlgorithm and signatureAlgorithm fields have been indirectly rather than explicity 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.</t>
      <section title="Notation">
	      <t>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<xref target="RFC2119"/>.</t>
      </section>
      </section>
		<section title="Attribute Structure">
      <t>The following defines the algorithm protection attribute:</t>
<t>The algorithm-protection attribute has the ASN.1 type AlgorithmProtection:</t>
      <figure>
        <artwork>
    aa-CMSAlgorithmProtection ATTRIBUTE ::= {
        TYPE CMSAlgorithmProtection
        IDENTIFIED BY { id-aa-CMSAlgorithmProtection }
    }
</artwork></figure>
      <t>The following object identifier identifies the algorithm-protection attribute:</t>
      <figure>
        <artwork>
    id-aa-CMSAlgorithmProtection OBJECT IDENTIFIER ::= { iso(1) member-body(2)
           us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBA }
</artwork>
      </figure>
<t>The algorithm-protection attribute uses the following ASN.1 type:</t>
<figure><artwork>

    CMSAlgorithmProtection ::= SEQUENCE {
        digestAlgorithm         DigestAlgorithmIdentifier,
        signatureAlgorithm  [1] SignatureAlgorithmIdentifier OPTIONAL,
        macAlgorithm        [2] MessageAuthenticationCodeAlgorithm OPTIONAL
    }
    (WITH COMPONENTS { signatureAlgorithm PRESENT,
                       macAlgorithm ABSENT } |
     WITH COMPONENTS { signatureAlgorithm ABSENT,
                       macAlgorithm PRESENT })
</artwork>
      </figure>
      <t> The fields are defined as follows:</t>
      <list style="hanging">
        <t hangText="digestAlg"> contains a copy of the digest algorithm identifier and any parameters associated with it.</t>
        <t hangText="signatureAlg"> 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 structure.</t>
        <t hangText="authenticationAlg"> contains a copy of the message authentication code and any parameters associated with it.  This field is only populated if the attribute is placed in an authenticated data structure.</t>
      </list>
      <t>Exactly one of signatureAlgorithm and macAlgorithm SHALL be present.</t>
      <t>An algorithm protection 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.</t>

      <t>The authentication 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.</t>

      <t>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.</t>
		</section>

		<section title="Verification Process">
      <t>The exact verification process depends on the structure being dealt with.</t>
      <section title="Signed Data Verification Changes">
<t>If a CMS validator supports this attribute, the following additional verification steps MUST be performed:</t>
<t>1.  The SignerInfo.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.</t>
<t>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.</t>
      </section>
      <section title="Authenticated Data Verification Changes">
<t>If a CMS validator supports this attribute, the following additional verification steps MUST be performed:</t>
<t>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.</t>
<t>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.</t>
      </section>
		</section>

		<section title="Security Considerations">
			<t>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 a weaker algorithm could be substituted for a stronger algorithm.</t>
			<t>The attributes defined in this document are to be placed in locations that are protected by the signature.  This attribute does not provide any additional security if placed in an un-signed or un-authenticated location.</t>
		</section>
	</middle>
	<back>
		<references title="Normative References">
			<reference anchor="RFC2634">
				<front>
					<title>Enhanced Security Services for S/MIME</title>
					<author initials="P." surname="Hoffman"/>
					<date month="June" year="1999"/>
				</front>
				<seriesInfo name="RFC" value="2634"/>
			</reference>

			<reference anchor="RFC2119">
				<front>
					<title>Key words for use in RFCs to Indicate Requirement Levels</title>
					<author initials="S." surname="Bradner"/>
					<date month="March" year="1997"/>
				</front>
				<seriesInfo name="RFC" value="2119"/>
				<seriesInfo name="BCP" value="14"/>
			</reference>

			<reference anchor="RFC5280">
				<front>
					<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
          <author initials="D." surname="Cooper"/>
          <author initials="S." surname="Santesson"/>
          <author initials="S." surname="Farrel"/>
          <author initials="S." surname="Boeyen"/>
					<author initials="R." surname="Housley"/>
					<author initials="W." surname="Polk"/>
					<date year="2008" month="May"/>
				</front>
				<seriesInfo name="RFC" value="5280"/>
			</reference>
			<reference anchor="RFC3852">
				<front>
					<title>Cryptographic Message Syntax (CMS)</title>
					<author initials="R." surname="Housley"/>
					<date month="July" year="2004"/>
				</front>
				<seriesInfo name="RFC" value="3852"/>
			</reference>
			<reference anchor="RFC5035">
				<front>
					<title>Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility</title>
					<author initials="J." surname="Schaad"/>
					<date month="August" year="2007"/>
				</front>
				<seriesInfo name="RFC" value="5035"/>
			</reference>
		</references>
		<appendix title="ASN.1 Module">
			<figure>
				<artwork>
CMSAlgorithmAttribute
      { iso(1) member-body(2) us(840) rsadsi(113549)
        pkcs(1) pkcs-9(9) smime(16) modules(0) TBD }
 DEFINITIONS IMPLICIT TAGS ::= 
 BEGIN
 IMPORTS
 -- Cryptographic Message Syntax (CMS) [RFC 3852]
     ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier
        FROM CryptographicMessageSyntax2004 { iso(1) member-body(2) us(840)
                 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24)}
 -- PKIX Certificate and CRL Profile, Section A.1 Explicity Tagged Module
 --  1988 Syntax             [RFC 5280]
     AlgorithmIdentifier, CertificateSerialNumber
        FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1)
                 security(5) mechanisms(5) pkix(7) id-mod(0) pkix1-explicit(18) }

 -- PKIX Certificate and CRL Profile, Sec A.2 Implicitly Tagged Module,
 --  1988 Syntax             [RFC 5280]
     PolicyInformation, CertificateSerialNumber, GeneralNames
           FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1)
                  security(5) mechanisms(5) pkix(7)id-mod(0) id-pkix1-implicit(19)};

    -- 
    --  The CMS Algorithm Protection attribute is a Signed Attribute or
    --  an Authenticated Attribute.
    --
    --  Add this attribute to SignedAttributesSet in [CMS]
    --  Add this attribute to AuthAttriuteSet in [CMS]
    --

    aa-CMSAlgorithmProtection ATTRIBUTE ::= {
        TYPE CMSAlgorithmProtection 
        IDENTIFIED BY { id-aa-CMSAlgorithmProtection }
    }

    id-aa-CMSAlgorithmProtection OBJECT IDENTIFIER ::= { iso(1) member-body(2)
           us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBA }

    CMSAlgorithmProtection ::= SEQUENCE {
        digestAlgorithm         DigestAlgorithmIdentifier,
        signatureAlgorithm  [1] SignatureAlgorithmIdentifier OPTIONAL,
        macAlgorithm        [2] MessageAuthenticationCodeAlgorithm OPTIONAL
    }
    (WITH COMPONENTS { signatureAlgorithm PRESENT,
                       macAlgorithm ABSENT } |
     WITH COMPONENTS { signatureAlgorithm ABSENT,
                       macAlgorithm PRESENT })
</artwork>
			</figure>
		</appendix>
	</back>
</rfc>
