idnits 2.17.00 (12 Aug 2021) /tmp/idnits56969/draft-schaad-smime-algorithm-attribute-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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.) ** There are 6 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 92 has weird spacing: '...version is no...' == Line 98 has weird spacing: '... sid can be...' == Line 105 has weird spacing: '...gorithm the d...' == Line 113 has weird spacing: '...ributes are d...' == Line 117 has weird spacing: '...gorithm has b...' == (5 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. -- The document date (December 17, 2009) is 4537 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 87 -- Looks like a reference, but probably isn't: '1' on line 336 -- Looks like a reference, but probably isn't: '2' on line 337 == Unused Reference: 'RFC5280' is defined on line 274, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) == Outdated reference: draft-ietf-pkix-new-asn1 has been published as RFC 5912 ** Downref: Normative reference to an Informational draft: draft-ietf-pkix-new-asn1 (ref. 'I-D.ietf-pkix-new-asn1') == Outdated reference: draft-schaad-smime-hash-experiment has been published as RFC 6210 Summary: 5 errors (**), 0 flaws (~~), 11 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 December 17, 2009 5 Expires: June 20, 2010 7 Signer Info Algorithm Protection Attribute 8 draft-schaad-smime-algorithm-attribute-01 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 defintion information in the integrity protection process. 17 Status of this Memo 19 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 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 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on June 20, 2010. 40 Copyright Notice 42 Copyright (c) 2009 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Attribute Structure . . . . . . . . . . . . . . . . . . . . . 5 60 3. Verification Process . . . . . . . . . . . . . . . . . . . . . 7 61 3.1. Signed Data Verification Changes . . . . . . . . . . . . . 7 62 3.2. Authenticated Data Verification Changes . . . . . . . . . 7 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 5.1. Normative References . . . . . . . . . . . . . . . . . . . 9 66 5.2. Informational References . . . . . . . . . . . . . . . . . 9 67 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 10 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 1. Introduction 72 In the current definition of [RFC3852] there are some fields that are 73 not protected in the process of doing either a signature validation 74 or an authentication validation. In this document a new signed or 75 authenticated attribute is defined which permits these fields to be 76 validated. 78 Taking the SignerInfo structure from CMS, lets look at each of the 79 fields for and discuss what is and is not protected by the signature. 80 The ASN.1 is included here for convience. (The analysis of 81 AuthenticedData is similar.) 83 SignerInfo ::= SEQUENCE { 84 version CMSVersion, 85 sid SignerIdentifier, 86 digestAlgorithm DigestAlgorithmIdentifier, 87 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 88 signatureAlgorithm SignatureAlgorithmIdentifier, 89 signature SignatureValue, 90 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 92 version is not protected by the signature. Many implementations of 93 CMS today actually ignore the value of this field. If the 94 structure decodes then this is considered sufficient to continue 95 processing. Using most decoders on the market the value of this 96 field does not control how the decoding is actually processed. 98 sid can be protected by the use of either signing certificate 99 authenticated attribute. SigningCertificateV2 is defined in 100 [RFC5035]. SigningCertificate is defined in [RFC2634]. In 101 addition to allowing for the protection of the signer identifier, 102 the specific certificate is protected by including a hash of the 103 certificate to be used for validation. 105 digestAlgorithm the digest algorithm used has been implicitly 106 protected by the fact that CMS has only defined one digest 107 algorithm for each hash value length. (The algorithm RIPEM-160 108 was never standardized). If newer digest algorithms are defined 109 where there are multiple algorthms for a given hash length, or 110 where parameters are defined for a specific algorithm, this 111 implicit protection will no longer exist. 113 signedAttributes are directly protected by the signature when they 114 are present. The DER encoding of this value is what is actually 115 hashed for the signature computation. 117 signatureAlgorithm has been protected by implication in the past. 118 For RSA v 1.5 signatures, the fact that the RSA algorithm was 119 known from the public key and the digest algorithm used is 120 included in the formatted value over which the RSA computation is 121 done. For DSA signature, the fact that a DSA public key was 122 sufficient to know that SHA-1 was the digest algorithm as it was 123 the only acceptable digest algorithm. With the advent of newer 124 signature algorithms, especially those such as RSA-PSS which have 125 parameters, this implicit protection of the signature algorithm is 126 no longer possible. 128 signature is not directly protected by any other value unless a 129 counter signature is present. However this represents the 130 crytographically computed value to protected the rest of the 131 signature information. 133 unsignedAttrs is not protected by the signature value. It is also 134 explicitly designed not to be protected by the signature value. 136 As can be seen above, the digestAlgorithm and signatureAlgorithm 137 fields have been indirectly rather than explicity protected in the 138 past. With new algorithms that have been or are being defined this 139 will no longer be the case. This document defines and describes a 140 new attribute that will explicitly protect these fields along with 141 the macAlgorithm field of the AuthenticatedData structure. 143 1.1. Notation 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 2. Attribute Structure 151 The following defines the algorithm protection attribute: 153 The algorithm-protection attribute has the ASN.1 type 154 AlgorithmProtection: 156 aa-CMSAlgorithmProtection ATTRIBUTE ::= { 157 TYPE CMSAlgorithmProtection 158 IDENTIFIED BY { id-aa-CMSAlgorithmProtection } 159 } 161 The following object identifier identifies the algorithm-protection 162 attribute: 164 id-aa-CMSAlgorithmProtection OBJECT IDENTIFIER ::= { iso(1) member-body(2) 165 us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBA } 167 The algorithm-protection attribute uses the following ASN.1 type: 169 CMSAlgorithmProtection ::= SEQUENCE { 170 digestAlgorithm DigestAlgorithmIdentifier, 171 signatureAlgorithm [1] SignatureAlgorithmIdentifier OPTIONAL, 172 macAlgorithm [2] MessageAuthenticationCodeAlgorithm OPTIONAL 173 } 174 (WITH COMPONENTS { signatureAlgorithm PRESENT, 175 macAlgorithm ABSENT } | 176 WITH COMPONENTS { signatureAlgorithm ABSENT, 177 macAlgorithm PRESENT }) 179 The fields are defined as follows: 181 digestAlg contains a copy of the SignerInfo.digestAlgorithm field or 182 the AuthenticatedData.digestAlgorithm field including any 183 parameters associated with it. 185 signatureAlg contains a copy of the signature algorithm identifier 186 and any parameters associated with it. This field is only 187 populated if the attribute is placed in a SignerInfo structure. 189 authenticationAlg contains a copy of the message authentication code 190 and any parameters associated with it. This field is only 191 populated if the attribute is placed in an authenticated data 192 structure. 194 Exactly one of signatureAlgorithm and macAlgorithm SHALL be present. 196 An algorithm protection MUST have a single attribute value, even 197 though the syntax is defined as a SET OF AttributeValue. There MUST 198 not be zero or multiple instances of AttributeValue present. 200 The authentication protection attribute MUST be a signed attribute or 201 an authenticated attribute; it MUST NOT be an unsigned attribute, an 202 unauthenticated attribute or an unprotected attribute. 204 The SignedAttributes and AuthAttributes syntax are each defined as a 205 SET of Attributes. The SignedAttributes in a signerInfo MUST include 206 only one instance of the algorithm protection attribute. Similarly, 207 the AuthAttributes in an AuthenticatedData MUST include only one 208 instance of the algorithm protection attribute. 210 3. Verification Process 212 The exact verification process depends on the structure being dealt 213 with. 215 When doing comparisions of the fields, a field whos value is a 216 default value and one which is explicitly provided MUST compare as 217 equivalent. It is not required that a field which is absent in one 218 case and present in another case be compared as equivelent. (This 219 mean that an algorithm identifier with absent parameters and one with 220 NULL parameters need not compare as equivalent.) 222 3.1. Signed Data Verification Changes 224 If a CMS validator supports this attribute, the following additional 225 verification steps MUST be performed: 227 1. The SignerInfo.digestAlgorithm field MUST be compared to the 228 digestAlgorithm field in the attribute. If the fields are not same 229 (modulo encoding) then signature validation MUST fail. 231 2. The SignerInfo.signatureAlgorithm field MUST be compared to the 232 signatureAlgorithm field in the attribute. If the fields are not the 233 same (modulo encoding) then the signature validation MUST fail. 235 3.2. Authenticated Data Verification Changes 237 If a CMS validator supports this attribute, the following additional 238 verification steps MUST be performed: 240 1. The AuthenticatedData.digestAlgorithm field MUST be compared to 241 the digestAlgorithm field in the attribute. If the fields are not 242 same (modulo encoding) then signature validation MUST fail. 244 2. The AuthenticatedData.macAlgorithm field MUST be compared to the 245 macAlgorithm field in the attribute. If the fields are not the same 246 (modulo encoding) then the signature validation MUST fail. 248 4. Security Considerations 250 This document is designed to address the security issue of algorithm 251 substitutions of the algorithms used by the validator. At this time 252 there is no known method to exploit this type of attack. If the 253 attack could be successful, then either a weaker algorithm could be 254 substituted for a stronger algorithm or the parameters can be 255 modified by an attacker to change the state of the hashing algorithm 256 used. (One example would be changing the initial parmeter value for 257 [I-D.schaad-smime-hash-experiment] 259 The attributes defined in this document are to be placed in locations 260 that are protected by the signature. This attribute does not provide 261 any additional security if placed in an un-signed or un-authenticated 262 location. 264 5. References 266 5.1. Normative References 268 [RFC2634] Hoffman, P., "Enhanced Security Services for S/MIME", 269 RFC 2634, June 1999. 271 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 272 Requirement Levels", RFC 2119, BCP 14, March 1997. 274 [RFC5280] Cooper, D., Santesson, S., Farrel, S., Boeyen, S., 275 Housley, R., and W. Polk, "Internet X.509 Public Key 276 Infrastructure Certificate and Certificate Revocation List 277 (CRL) Profile", RFC 5280, May 2008. 279 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 280 RFC 3852, July 2004. 282 [RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update: 283 Adding CertID Algorithm Agility", RFC 5035, August 2007. 285 [I-D.ietf-pkix-new-asn1] 286 Hoffman, P. and J. Schaad, "New ASN.1 Modules for PKIX", 287 draft-ietf-pkix-new-asn1-07 (work in progress), 288 August 2009. 290 5.2. Informational References 292 [I-D.schaad-smime-hash-experiment] 293 Schaad, J., "Experiment: Hash functions with parameters in 294 CMS and S/MIME", draft-schaad-smime-hash-experiment-00 295 (work in progress), May 2009. 297 Appendix A. ASN.1 Module 299 CMSAlgorithmAttribute 300 { iso(1) member-body(2) us(840) rsadsi(113549) 301 pkcs(1) pkcs-9(9) smime(16) modules(0) 989 } 302 DEFINITIONS IMPLICIT TAGS ::= 303 BEGIN 304 IMPORTS 305 -- Cryptographic Message Syntax (CMS) [RFC3852] 306 DigestAlgorithmIdentifier, MessageAuthenticationCodeAlgorithm, 307 SignatureAlgorithmIdentifier 308 FROM CryptographicMessageSyntax-2009 309 { iso(1) member-body(2) us(840) rsadsi(113549) 310 pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41) } 312 -- Common PKIX structures [I-D.ietf-pkix-new-asn1] 313 ATTRIBUTE 314 FROM PKIX-CommonTypes-2009 315 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 316 mechanisms(5) pkix(7) id-mod(0) 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 [RFC3852] 323 -- Add this attribute to AuthAttriuteSet in [RFC3852] 324 -- 326 aa-CMSAlgorithmProtection ATTRIBUTE ::= { 327 TYPE CMSAlgorithmProtection 328 IDENTIFIED BY { id-aa-CMSAlgorithmProtection } 329 } 331 id-aa-CMSAlgorithmProtection OBJECT IDENTIFIER ::= { iso(1) member-body(2) 332 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 989 } 334 CMSAlgorithmProtection ::= SEQUENCE { 335 digestAlgorithm DigestAlgorithmIdentifier, 336 signatureAlgorithm [1] SignatureAlgorithmIdentifier OPTIONAL, 337 macAlgorithm [2] MessageAuthenticationCodeAlgorithm OPTIONAL 338 } 339 (WITH COMPONENTS { signatureAlgorithm PRESENT, 340 macAlgorithm ABSENT } | 341 WITH COMPONENTS { signatureAlgorithm ABSENT, 342 macAlgorithm PRESENT }) 343 END 345 Author's Address 347 Jim Schaad 348 Soaring Hawk Consulting 349 PO Box 675 350 Gold Bar, WA 98251 352 Email: ietf@augustcellars.com