idnits 2.17.00 (12 Aug 2021) /tmp/idnits56442/draft-schaad-smime-algorithm-attribute-03.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 87 has weird spacing: '...version is no...' == Line 93 has weird spacing: '... sid can be...' == Line 100 has weird spacing: '...gorithm the d...' == Line 108 has weird spacing: '...ributes are d...' == Line 112 has weird spacing: '...gorithm has b...' == (5 more instances...) -- The document date (November 22, 2010) is 4197 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 82 -- Looks like a reference, but probably isn't: '1' on line 337 -- Looks like a reference, but probably isn't: '2' on line 338 ** 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 November 22, 2010 5 Expires: May 26, 2011 7 Signer Info Algorithm Protection Attribute 8 draft-schaad-smime-algorithm-attribute-03 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 May 26, 2011. 34 Copyright Notice 36 Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Attribute Structure . . . . . . . . . . . . . . . . . . . . . 5 54 3. Verification Process . . . . . . . . . . . . . . . . . . . . . 7 55 3.1. Signed Data Verification Changes . . . . . . . . . . . . . 7 56 3.2. Authenticated Data Verification Changes . . . . . . . . . 7 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 59 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 61 6.2. Informational References . . . . . . . . . . . . . . . . . 10 62 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 11 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 1. Introduction 67 In the current definition of [CMS], there are some fields that are 68 not protected in the process of doing either a signature validation 69 or an authentication validation. In this document a new signed or 70 authenticated attribute is defined which permits these fields to be 71 validated. 73 Taking the SignerInfo structure from CMS, let's look at each of the 74 fields and discuss what is and is not protected by the signature. 75 The ASN.1 is included here for convenience. (The analysis of 76 AuthenticatedData is similar.) 78 SignerInfo ::= SEQUENCE { 79 version CMSVersion, 80 sid SignerIdentifier, 81 digestAlgorithm DigestAlgorithmIdentifier, 82 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 83 signatureAlgorithm SignatureAlgorithmIdentifier, 84 signature SignatureValue, 85 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 87 version is not protected by the signature. Many implementations of 88 CMS today actually ignore the value of this field. If the 89 structure decodes then this is considered sufficient to continue 90 processing. Using most decoders on the market the value of this 91 field does not control how the decoding is actually processed. 93 sid can be protected by the use of either version of the signing 94 certificate authenticated attribute. SigningCertificateV2 is 95 defined in [RFC5035]. SigningCertificate is defined in [RFC2634]. 96 In addition to allowing for the protection of the signer 97 identifier, the specific certificate is protected by including a 98 hash of the certificate to be used for validation. 100 digestAlgorithm the digest algorithm used has been implicitly 101 protected by the fact that CMS has only defined one digest 102 algorithm for each hash value length. (The algorithm RIPEM-160 103 was never standardized). If newer digest algorithms are defined 104 where there are multiple algorithms for a given hash length, or 105 where parameters are defined for a specific algorithm, this 106 implicit protection will no longer exist. 108 signedAttributes are directly protected by the signature when they 109 are present. The DER encoding of this value is what is actually 110 hashed for the signature computation. 112 signatureAlgorithm has been protected by implication in the past. 113 The use of an RSA public key implied that the RSA v 1.5 signature 114 algorithm was being used. The hash algorithm and this fact could 115 be checked by the internal padding defined. This is no longer 116 true with the addition of the RSA-PSS signature algorithms. The 117 use of a DSA public key implied the SHA-1 hash algorithm as that 118 was the only possible hash algorithm and the DSA was the public 119 signature algorithm. This is longer true with the addition of the 120 SHA2 signature algorithms. 122 signature is not directly protected by any other value unless a 123 counter signature is present. However this represents the 124 cryptographically computed value that protects the rest of the 125 signature information. 127 unsignedAttrs is not protected by the signature value. It is also 128 explicitly designed not to be protected by the signature value. 130 As can be seen above, the digestAlgorithm and signatureAlgorithm 131 fields have been indirectly rather than explicitly protected in the 132 past. With new algorithms that have been or are being defined this 133 will no longer be the case. This document defines and describes a 134 new attribute that will explicitly protect these fields along with 135 the macAlgorithm field of the AuthenticatedData structure. 137 1.1. Notation 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 2. Attribute Structure 145 The following defines the algorithm protection attribute: 147 The algorithm-protection attribute has the ASN.1 type 148 CMSAlgorithmProtection: 150 aa-cmsAlgorithmProtection ATTRIBUTE ::= { 151 TYPE CMSAlgorithmProtection 152 IDENTIFIED BY { id-aa-CMSAlgorithmProtection } 153 } 155 The following object identifier identifies the algorithm-protection 156 attribute: 158 id-aa-CMSAlgorithmProtection OBJECT IDENTIFIER ::= { iso(1) 159 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 52 } 161 The algorithm-protection attribute uses the following ASN.1 type: 163 CMSAlgorithmProtection ::= SEQUENCE { 164 digestAlgorithm DigestAlgorithmIdentifier, 165 signatureAlgorithm [1] SignatureAlgorithmIdentifier OPTIONAL, 166 macAlgorithm [2] MessageAuthenticationCodeAlgorithm 167 OPTIONAL 168 } 169 (WITH COMPONENTS { signatureAlgorithm PRESENT, 170 macAlgorithm ABSENT } | 171 WITH COMPONENTS { signatureAlgorithm ABSENT, 172 macAlgorithm PRESENT }) 174 The fields are defined as follows: 176 digestAlgorithm contains a copy of the SignerInfo.digestAlgorithm 177 field or the AuthenticatedData.digestAlgorithm field including any 178 parameters associated with it. 180 signatureAlgorithm contains a copy of the signature algorithm 181 identifier and any parameters associated with it. This field is 182 only populated if the attribute is placed in a 183 SignerInfo.signedAttrs sequence. 185 macAlgorithm contains a copy of the message authentication code 186 algorithm identifier and any parameters associated with it. This 187 field is only populated if the attribute is placed in an 188 AuthenticatedData.authAttrs sequence. 190 Exactly one of signatureAlgorithm and macAlgorithm SHALL be present. 192 An algorithm-protection attribute MUST have a single attribute value, 193 even though the syntax is defined as a SET OF AttributeValue. There 194 MUST NOT be zero or multiple instances of AttributeValue present. 196 The algorithm-protection attribute MUST be a signed attribute or an 197 authenticated attribute; it MUST NOT be an unsigned attribute, an 198 unauthenticated attribute or an unprotected attribute. 200 The SignedAttributes and AuthAttributes syntax are each defined as a 201 SET of Attributes. The SignedAttributes in a signerInfo MUST include 202 only one instance of the algorithm protection attribute. Similarly, 203 the AuthAttributes in an AuthenticatedData MUST include only one 204 instance of the algorithm protection attribute. 206 3. Verification Process 208 The exact verification process depends on the structure being dealt 209 with. 211 When doing comparisons of the fields, a field whose value is a 212 default value and one which is explicitly provided MUST compare as 213 equivalent. It is not required that a field which is absent in one 214 case and present in another case be compared as equivalent. (This 215 means that an algorithm identifier with absent parameters and one 216 with NULL parameters are not expected to compare as equivalent.) 218 3.1. Signed Data Verification Changes 220 If a CMS validator supports this attribute, the following additional 221 verification steps MUST be performed: 223 1. The SignerInfo.digestAlgorithm field MUST be compared to the 224 digestAlgorithm field in the attribute. If the fields are not the 225 same (modulo encoding) then signature validation MUST fail. 227 2. The SignerInfo.signatureAlgorithm field MUST be compared to the 228 signatureAlgorithm field in the attribute. If the fields are not the 229 same (modulo encoding) then the signature validation MUST fail. 231 3.2. Authenticated Data Verification Changes 233 If a CMS validator supports this attribute, the following additional 234 verification steps MUST be performed: 236 1. The AuthenticatedData.digestAlgorithm field MUST be compared to 237 the digestAlgorithm field in the attribute. If the fields are not 238 same (modulo encoding) then signature validation MUST fail. 240 2. The AuthenticatedData.macAlgorithm field MUST be compared to the 241 macAlgorithm field in the attribute. If the fields are not the same 242 (modulo encoding) then the signature validation MUST fail. 244 4. IANA Considerations 246 There are no IANA considerations. All identifiers are assigned out 247 of the S/MIME OID arc. 249 5. Security Considerations 251 This document is designed to address the security issue of algorithm 252 substitutions of the algorithms used by the validator. At this time 253 there is no known method to exploit this type of attack. If the 254 attack could be successful, then either a weaker algorithm could be 255 substituted for a stronger algorithm or the parameters could be 256 modified by an attacker to change the behavior of the hashing 257 algorithm used. (One example would be changing the initial parameter 258 value for [I-D.schaad-smime-hash-experiment].) 260 The attribute defined in this document is to be placed in a location 261 that is protected by the signature or message authentication code. 262 This attribute does not provide any additional security if placed in 263 an un-signed or un-authenticated location. 265 6. References 267 6.1. Normative References 269 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 270 Requirement Levels", BCP 14, RFC 2119, March 1997. 272 [RFC2634] Hoffman, P., "Enhanced Security Services for S/MIME", 273 RFC 2634, June 1999. 275 [RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update: 276 Adding CertID Algorithm Agility", RFC 5035, August 2007. 278 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", 279 RFC 5652, September 2009. 281 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 282 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 283 June 2010. 285 6.2. Informational References 287 [I-D.schaad-smime-hash-experiment] 288 Schaad, J., "Experiment: Hash functions with parameters in 289 CMS and S/MIME", draft-schaad-smime-hash-experiment-01 290 (work in progress), December 2009. 292 Appendix A. ASN.1 Module 294 CMSAlgorithmProtectionAttribute 295 { iso(1) member-body(2) us(840) rsadsi(113549) 296 pkcs(1) pkcs-9(9) smime(16) modules(0) 297 id-mod-cms-algorithmProtect(52) } 298 DEFINITIONS IMPLICIT TAGS ::= 299 BEGIN 300 IMPORTS 302 -- Cryptographic Message Syntax (CMS) [CMS] 304 DigestAlgorithmIdentifier, MessageAuthenticationCodeAlgorithm, 305 SignatureAlgorithmIdentifier 306 FROM CryptographicMessageSyntax-2009 307 { iso(1) member-body(2) us(840) rsadsi(113549) 308 pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41) } 310 -- Common PKIX structures [RFC5912] 312 ATTRIBUTE 313 FROM PKIX-CommonTypes-2009 314 { iso(1) identified-organization(3) dod(6) internet(1) 315 security(5) mechanisms(5) pkix(7) id-mod(0) 316 id-mod-pkixCommon-02(57)}; 318 -- 319 -- The CMS Algorithm Protection attribute is a Signed Attribute or 320 -- an Authenticated Attribute. 321 -- 322 -- Add this attribute to SignedAttributesSet in [CMS] 323 -- Add this attribute to AuthAttributeSet in [CMS] 324 -- 326 aa-cmsAlgorithmProtection ATTRIBUTE ::= { 327 TYPE CMSAlgorithmProtection 328 IDENTIFIED BY { id-aa-cmsAlgorithmProtect } 329 } 331 id-aa-cmsAlgorithmProtect OBJECT IDENTIFIER ::= { 332 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 333 pkcs9(9) 52 } 335 CMSAlgorithmProtection ::= SEQUENCE { 336 digestAlgorithm DigestAlgorithmIdentifier, 337 signatureAlgorithm [1] SignatureAlgorithmIdentifier OPTIONAL, 338 macAlgorithm [2] MessageAuthenticationCodeAlgorithm 339 OPTIONAL 341 } 342 (WITH COMPONENTS { signatureAlgorithm PRESENT, 343 macAlgorithm ABSENT } | 344 WITH COMPONENTS { signatureAlgorithm ABSENT, 345 macAlgorithm PRESENT }) 347 END 349 Author's Address 351 Jim Schaad 352 Soaring Hawk Consulting 353 PO Box 675 354 Gold Bar, WA 98251 356 Email: ietf@augustcellars.com