idnits 2.17.00 (12 Aug 2021) /tmp/idnits57829/draft-schaad-smime-algorithm-attribute-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 118 has weird spacing: '...version is no...' == Line 124 has weird spacing: '... sid can be...' == Line 131 has weird spacing: '...gorithm the d...' == Line 139 has weird spacing: '...ributes are d...' == Line 143 has weird spacing: '...gorithm has b...' == (5 more instances...) -- The document date (January 6, 2011) is 4152 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 113 -- Looks like a reference, but probably isn't: '1' on line 374 -- Looks like a reference, but probably isn't: '2' on line 375 ** Downref: Normative reference to an Informational RFC: RFC 5912 == Outdated reference: draft-schaad-smime-hash-experiment has been published as RFC 6210 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Schaad 3 Internet-Draft Soaring Hawk Consulting 4 Intended status: Standards Track January 6, 2011 5 Expires: July 10, 2011 7 Signer Info Algorithm Protection Attribute 8 draft-schaad-smime-algorithm-attribute-04 10 Abstract 12 A new attribute is defined that allows for protection of the digest 13 and signature algorithm structures in an authenticated data or a 14 signer info structure. Using the attribute includes the algorithm 15 definition information in the integrity protection process. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on July 10, 2011. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 2. Attribute Structure . . . . . . . . . . . . . . . . . . . . . 6 54 3. Verification Process . . . . . . . . . . . . . . . . . . . . . 8 55 3.1. Signed Data Verification Changes . . . . . . . . . . . . . 8 56 3.2. Authenticated Data Verification Changes . . . . . . . . . 8 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 59 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 60 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 61 6.2. Informational References . . . . . . . . . . . . . . . . . 11 62 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 12 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 65 1. Introduction 67 Over past 20 years since the original definition of CMS as PKCS #7 in 68 1991, the number of signature and digest algorithms has grown from a 69 small number to a fairly substantial number and the trend is expected 70 to accelerate in the future. This has led to a new possible attack 71 that was not addressed at the time, the algorithm substitution 72 attack. In the algorithm substitution attack, the attacker looks for 73 collisions not only within the same algorithm as the creator of the 74 message used, but in all algorithms that have similar 75 characteristics. Thus if the creator of the message used SHA-1 as 76 the digest algorithm to hash the content, an attacker could look for 77 collisions in SHA-1, SHA-0 or RIPEMD-160 if those algorithms were in 78 use at the time the message was created. Once a collision had been 79 found, the attacker would change both the message content and the 80 digest identifier in the message. 82 If one looks at parameterized algorithms, then attacker could also 83 potentially attack the set of parameters that are chosen by the 84 message creator. We currently have RSASSA-PSS as a parameterized 85 signature algorithm and a number different hash algorithms have been 86 proposed (such as randomized hashing in [RANDOM-HASH]). Part of the 87 security proof for these algorithms assumes that the attacker does 88 not have the ability to select the parameters, although in the case 89 of a choice of digest algorithms it may influence them. 91 Algorithm substitution attacks are of greater interest to situations 92 where messages are expected to be long-lived than for very short term 93 messages. It is much simpler to prove what the current set of 94 constraints of a system are in the present time than it is for a 95 great deal of time in the past. Thus this attribute is expected to 96 be of greater interest in the timestamping and archiving communities 97 than in the S/MIME community. 99 In the current definition of [CMS], there are fields that are not 100 protected for either signature or authentication validation. In this 101 document a new signed or authenticated attribute is defined which 102 permits these fields to be protected as part of the validation 103 process. 105 Using the SignerInfo structure from CMS, let's look at each of the 106 fields in that structure and discuss what is and is not protected by 107 the signature. The ASN.1 is included here for convenience. (The 108 analysis of AuthenticatedData is similar.) 109 SignerInfo ::= SEQUENCE { 110 version CMSVersion, 111 sid SignerIdentifier, 112 digestAlgorithm DigestAlgorithmIdentifier, 113 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 114 signatureAlgorithm SignatureAlgorithmIdentifier, 115 signature SignatureValue, 116 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 118 version is not protected by the signature. Many implementations of 119 CMS today just ignore the value of this field. If the structure 120 decodes then this is considered sufficient to continue processing. 121 Using most decoders on the market the value of this field does not 122 control how the decoding is processed. 124 sid can be protected by the use of either version of the signing 125 certificate authenticated attribute. SigningCertificateV2 is 126 defined in [RFC5035]. SigningCertificate is defined in 127 [ESS-BASE]. In addition to allowing for the protection of the 128 signer identifier, the specific certificate is protected by 129 including a hash of the certificate to be used for validation. 131 digestAlgorithm the digest algorithm used has been implicitly 132 protected by the fact that CMS has only defined one digest 133 algorithm for each hash value length. (The algorithm RIPEM-160 134 was never standardized). If newer digest algorithms are defined 135 where there are multiple algorithms for a given hash length, or 136 where parameters are defined for a specific algorithm, this 137 implicit protection will no longer exist. 139 signedAttributes are directly protected by the signature when they 140 are present. The DER encoding of this value is what is hashed for 141 the signature computation. 143 signatureAlgorithm has been protected by implication in the past. 144 The use of an RSA public key implied that the RSA v 1.5 signature 145 algorithm was being used. The hash algorithm and this fact could 146 be checked by the internal padding defined. This is no longer 147 true with the addition of the RSA-PSS signature algorithms. The 148 use of a DSA public key implied the SHA-1 hash algorithm as that 149 was the only possible hash algorithm and the DSA was the public 150 signature algorithm. This is longer true with the addition of the 151 SHA2 signature algorithms. 153 signature is not directly protected by any other value unless a 154 counter signature is present. However this represents the 155 cryptographically computed value that protects the rest of the 156 signature information. 158 unsignedAttrs is not protected by the signature value. It is also 159 explicitly designed not to be protected by the signature value. 161 As can be seen above, the digestAlgorithm and signatureAlgorithm 162 fields have been indirectly rather than explicitly protected in the 163 past. With new algorithms that have been or are being defined this 164 will no longer be the case. This document defines and describes a 165 new attribute that will explicitly protect these fields along with 166 the macAlgorithm field of the AuthenticatedData structure. 168 1.1. Notation 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in [RFC2119]. 174 2. Attribute Structure 176 The following defines the algorithm protection attribute: 178 The algorithm-protection attribute has the ASN.1 type 179 CMSAlgorithmProtection: 181 aa-cmsAlgorithmProtection ATTRIBUTE ::= { 182 TYPE CMSAlgorithmProtection 183 IDENTIFIED BY { id-aa-CMSAlgorithmProtection } 184 } 186 The following object identifier identifies the algorithm-protection 187 attribute: 189 id-aa-CMSAlgorithmProtection OBJECT IDENTIFIER ::= { iso(1) 190 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 52 } 192 The algorithm-protection attribute uses the following ASN.1 type: 194 CMSAlgorithmProtection ::= SEQUENCE { 195 digestAlgorithm DigestAlgorithmIdentifier, 196 signatureAlgorithm [1] SignatureAlgorithmIdentifier OPTIONAL, 197 macAlgorithm [2] MessageAuthenticationCodeAlgorithm 198 OPTIONAL 199 } 200 (WITH COMPONENTS { signatureAlgorithm PRESENT, 201 macAlgorithm ABSENT } | 202 WITH COMPONENTS { signatureAlgorithm ABSENT, 203 macAlgorithm PRESENT }) 205 The fields are defined as follows: 207 digestAlgorithm contains a copy of the SignerInfo.digestAlgorithm 208 field or the AuthenticatedData.digestAlgorithm field including any 209 parameters associated with it. 211 signatureAlgorithm contains a copy of the signature algorithm 212 identifier and any parameters associated with it 213 (SignerInfo.signatureAlgorithm). This field is only populated if 214 the attribute is placed in a SignerInfo.signedAttrs sequence. 216 macAlgorithm contains a copy of the message authentication code 217 algorithm identifier and any parameters associated with it 218 (AuthenticatedData.macAlgorithm). This field is only populated if 219 the attribute is placed in an AuthenticatedData.authAttrs 220 sequence. 222 Exactly one of signatureAlgorithm and macAlgorithm SHALL be present. 224 An algorithm-protection attribute MUST have a single attribute value, 225 even though the syntax is defined as a SET OF AttributeValue. There 226 MUST NOT be zero or multiple instances of AttributeValue present. 228 The algorithm-protection attribute MUST be a signed attribute or an 229 authenticated attribute; it MUST NOT be an unsigned attribute, an 230 unauthenticated attribute or an unprotected attribute. 232 The SignedAttributes and AuthAttributes syntax are each defined as a 233 SET of Attributes. The SignedAttributes in a signerInfo MUST include 234 only one instance of the algorithm protection attribute. Similarly, 235 the AuthAttributes in an AuthenticatedData MUST include only one 236 instance of the algorithm protection attribute. 238 3. Verification Process 240 The exact verification process depends on the structure being dealt 241 with. 243 When doing comparisons of the fields, a field whose value is a 244 default value and one which is explicitly provided MUST compare as 245 equivalent. It is not required that a field which is absent in one 246 case and present in another case be compared as equivalent. (This 247 means that an algorithm identifier with absent parameters and one 248 with NULL parameters are not expected to compare as equivalent.) 250 3.1. Signed Data Verification Changes 252 If a CMS validator supports this attribute, the following additional 253 verification steps MUST be performed: 255 1. The SignerInfo.digestAlgorithm field MUST be compared to the 256 digestAlgorithm field in the attribute. If the fields are not the 257 same (modulo encoding) then signature validation MUST fail. 259 2. The SignerInfo.signatureAlgorithm field MUST be compared to the 260 signatureAlgorithm field in the attribute. If the fields are not the 261 same (modulo encoding) then the signature validation MUST fail. 263 3.2. Authenticated Data Verification Changes 265 If a CMS validator supports this attribute, the following additional 266 verification steps MUST be performed: 268 1. The AuthenticatedData.digestAlgorithm field MUST be compared to 269 the digestAlgorithm field in the attribute. If the fields are not 270 same (modulo encoding) then authentication MUST fail. 272 2. The AuthenticatedData.macAlgorithm field MUST be compared to the 273 macAlgorithm field in the attribute. If the fields are not the same 274 (modulo encoding) then the authentication MUST fail. 276 4. IANA Considerations 278 There are no IANA considerations. All identifiers are assigned out 279 of the S/MIME OID arc. 281 5. Security Considerations 283 This document is designed to address the security issue of algorithm 284 substitutions of the algorithms used by the validator. At this time 285 there is no known method to exploit this type of attack. If the 286 attack could be successful, then either a weaker algorithm could be 287 substituted for a stronger algorithm or the parameters could be 288 modified by an attacker to change the behavior of the hashing 289 algorithm used. (One example would be changing the initial parameter 290 value for [XOR-HASH].) 292 The attribute defined in this document is to be placed in a location 293 that is protected by the signature or message authentication code. 294 This attribute does not provide any additional security if placed in 295 an un-signed or un-authenticated location. 297 6. References 299 6.1. Normative References 301 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 302 Requirement Levels", BCP 14, RFC 2119, March 1997. 304 [ESS-BASE] 305 Hoffman, P., "Enhanced Security Services for S/MIME", 306 RFC 2634, June 1999. 308 [RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update: 309 Adding CertID Algorithm Agility", RFC 5035, August 2007. 311 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", 312 RFC 5652, September 2009. 314 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 315 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 316 June 2010. 318 6.2. Informational References 320 [XOR-HASH] 321 Schaad, J., "Experiment: Hash functions with parameters in 322 CMS and S/MIME", draft-schaad-smime-hash-experiment-01 323 (work in progress), December 2009. 325 [RANDOM-HASH] 326 Halevi, S. and H. Krawczyk, "Randomized Hashing: Secure 327 Digital Signatures without Collision Resistance", IETF 74. 329 Appendix A. ASN.1 Module 331 CMSAlgorithmProtectionAttribute 332 { iso(1) member-body(2) us(840) rsadsi(113549) 333 pkcs(1) pkcs-9(9) smime(16) modules(0) 334 id-mod-cms-algorithmProtect(52) } 335 DEFINITIONS IMPLICIT TAGS ::= 336 BEGIN 337 IMPORTS 339 -- Cryptographic Message Syntax (CMS) [CMS] 341 DigestAlgorithmIdentifier, MessageAuthenticationCodeAlgorithm, 342 SignatureAlgorithmIdentifier 343 FROM CryptographicMessageSyntax-2009 344 { iso(1) member-body(2) us(840) rsadsi(113549) 345 pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41) } 347 -- Common PKIX structures [RFC5912] 349 ATTRIBUTE 350 FROM PKIX-CommonTypes-2009 351 { iso(1) identified-organization(3) dod(6) internet(1) 352 security(5) mechanisms(5) pkix(7) id-mod(0) 353 id-mod-pkixCommon-02(57)}; 355 -- 356 -- The CMS Algorithm Protection attribute is a Signed Attribute or 357 -- an Authenticated Attribute. 358 -- 359 -- Add this attribute to SignedAttributesSet in [CMS] 360 -- Add this attribute to AuthAttributeSet in [CMS] 361 -- 363 aa-cmsAlgorithmProtection ATTRIBUTE ::= { 364 TYPE CMSAlgorithmProtection 365 IDENTIFIED BY { id-aa-cmsAlgorithmProtect } 366 } 368 id-aa-cmsAlgorithmProtect OBJECT IDENTIFIER ::= { 369 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 370 pkcs9(9) 52 } 372 CMSAlgorithmProtection ::= SEQUENCE { 373 digestAlgorithm DigestAlgorithmIdentifier, 374 signatureAlgorithm [1] SignatureAlgorithmIdentifier OPTIONAL, 375 macAlgorithm [2] MessageAuthenticationCodeAlgorithm 376 OPTIONAL 378 } 379 (WITH COMPONENTS { signatureAlgorithm PRESENT, 380 macAlgorithm ABSENT } | 381 WITH COMPONENTS { signatureAlgorithm ABSENT, 382 macAlgorithm PRESENT }) 384 END 386 Author's Address 388 Jim Schaad 389 Soaring Hawk Consulting 390 PO Box 675 391 Gold Bar, WA 98251 393 Email: ietf@augustcellars.com