idnits 2.17.1 draft-ietf-smime-sigattr-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 338 lines 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 66: '...draft, the terms MUST, MUST NOT, SHOUL...' RFC 2119 keyword, line 207: '...mber IssuerAndSerialNumber OPTIONAL...' RFC 2119 keyword, line 234: '...e sequence of certificates MUST be the...' RFC 2119 keyword, line 236: '...this certificate SHOULD NOT include th...' RFC 2119 keyword, line 240: '...e, the signature MUST be considered in...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2, 1998) is 9430 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) -- Missing reference section? 'CMS' on line 186 looks like a reference -- Missing reference section? 'MUSTSHOULD' on line 68 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Jim Schaad 2 draft-ietf-smime-sigattr-01 Microsoft 3 July 2, 1998 4 Expires in six months 6 Signing Certificate Attribute Specification 8 Status of this memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference material 18 or to cite them other than as "work in progress." 20 To learn the current status of any Internet-Draft, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 Abstract 28 A set of attacks on SignedData objects have been identified relating 29 to the fact that the certificate to be used when verifying the 30 signature in a SignerInfo is not cryptographically bound into the 31 signature. This leads to a set of attacks where the certificate used 32 to verify the signature is altered leading to possible incorrect 33 results. This document describes these attacks and provides ways to 34 deal with some of the attacks. 36 This draft is being discussed on the "ietf-smime" mailing list. To 37 join the list, send a message to with the 38 single word "subscribe" in the body of the message. Also, there is a 39 Web site for the mailing list at . 41 1. Introduction 43 Concerns have been raised over the fact that the certificate which the 44 signer of a [CMS] SignedData object desired to be bound into the 45 verification process of the SignedData object is not cryptographically 46 bound into the signature itself. This draft addresses this issue by 47 creating a new attribute to be placed in the signedAttributes or 48 authenticated attributes section of a SignerInfo object. 50 This document presents a description of a set of possible attacks 51 dealing with the substitution of one certificate to verify the 52 signature for the desired certificate. A set of ways for preventing 53 or addressing these attacks is presented to deal with the simplest of 54 the attacks. 56 Attribute certificates can be used as part of a signature verification 57 process. As [CMS] currently stands there is no way to include the 58 list of attribute certificates to be used in the verification process. 59 The set of attribute certificates used in the signature verification 60 process needs to have the ability for the signer to restrict the set 61 of certificates. This information needs to be encoded in a manner 62 that is covered by the signature on the SignedData object. This 63 document allows for the set of attribute certificates to be listed as 64 part of the signing certificate attribute. 66 Throughout this draft, the terms MUST, MUST NOT, SHOULD, and SHOULD 67 NOT are used in capital letters. This conforms to the definitions in 68 [MUSTSHOULD]. [MUSTSHOULD] defines the use of these key words to help 69 make the intent of standards track documents as clear as possible. The 70 same key words are used in this document to help implementers achieve 71 interoperability. 73 2. Attack Descriptions 75 I have identified 3 different attacks that can be launched against a 76 possible signature verification process by changing the certificate(s) 77 used in the signature verification process. 79 Substitution Attack 81 The first attack deals with simple substitution of one certificate for 82 another certificate. In this attack, the issuer and serial number in 83 the SignerInfo is modified to refer to a new certificate. This new 84 certificate is used the signature verification process. 86 The first version of this attack is a simple denial of service attack 87 where an invalid certificate is substituted for the valid certificate. 88 This renders the message unverifiable, as the public key in the 89 certificate no longer matches the private key used to sign the message 91 The second version is a substitution of one valid certificate for the 92 original valid certificate where the public keys in the certificates 93 match. This allows the signature to be validated under potentially 94 different certificate constraints than the originator of the message 95 used 97 Reissue of Certificate 99 The second attack deals with a Certificate Authority re-issuing the 100 signing certificate (or potentially one of its certificates). This 101 attack may start becoming more frequent as Certificate Authorities re- 102 issue there own root certificates and change policies in the 103 certificate while doing so. This problem also occurs when cross 104 certificates (with potentially different restrictions) are used in the 105 process of verifying a signature. 107 Rogue Duplicate Certificate Authority 109 The third attack deals with a rogue entity setting up a certificate 110 authority that attempts to duplicate the structure of an existing 111 Certificate Authority. Specifically, the rogue entity issues a new 112 certificate with the same public keys as the signer used, but signed 113 by the rogue entity's private key. 115 3. Attack Responses 117 This document does not attempt to solve all of the above attacks, 118 however a brief description of responses to each of the attacks is 119 given in this section. 121 Substitution Attack 123 The denial of service attack cannot be prevented, once the certificate 124 identifier has been modified in transit no verification of the 125 signature is possible. There is no way to automatically identify the 126 attack either, it is indistinguishable from a message corruption. 128 The substitution of a valid certificate can be responded to in two 129 different manners. The first is to make a blanket statement that the 130 use of the same public key in two different certificates is bad 131 practice and should be avoided. In practice, there is no practical 132 way to prevent users from doing this and we need to assume that they 133 will. Section 4 provides a new attribute to be included in the 134 SignerInfo signed attributes. This binds the correct certificate 135 identifier into the signature. This will convert the attack from a 136 potentially successful one to a denial of service attack. 138 Reissue of Certificate 140 A Certificate Authority should never reissue a certificate with 141 different attributes. Certificate Authorities that do so are 142 following incorrect practices and cannot be relied on. Using the hash 143 of the certificate as the reference to the certificate prevents this 144 attach for end-entity certificates. 146 Preventing the attack based on reissuing of CA certificates would 147 require a substantial change the attribute presented in section 5. It 148 would require that a sequence of certificate identifiers be included 149 in the attribute. This presents problem under the circumstances where 150 the relying party is using a cross certificate as part of its 151 authentication process and this certificate does not appear on the 152 list of certificates. The problems outside of a closed PKI make the 153 addition of this information prone to error causing the rejection of 154 valid chains. 156 Rogue Duplicate Certificate Authority 158 The best method of preventing this attack is to avoid trusting the 159 rogue certificate authority. The use of the hash to identify 160 certificates prevents the use of end-entity certificates from the 161 rogue authority, however the only true way to prevent this attack is 162 to never trust the rough CA. 164 4. Attribute Certificates 166 Attribute certificates are required to do validation of signatures for 167 some applications. This requires that the application be able to find 168 the correct attribute certificates to perform the verification process 169 and there is currently no list of attribute certificates in a 170 SignerInfo object. The sender has the ability to include a set of 171 attribute certificates in a SignedData object. The receiver has the 172 ability to retrieve attribute certificates from a directory service. 173 There are some circumstances where the signer may wish to limit the 174 set of attribute certificates that may be used in verifying a 175 signature. It would be useful to be able to list the set of attribute 176 certificates the signer wants used in validating the signature. 178 Given that this attribute is dealing with the certificate used in 179 verifying the signature on a SignerInfo object, it makes sense that it 180 should also address the issue of limiting the set of attribute 181 certificates as well. 183 5. Certificate Identification 185 The best way to identify certificates is an often discussed issued. 186 [CMS] has imposed a restriction for SignedData objects that the issuer 187 DN must be present in all signing certificates. The issuer/serial 188 number pair is therefore sufficient to identify the correct signing 189 certificate. This information is already present, as part of the 190 SignerInfo object, and duplication of this information would be 191 unfortunate. A hash of the entire certificate serves the same 192 function (allowing the receiver to very the same certificate is being 193 used), is smaller and permits a detection of the simple substitution 194 attacks. 196 Attribute certificates do not have an issuer/serial number pair 197 represented anywhere in a SignerInfo object. When the certificate is 198 not included in the SignedData object, it becomes much more difficult 199 to get the correct set of certificates based only on a hash of the 200 certificate. For this reasons attribute certificates are identified 201 by the issuer/serial number pair. 203 This document defines a certificate identifier as: 205 CertID ::= SEQUENCE { 206 certHash Hash, 207 issuerAndSerialNumber IssuerAndSerialNumber OPTIONAL 208 } 210 Hash ::= OCTET STRING -- SHA1 hash of entire certificate 212 When creating a CertID, the certHash is computed over the entire DER 213 encoded certificate including the signature. The 214 issuerAndSerialNumber would normally be present unless the value can 215 be inferred from other information. 217 6. Signing Certificate Attribute 219 The signing certificate attribute is designed to prevent the simple 220 substitution and re-issue attacks and to allow for a restricted set of 221 attribute certificates to be used in verifying a signature. 223 The following object identifier identifies the encrypted-data content 224 type: 226 id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1) 227 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 228 smime(16) id-aa(2) } 230 The definition of SigningCertificate is 232 SigningCertificate ::= SEQUENCE OF CertID 234 The first certificate in the sequence of certificates MUST be the 235 certificate used to verify the signature. The encoding of the CertID 236 for this certificate SHOULD NOT include the issuerAndSerialNumber. 237 (The issuerAndSerialNumber is already present in the SignerInfo.) This 238 certificate is used during the signature verification process. If the 239 hash of the certificate does not match the certificate used to decode 240 the signature, the signature MUST be considered invalid. 242 If more than one certificate is present in the sequence of CertIDs, 243 the certificates after the first one limit the set of attribute 244 certificates that are used during signature validation. The 245 issuerAndSerialNumber SHOULD be present, unless the validator is 246 expected to have easy access to all certificates required. If only 247 the signing certificate is present (a single item in the sequence) 248 there are no restrictions on the set of attribute certificates used in 249 validating the signature. 251 If present, the SigningCertificate attribute MUST be an authenticated 252 attribute; it MUST NOT be an unauthenticated attribute. CMS defines 253 authenticatedAttributes as a SET OF AuthAttribute. A SignerInfo MUST 254 NOT include multiple instances of the SigningCertificate attribute. 255 CMS defines the ASN.1 syntax for the authenticated attributes to 256 include attrValues SET OF AttributeValue. A SigningCertificate 257 attribute MUST only include a single instance of AttributeValue. 258 There MUST NOT be zero or multiple instances of AttributeValue present 259 in the attrValues SET OF AttributeValue. 261 A. ASN.1 Module 263 SigningCertificate 264 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 265 smime(16) modules(0) sca(?) } 267 DEFINITIONS IMPLICIT TAGS ::= 268 BEGIN 270 EXPORTS 271 SigningCertificate 273 IMPORTS 274 -- Cryptographic Message Syntax 275 IssuerAndSerialNumber 276 FROM CryptographicMessageSyntax { iso(1) member-body(2) 277 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 278 modules(0) cms(1) }; 280 CertID ::= SEQUENCE { 281 certHash Hash, 282 issuerAndSerialNumber IssuerAndSerialNumber OPTIONAL 283 } 285 Hash ::= OCTET STRING -- SHA1 hash of entire certificate 287 SigningCertificate ::= SEQUENCE OF CertID 289 END 291 B. Open Issues 293 Should CertID be a CHOICE rather than a SEQUENCE? This makes the 294 encoded bytes smaller, but does mean that you can't have both the hash 295 and the issuer/serial number together. My personal feelings is that 296 the ability to have both outweighs the small overhead of the sequence. 298 C. Changes 300 On request from Russ, I have added the ability to refer to attribute 301 certificates from this attribute. 302 Allow for using hashes as well as issuer/serial number for referring 303 to certificates. 304 Added the ASN module to Appendix A 306 References 308 CMS "Cryptographic Message Syntax", Internet Draft ietf-draft- 309 smime-cms 311 MUSTSHOULD "Key words for use in RFCs to Indicate Requirement Levels", 312 RFC 2119 314 Security Considerations 316 To be supplied 317 Must keep a complete copy or equivalent of the certificate in the 318 trusted root database, issuer serial number is insufficient. 319 Private key material must be protected. 321 Author's Address 323 Jim Schaad 324 Microsoft 325 One Microsoft Way 326 Redmond, WA 98XXX 327 Jimsch@microsoft.com