idnits 2.17.00 (12 Aug 2021) /tmp/idnits57400/draft-schaad-smime-algorithm-attribute-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 11 instances of too long lines in the document, the longest one being 13 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 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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 (May 5, 2009) is 4763 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 308 -- Looks like a reference, but probably isn't: '2' on line 309 == Missing Reference: 'RFC 3852' is mentioned on line 274, but not defined ** Obsolete undefined reference: RFC 3852 (Obsoleted by RFC 5652) == Missing Reference: 'RFC 5280' is mentioned on line 285, but not defined == Missing Reference: 'CMS' is mentioned on line 295, but not defined == Unused Reference: 'RFC5280' is defined on line 255, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) Summary: 5 errors (**), 0 flaws (~~), 13 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 May 5, 2009 5 Expires: November 6, 2009 7 Signer Info Algorithm Protection Attribute 8 draft-schaad-smime-algorithm-attribute-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on November 6, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 A new signed attribute is defined that allows for protection of the 47 algorithm structures in an authenticated data or a signer info 48 structure. By placing the information into a signed or authenticated 49 attribute its value is then covered by the validation process. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Attribute Structure . . . . . . . . . . . . . . . . . . . . . 5 56 3. Verification Process . . . . . . . . . . . . . . . . . . . . . 7 57 3.1. Signed Data Verification Changes . . . . . . . . . . . . . 7 58 3.2. Authenticated Data Verification Changes . . . . . . . . . 7 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 60 5. Normative References . . . . . . . . . . . . . . . . . . . . . 9 61 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 10 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 1. Introduction 66 In the current definition of [RFC3852] 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, lets look at each of the 73 fields for and discuss what is and is not protected by the signature. 74 The ASN.1 is included here for convience. (The analysis of 75 AuthenticedData 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 signing certificate 93 authenticated attribute. SigningCertificateV2 is defined in 94 [RFC5035]. SigningCertificate is defined in [RFC2634]. In 95 addition to allowing for the protection of the signer identifier, 96 the specific certificate is protected by including a hash of the 97 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 algorthms 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 For RSA v 1.5 signatures, the fact that the RSA algorithm was 113 known from the public key and the digest algorithm used is 114 included in the formatted value over which the RSA computation is 115 done. For DSA signature, the fact that a DSA public key was 116 sufficient to know that SHA-1 was the digest algorithm as it was 117 the only acceptable digest algorithm. With the advent of newer 118 signature algorithms, especially those such as RSA-PSS which have 119 parameters, this implicit protection of the signature algorithm is 120 no longer possible. 122 signature is not directly protected by any other value unless a 123 counter signature is present. However this represents the 124 crytographically computed value to protected 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 explicity 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 AlgorithmProtection: 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) member-body(2) 159 us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBA } 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 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 digestAlg contains a copy of the digest algorithm identifier and any 176 parameters associated with it. 178 signatureAlg contains a copy of the signature algorithm identifier 179 and any parameters associated with it. This field is only 180 populated if the attribute is placed in a SignerInfo structure. 182 authenticationAlg contains a copy of the message authentication code 183 and any parameters associated with it. This field is only 184 populated if the attribute is placed in an authenticated data 185 structure. 187 Exactly one of signatureAlgorithm and macAlgorithm SHALL be present. 189 An algorithm protection MUST have a single attribute value, even 190 though the syntax is defined as a SET OF AttributeValue. There MUST 191 not be zero or multiple instances of AttributeValue present. 193 The authentication protection attribute MUST be a signed attribute or 194 an authenticated attribute; it MUST NOT be an unsigned attribute, an 195 unauthenticated attribute or an unprotected attribute. 197 The SignedAttributes and AuthAttributes syntax are each defined as a 198 SET of Attributes. The SignedAttributes in a signerInfo MUST include 199 only one instance of the algorithm protection attribute. Similarly, 200 the AuthAttributes in an AuthenticatedData MUST include only one 201 instance of the algorithm protection attribute. 203 3. Verification Process 205 The exact verification process depends on the structure being dealt 206 with. 208 3.1. Signed Data Verification Changes 210 If a CMS validator supports this attribute, the following additional 211 verification steps MUST be performed: 213 1. The SignerInfo.digestAlgorithm field MUST be compared to the 214 digestAlgorithm field in the attribute. If the fields are not same 215 (modulo encoding) then signature validation MUST fail. 217 2. The SignerInfo.signatureAlgorithm field MUST be compared to the 218 signatureAlgorithm field in the attribute. If the fields are not the 219 same (modulo encoding) then the signature validation MUST fail. 221 3.2. Authenticated Data Verification Changes 223 If a CMS validator supports this attribute, the following additional 224 verification steps MUST be performed: 226 1. The AuthenticatedData.digestAlgorithm field MUST be compared to 227 the digestAlgorithm field in the attribute. If the fields are not 228 same (modulo encoding) then signature validation MUST fail. 230 2. The AuthenticatedData.macAlgorithm field MUST be compared to the 231 macAlgorithm field in the attribute. If the fields are not the same 232 (modulo encoding) then the signature validation MUST fail. 234 4. Security Considerations 236 This document is designed to address the security issue of algorithm 237 substitutions of the algorithms used by the validator. At this time 238 there is no known method to exploit this type of attack. If the 239 attack could be successful, then a weaker algorithm could be 240 substituted for a stronger algorithm. 242 The attributes defined in this document are to be placed in locations 243 that are protected by the signature. This attribute does not provide 244 any additional security if placed in an un-signed or un-authenticated 245 location. 247 5. Normative References 249 [RFC2634] Hoffman, P., "Enhanced Security Services for S/MIME", 250 RFC 2634, June 1999. 252 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 253 Requirement Levels", RFC 2119, BCP 14, March 1997. 255 [RFC5280] Cooper, D., Santesson, S., Farrel, S., Boeyen, S., 256 Housley, R., and W. Polk, "Internet X.509 Public Key 257 Infrastructure Certificate and Certificate Revocation List 258 (CRL) Profile", RFC 5280, May 2008. 260 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 261 RFC 3852, July 2004. 263 [RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update: 264 Adding CertID Algorithm Agility", RFC 5035, August 2007. 266 Appendix A. ASN.1 Module 268 CMSAlgorithmAttribute 269 { iso(1) member-body(2) us(840) rsadsi(113549) 270 pkcs(1) pkcs-9(9) smime(16) modules(0) TBD } 271 DEFINITIONS IMPLICIT TAGS ::= 272 BEGIN 273 IMPORTS 274 -- Cryptographic Message Syntax (CMS) [RFC 3852] 275 ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier 276 FROM CryptographicMessageSyntax2004 { iso(1) member-body(2) us(840) 277 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24)} 278 -- PKIX Certificate and CRL Profile, Section A.1 Explicity Tagged Module 279 -- 1988 Syntax [RFC 5280] 280 AlgorithmIdentifier, CertificateSerialNumber 281 FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) 282 security(5) mechanisms(5) pkix(7) id-mod(0) pkix1-explicit(18) } 284 -- PKIX Certificate and CRL Profile, Sec A.2 Implicitly Tagged Module, 285 -- 1988 Syntax [RFC 5280] 286 PolicyInformation, CertificateSerialNumber, GeneralNames 287 FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1) 288 security(5) mechanisms(5) pkix(7)id-mod(0) id-pkix1-implicit(19)}; 290 -- 291 -- The CMS Algorithm Protection attribute is a Signed Attribute or 292 -- an Authenticated Attribute. 293 -- 294 -- Add this attribute to SignedAttributesSet in [CMS] 295 -- Add this attribute to AuthAttriuteSet in [CMS] 296 -- 298 aa-CMSAlgorithmProtection ATTRIBUTE ::= { 299 TYPE CMSAlgorithmProtection 300 IDENTIFIED BY { id-aa-CMSAlgorithmProtection } 301 } 303 id-aa-CMSAlgorithmProtection OBJECT IDENTIFIER ::= { iso(1) member-body(2) 304 us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBA } 306 CMSAlgorithmProtection ::= SEQUENCE { 307 digestAlgorithm DigestAlgorithmIdentifier, 308 signatureAlgorithm [1] SignatureAlgorithmIdentifier OPTIONAL, 309 macAlgorithm [2] MessageAuthenticationCodeAlgorithm OPTIONAL 310 } 311 (WITH COMPONENTS { signatureAlgorithm PRESENT, 312 macAlgorithm ABSENT } | 313 WITH COMPONENTS { signatureAlgorithm ABSENT, 314 macAlgorithm PRESENT }) 316 Author's Address 318 Jim Schaad 319 Soaring Hawk Consulting 320 PO Box 675 321 Gold Bar, WA 98251 323 Email: jimsch@exmsft.com