idnits 2.17.1 draft-ietf-smime-sigattr-00.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-25) 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 293 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 117 instances of lines with control characters in the document. ** 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 63: '...draft, the terms MUST, MUST NOT, SHOUL...' RFC 2119 keyword, line 64: '... and SHOULD NOT are used in capital le...' 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 (May 9, 1998) is 9483 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 49 looks like a reference -- Missing reference section? 'MUSTSHOULD' on line 65 looks like a reference Summary: 11 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-00.txt Microsoft 3 May 9, 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 11 working documents of the Internet Engineering Task Force 12 (IETF), its areas, and its working groups. Note that other 13 groups may also distribute working documents as Internet- 14 Drafts. 16 Internet-Drafts are draft documents valid for a maximum of 17 six months and may be updated, replaced, or obsoleted by 18 other documents at any time. It is inappropriate to use 19 Internet-Drafts as reference material or to cite them 20 other than as "work in progress." 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 26 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 27 (US West Coast). 29 Abstract 31 A set of attacks on SignedData objects have been 32 identified relating to the fact that the certificate to be 33 used when verifying the signature in a SignerInfo is not 34 cryptographically bound into the signature. This leads to 35 a set of attacks where the certificate used to verify the 36 signature is altered leading to possible incorrect 37 results. This document describes these attacks and 38 provides ways to deal with some of the attacks. 40 This draft is being discussed on the 'ietf-smime' mailing 41 list. To join the list, send a message to > with the single word 43 'subscribe' in the body of the message. Also, there is a Web site 44 for the mailing list at . 46 1. Introduction 48 Concerns have been raised over the fact that the 49 certificate which the signer of a [CMS] SignedData object 50 desired to be bound into the verification process of the 51 SignedData object is not cryptographically bound into the 52 signature itself. This draft attempts to address this 53 issue by creating a new attribute to be placed in the 54 signedAttributes or authenticated attributes section of a 55 SignerInfo object. 57 This document presents a description of a set of possible 58 attacks dealing with the substitution of one certificate 59 to verify the signature for the desired certificate. A 60 set of ways for preventing or addressing these attacks is 61 presented to deal with the simplest of the attacks. 63 Throughout this draft, the terms MUST, MUST NOT, SHOULD, 64 and SHOULD NOT are used in capital letters. This conforms 65 to the definitions in [MUSTSHOULD]. [MUSTSHOULD] defines 66 the use of these key words to help make the intent of 67 standards track documents as clear as possible. The same 68 key words are used in this document to help implementers 69 achieve interoperability. 71 2. Attack Descriptions 73 I have identified 3 different attacks that can be launched 74 against a possible signature verification process by 75 changing the certificate(s) used in the signature 76 verification process. 78 Substitution Attack 80 The first attack deals with simple substitution of one 81 certificate for another certificate. In this attack the 82 issuer and serial number in the SignerInfo is modified to 83 refer to a new certificate. This new certificate is used 84 the signature verification process. 86 The first version of this attack is a simple denial of 87 service attack where an invalid certificate is substituted 88 for the valid certificate. This renders the message 89 unverifiable, as the public key in the certificate no 90 longer matches the private key used to sign the message 92 The second version is a substitution of one valid 93 certificate for the original valid certificate where the 94 public keys in the certificates match. This allows for 95 the signature to be validated under potentially different 96 certificate constraints than the originator of the message 97 used 99 Reissue of Certificate 101 The second attack deals with a Certificate Authority re- 102 issuing the signing certificate (or potentially one of its 103 certificates). This attack may start becoming more 104 frequent as Certificate Authorities re-issue there own 105 root certificates and change policies in the certificate 106 while doing so. When a certificate is re-issued using 107 different policies (or extensions), the validation code 108 may do different things based on the different policies 109 (or extensions). 111 The use of cross certificates in validating a certificate 112 path can lead to similar problems. When the cross 113 certificate is used in the validation code and the cross 114 certificate has different and non-equivalent policies and 115 extensions to the original certificate, the validation 116 code lead to different results based on whether the 117 original or the cross certificate is used. This problem 118 cannot be solved an requires due diligence be followed 119 when issuing cross certificates. 121 Rogue Duplicate Certificate Authority 123 The third attack deals with a rogue entity setting up a 124 certificate authority that attempts to duplicate the 125 structure of an existing Certificate Authority. 126 Specifically, the rogue entity issues a new certificate 127 with the same public keys as the signer used, but signed 128 by the rogue entity's private key. 130 3. Attack Responses 132 This document does not attempt to solve all of the above 133 attacks, however a brief description of responses to each 134 of the attacks is given in this section. 136 Substitution Attack 138 The denial of service attack cannot be prevented, once the 139 certificate identifier has been modified in transit no 140 verification of the signature is possible. There is no 141 way to automatically identify the attack either, it is 142 indistinguishable from a message corruption. 144 The substitution of a valid certificate can be responded 145 to in two different manners. The first is to make a 146 blanket statement that the use of the same public key in 147 two different certificates is bad practice and should be 148 avoided. In practice there is no practical way to prevent 149 users from doing this and we need to assume that they 150 will. Section 4 provides a new attribute to be included 151 in the SignerInfo signed attributes. This binds the 152 correct certificate identifier into the signature. This 153 will convert the attack from a potentially successful one 154 to a denial of service attack. 156 Reissue of Certificate 158 A Certificate Authority should never reissue a certificate 159 with different attributes. Certificate Authorities that 160 do so are following incorrect practices and cannot be 161 relied on. Addition of a hash of the complete signing 162 certificate (including signature value) to the 163 signingCertificate attribute defined in section 4 would 164 identify this attack for the end-entity certificate. At 165 the present time I do not feel this attack needs to be 166 prevented. 168 Preventing the re-issuing of CA certificates requires a 169 substantial change the attribute presented in section 4. 170 The only way to prevent this from occuring is to 1) have 171 the sequence of issuer/serial numbers with the hash of 172 each certificate be included and 2) prevent the use of 173 cross certificates in validating the leaf certificate. 174 Except in closed PKIs (where this should not be a problem 175 anyway) the problems associated with not using cross 176 certificates make solving this problem unacceptable. 178 Rogue Duplicate Certificate Authority 180 The best method of preventing this attack is to avoid 181 trusting the rogue certificate authority. The addition of 182 the hash to the attribute defined in section 4 can prevent 183 the use of end-entity certificates from the rogue 184 authority, however the only true way to prevent this 185 attack is to never trust the rough CA. 187 4. Signing Certificate Attribute 189 The signing certificate attribute is designed to prevent 190 the second version of the substitution attack and verify 191 that the correct certificate is being used in the 192 signature certificate validation process. 194 The following object identifier identifies the 195 signingCertificate attribute type: 197 id-aa-signingCertificate OBJECT IDENTIFIER ::= { 198 iso(1) 199 member-body(2) us(840) rsadsi(113549) pkcs(1) 200 pkcs9(9) 201 smime(16) id-aa(2) } 203 The definition of SigningCertificate is 205 SigningCertificate ::= IssuerAndSerialNumber 207 When this attribute is present in the set of signed 208 attributes of a SignerInfo structure, the issuer DN and 209 serial number of the certificate providing the public key 210 used in verifying the signature on the message is to be 211 compared to the values in this attribute. If the issuer 212 DN and serial number do not match, the signature is 213 considered to be invalid. 215 A. ASN.1 Module 217 To be supplied. 219 B. Open Issues 221 There is considerable feeling among a portion of the 222 community that more information needs to be placed in the 223 SigningCertificate ASN structure. I don't currently see a 224 need for this for the following reason: The identification 225 of a certificate currently used in CMS is the issuer and 226 serial number pair. The main purpose of this attribute at 227 present is to authenticate this information and thus this 228 is the only information that is duplicated. 230 Some people have expressed a desire to solve the "Reissue 231 of Certificate" attack. I see no pressing need to address 232 this attack. Any certificate authority that allowed for 233 this attack is operating in an improper fashion and should 234 not be used. In the event that the attack is deemed to be 235 of importance, it could be solved by the addition of a 236 hash to the SigningCertificate ASN structure. This would 237 allow the relying entity to verify that the certificate 238 was exactly the same as the signing entity claimed to have 239 used. 241 There was a desired expressed at one point to allow for a 242 complete chain to be specified in the SigningCertificate 243 attribute. This would address the "Rogue Duplicate 244 Certificate Authority" attack. I do not think we should 245 address this problem for the following reasons: 1. Nothing 246 says that I will use the exact same path of certificates 247 to verify the signature as what you "used" when producing 248 the signature. (An example of this would be the rollover 249 of the root certificate in the signers PKI.) 2. This 250 adds size to the attribute without gaining appreciable 251 benefits. 253 There is a portion of the community that feels that the 254 private/public key is the basis of a signature and an 255 attribute such as is proposed here is anathema. My 256 personal feeling on this issue is that while this is true 257 from a cryptographic sense, it is not true from a protocol 258 sense. In a signing protocol the certificate associated 259 with the signature is a vital portion of the signature 260 verification process. One cannot use any certificate that 261 comes to hand which will cryptographically verify the 262 signature. 264 References 266 CMS "Cryptographic Message Syntax", Internet Draft ietf- 267 draft-smime-cms 268 MUSTSHOULD "Key words for use in RFCs to Indicate 269 Requirement Levels", RFC 2119 271 Security Considerations 273 To be supplied, but will include: 274 Must keep a complete copy or equivalent of the 275 certificate in the trusted root database, issuer serial 276 number is insufficient. 277 Private key material must be protected. 279 Authors Address 281 Jim Schaad 282 Microsoft 283 One Microsoft Way 284 Redmond, WA 98052-6399 285 jimsch@microsoft.com