idnits 2.17.00 (12 Aug 2021) /tmp/idnits58075/draft-schaad-smime-algorithm-attribute-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 86 has weird spacing: '...version is no...' == Line 92 has weird spacing: '... sid can be...' == Line 99 has weird spacing: '...gorithm the d...' == Line 107 has weird spacing: '...ributes are d...' == Line 111 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 81 -- Looks like a reference, but probably isn't: '1' on line 331 -- Looks like a reference, but probably isn't: '2' on line 332 == Missing Reference: 'RFC5652' is mentioned on line 317, but not defined ** Downref: Normative reference to an Informational RFC: RFC 5912 == Outdated reference: draft-schaad-smime-hash-experiment has been published as RFC 6210 Summary: 2 errors (**), 0 flaws (~~), 9 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-02 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. Security Considerations . . . . . . . . . . . . . . . . . . . 8 58 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 5.1. Normative References . . . . . . . . . . . . . . . . . . . 9 60 5.2. Informational References . . . . . . . . . . . . . . . . . 9 61 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 10 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 1. Introduction 66 In the current definition of [CMS], there are some fields that are 67 not protected in the process of doing either a signature validation 68 or an authentication validation. In this document a new signed or 69 authenticated attribute is defined which permits these fields to be 70 validated. 72 Taking the SignerInfo structure from CMS, let's look at each of the 73 fields and discuss what is and is not protected by the signature. 74 The ASN.1 is included here for convenience. (The analysis of 75 AuthenticatedData is similar.) 77 SignerInfo ::= SEQUENCE { 78 version CMSVersion, 79 sid SignerIdentifier, 80 digestAlgorithm DigestAlgorithmIdentifier, 81 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 82 signatureAlgorithm SignatureAlgorithmIdentifier, 83 signature SignatureValue, 84 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 86 version is not protected by the signature. Many implementations of 87 CMS today actually ignore the value of this field. If the 88 structure decodes then this is considered sufficient to continue 89 processing. Using most decoders on the market the value of this 90 field does not control how the decoding is actually processed. 92 sid can be protected by the use of either version of the signing 93 certificate authenticated attribute. SigningCertificateV2 is 94 defined in [RFC5035]. SigningCertificate is defined in [RFC2634]. 95 In addition to allowing for the protection of the signer 96 identifier, the specific certificate is protected by including a 97 hash of the certificate to be used for validation. 99 digestAlgorithm the digest algorithm used has been implicitly 100 protected by the fact that CMS has only defined one digest 101 algorithm for each hash value length. (The algorithm RIPEM-160 102 was never standardized). If newer digest algorithms are defined 103 where there are multiple algorithms for a given hash length, or 104 where parameters are defined for a specific algorithm, this 105 implicit protection will no longer exist. 107 signedAttributes are directly protected by the signature when they 108 are present. The DER encoding of this value is what is actually 109 hashed for the signature computation. 111 signatureAlgorithm has been protected by implication in the past. 112 The use of an RSA public key implied that the RSA v 1.5 signature 113 algorithm was being used. The hash algorithm and this fact could 114 be checked by the internal padding defined. This is no longer 115 true with the addition of the RSA-PSS signature algorithms. The 116 use of a DSA public key implied the SHA-1 hash algorithm as that 117 was the only possible hash algorithm and the DSA was the public 118 signature algorithm. This is longer true with the addition of the 119 SHA2 signature algorithms. 121 signature is not directly protected by any other value unless a 122 counter signature is present. However this represents the 123 cryptographically computed value that protects the rest of the 124 signature information. 126 unsignedAttrs is not protected by the signature value. It is also 127 explicitly designed not to be protected by the signature value. 129 As can be seen above, the digestAlgorithm and signatureAlgorithm 130 fields have been indirectly rather than explicitly protected in the 131 past. With new algorithms that have been or are being defined this 132 will no longer be the case. This document defines and describes a 133 new attribute that will explicitly protect these fields along with 134 the macAlgorithm field of the AuthenticatedData structure. 136 1.1. Notation 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 2. Attribute Structure 144 The following defines the algorithm protection attribute: 146 The algorithm-protection attribute has the ASN.1 type 147 CMSAlgorithmProtection: 149 aa-cmsAlgorithmProtection ATTRIBUTE ::= { 150 TYPE CMSAlgorithmProtection 151 IDENTIFIED BY { id-aa-CMSAlgorithmProtection } 152 } 154 The following object identifier identifies the algorithm-protection 155 attribute: 157 id-aa-CMSAlgorithmProtection OBJECT IDENTIFIER ::= { iso(1) 158 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 52 } 160 The algorithm-protection attribute uses the following ASN.1 type: 162 CMSAlgorithmProtection ::= SEQUENCE { 163 digestAlgorithm DigestAlgorithmIdentifier, 164 signatureAlgorithm [1] SignatureAlgorithmIdentifier OPTIONAL, 165 macAlgorithm [2] MessageAuthenticationCodeAlgorithm 166 OPTIONAL 167 } 168 (WITH COMPONENTS { signatureAlgorithm PRESENT, 169 macAlgorithm ABSENT } | 170 WITH COMPONENTS { signatureAlgorithm ABSENT, 171 macAlgorithm PRESENT }) 173 The fields are defined as follows: 175 digestAlgorithm contains a copy of the SignerInfo.digestAlgorithm 176 field or the AuthenticatedData.digestAlgorithm field including any 177 parameters associated with it. 179 signatureAlgorithm contains a copy of the signature algorithm 180 identifier and any parameters associated with it. This field is 181 only populated if the attribute is placed in a 182 SignerInfo.signedAttrs sequence. 184 macAlgorithm contains a copy of the message authentication code 185 algorithm identifier and any parameters associated with it. This 186 field is only populated if the attribute is placed in an 187 AuthenticatedData.authAttrs sequence. 189 Exactly one of signatureAlgorithm and macAlgorithm SHALL be present. 191 An algorithm-protection attribute MUST have a single attribute value, 192 even though the syntax is defined as a SET OF AttributeValue. There 193 MUST NOT be zero or multiple instances of AttributeValue present. 195 The algorithm-protection attribute MUST be a signed attribute or an 196 authenticated attribute; it MUST NOT be an unsigned attribute, an 197 unauthenticated attribute or an unprotected attribute. 199 The SignedAttributes and AuthAttributes syntax are each defined as a 200 SET of Attributes. The SignedAttributes in a signerInfo MUST include 201 only one instance of the algorithm protection attribute. Similarly, 202 the AuthAttributes in an AuthenticatedData MUST include only one 203 instance of the algorithm protection attribute. 205 3. Verification Process 207 The exact verification process depends on the structure being dealt 208 with. 210 When doing comparisons of the fields, a field whose value is a 211 default value and one which is explicitly provided MUST compare as 212 equivalent. It is not required that a field which is absent in one 213 case and present in another case be compared as equivalent. (This 214 means that an algorithm identifier with absent parameters and one 215 with NULL parameters are not expected to compare as equivalent.) 217 3.1. Signed Data Verification Changes 219 If a CMS validator supports this attribute, the following additional 220 verification steps MUST be performed: 222 1. The SignerInfo.digestAlgorithm field MUST be compared to the 223 digestAlgorithm field in the attribute. If the fields are not the 224 same (modulo encoding) then signature validation MUST fail. 226 2. The SignerInfo.signatureAlgorithm field MUST be compared to the 227 signatureAlgorithm field in the attribute. If the fields are not the 228 same (modulo encoding) then the signature validation MUST fail. 230 3.2. Authenticated Data Verification Changes 232 If a CMS validator supports this attribute, the following additional 233 verification steps MUST be performed: 235 1. The AuthenticatedData.digestAlgorithm field MUST be compared to 236 the digestAlgorithm field in the attribute. If the fields are not 237 same (modulo encoding) then signature validation MUST fail. 239 2. The AuthenticatedData.macAlgorithm field MUST be compared to the 240 macAlgorithm field in the attribute. If the fields are not the same 241 (modulo encoding) then the signature validation MUST fail. 243 4. Security Considerations 245 This document is designed to address the security issue of algorithm 246 substitutions of the algorithms used by the validator. At this time 247 there is no known method to exploit this type of attack. If the 248 attack could be successful, then either a weaker algorithm could be 249 substituted for a stronger algorithm or the parameters could be 250 modified by an attacker to change the behavior of the hashing 251 algorithm used. (One example would be changing the initial parameter 252 value for [I-D.schaad-smime-hash-experiment].) 254 The attribute defined in this document is to be placed in a location 255 that is protected by the signature or message authentication code. 256 This attribute does not provide any additional security if placed in 257 an un-signed or un-authenticated location. 259 5. References 261 5.1. Normative References 263 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 264 Requirement Levels", BCP 14, RFC 2119, March 1997. 266 [RFC2634] Hoffman, P., "Enhanced Security Services for S/MIME", 267 RFC 2634, June 1999. 269 [RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update: 270 Adding CertID Algorithm Agility", RFC 5035, August 2007. 272 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", 273 RFC 5652, September 2009. 275 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 276 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 277 June 2010. 279 5.2. Informational References 281 [I-D.schaad-smime-hash-experiment] 282 Schaad, J., "Experiment: Hash functions with parameters in 283 CMS and S/MIME", draft-schaad-smime-hash-experiment-01 284 (work in progress), December 2009. 286 Appendix A. ASN.1 Module 288 CMSAlgorithmProtectionAttribute 289 { iso(1) member-body(2) us(840) rsadsi(113549) 290 pkcs(1) pkcs-9(9) smime(16) modules(0) 291 id-mod-cms-algorithmProtect(52) } 292 DEFINITIONS IMPLICIT TAGS ::= 293 BEGIN 294 IMPORTS 296 -- Cryptographic Message Syntax (CMS) [RFC5652] 298 DigestAlgorithmIdentifier, MessageAuthenticationCodeAlgorithm, 299 SignatureAlgorithmIdentifier 300 FROM CryptographicMessageSyntax-2009 301 { iso(1) member-body(2) us(840) rsadsi(113549) 302 pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41) } 304 -- Common PKIX structures [RFC5912] 306 ATTRIBUTE 307 FROM PKIX-CommonTypes-2009 308 { iso(1) identified-organization(3) dod(6) internet(1) 309 security(5) mechanisms(5) pkix(7) id-mod(0) 310 id-mod-pkixCommon-02(57)}; 312 -- 313 -- The CMS Algorithm Protection attribute is a Signed Attribute or 314 -- an Authenticated Attribute. 315 -- 316 -- Add this attribute to SignedAttributesSet in [RFC5652] 317 -- Add this attribute to AuthAttriuteSet in [RFC5652] 318 -- 320 aa-cmsAlgorithmProtection ATTRIBUTE ::= { 321 TYPE CMSAlgorithmProtection 322 IDENTIFIED BY { id-aa-cmsAlgorithmProtect } 323 } 325 id-aa-cmsAlgorithmProtect OBJECT IDENTIFIER ::= { 326 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 327 pkcs9(9) 52 } 329 CMSAlgorithmProtection ::= SEQUENCE { 330 digestAlgorithm DigestAlgorithmIdentifier, 331 signatureAlgorithm [1] SignatureAlgorithmIdentifier OPTIONAL, 332 macAlgorithm [2] MessageAuthenticationCodeAlgorithm 333 OPTIONAL 335 } 336 (WITH COMPONENTS { signatureAlgorithm PRESENT, 337 macAlgorithm ABSENT } | 338 WITH COMPONENTS { signatureAlgorithm ABSENT, 339 macAlgorithm PRESENT }) 341 END 343 Author's Address 345 Jim Schaad 346 Soaring Hawk Consulting 347 PO Box 675 348 Gold Bar, WA 98251 350 Email: ietf@augustcellars.com