idnits 2.17.1 draft-dkim-pkix-00.txt: -(81): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(82): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(90): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 271. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == There are 3 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** 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 101 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (September 2005) is 6791 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? '1' on line 50 looks like a reference -- Missing reference section? '2' on line 69 looks like a reference -- Missing reference section? '3' on line 174 looks like a reference -- Missing reference section? '4' on line 75 looks like a reference -- Missing reference section? '5' on line 121 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft P. Hallam-Baker 3 Document: draft-dkim-pkix-00.txt VeriSign Inc. 4 Expires: January 2006 September 2005 6 Use of PKIX Certificates in DKIM 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware have 12 been or will be disclosed, and any of which he or she becomes aware 13 will be disclosed, in accordance with Section 6 of 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 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 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 in January 2006. 33 Abstract 35 This document describes a mechanism for using X.509v3 certificates 36 that comply with the PKIX profile with Domain Keys Identified Mail 37 (DKIM). 39 An email signer MAY inform potential relying parties that a key 40 described in a DKIM key record has a corresponding PKIX certificate 41 or certificate path by means of an attribute in the key record that 42 provides the URL of the certificate data. An email verifier MAY 43 choose to make use of this information in deciding the disposition 44 of the signed email message. 46 Conventions used in this document 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 49 this document are to be interpreted as described in RFC-2119 [1]. 51 Table of Contents 53 1. Introduction...................................................2 54 2. Key Record.....................................................3 55 2.1 The Key Record Attribute x509..............................3 56 2.2 Certificate Path URL.......................................4 57 3. Interpreting Certificate Data..................................4 58 4. Security Considerations........................................5 59 4.1 Trustworthiness of Certificate Data........................5 60 4.2 Establishing the Trustworthiness of Certificate Issuers....5 61 5. IANA Considerations............................................6 62 References........................................................6 63 Acknowledgments...................................................6 64 Copyright.........................................................6 65 Author's Addresses................................................6 67 1. Introduction 69 Domain Keys Identified Mail [2] (DKIM) defines a mechanism for 70 authenticating an email message against a key record stored in the 71 DNS. Although DKIM by design does not require use of a Trusted 72 Third Party (TTP) the use of TTP services with DKIM increases the 73 range of assurances that can be provided to a relying party. This 74 document describes the use of DKIM with digital certificates that 75 comply with the PKIX [3] profile of the X.509v3 [4] specification. 77 The DKIM core and DNS based key retrieval mechanism provides the 78 relying party with a robust assurance that an email message was 79 signed by a party authorized to do so by the domain name owner. 80 This allows email spoofing attacks against a particular domain name 81 to be detected but does not prevent the use of �disposable� domain 82 names to send spam or �cousin� (also known as look-alike) domain 83 names for phishing. 85 Accreditation by a TTP may provide a relying party with valuable 86 additional information that allows the relying party to evaluate a 87 DKIM signature more accurately. 89 For example many Certificate Authorities offer a certificate that 90 is only issued after verifying �proof of right� documentation 91 provided by the applicant that establishes that the applicant is a 92 bona-fide registered business in some locale. While a verified 93 business registration does not in itself guarantee that a business 94 is honest it does demonstrate a likelihood that the registered 95 party can be held accountable through civil or criminal process 96 should the need arise. In the wake of criminal prosecutions and 97 civil litigation the vast majority of spammers attempt to avoid 98 these forms of accountability. A verified business registration is 99 therefore significant when evaluating the probability that an email 100 message was sent by a spammer. 102 Accredited data supplied by a TTP may also be employed to control 103 certain types of phishing attack. While an unaccredited DKIM 104 signature can allow detection of an attempt to impersonate a domain 105 name, an email phishing attack is an attack against a trusted 106 brand. The use of cousin addresses in phishing attacks such as 107 security-bigbank.com in place of bigbank.com is already common. 109 The accountability established through existing TTP verification of 110 proof of right documentation provides a significant control against 111 this form of attack. A commercial TTP has a vested interest in 112 maintaining the trustworthiness of their brand and the introduction 113 of more stringent verification procedures may be anticipated in the 114 event that existing procedures prove inadequate. 116 The effectiveness of cousin addresses may be further reduced 117 through the introduction of TTP services that provide for 118 verification of the trusted brand that is being attacked in 119 addition to the domain name. For example a CA might publish a 120 verified brand in the certificate issued by means the PKIX Logotype 121 extension [5]. 123 2. Key Record 125 The DKIM Key Record contains a public key value and related 126 attributes. This specification defines attributes that allow the 127 location of certificate information related to the public key value 128 to be declared. 130 2.1 The Key Record Attribute x509 132 The key record attribute x509 specifies the location of a PKIX 133 compliant X.509 certificate by means of a URL. 135 Verifiers MUST support version 3 of the X.509 profile as required 136 by PKIX. A version 1 certificate offered by the signer MAY be 137 accepted as minimally compliant with the version 3 specification 138 but this use is now considered obsolete. 140 For example the following key record declares that a certificate 141 may be obtained using the URL 142 http://pki.example.com/certs/182871282.cer: 144 x509=http://pki.example.com/certs/182871282.x509 146 2.2 Certificate Path URL 148 The key record attribute x509path specifies the location of a 149 certificate path encapsulated in a PKCS#7 binding. 151 For example the following key record declares that a certificate 152 path may be obtained using the URL 153 http://pki.example.com/certs/182871282.p7c: 155 x509path=http://pki.example.com/certs/182871282.pkcs7 157 3. Interpreting Certificate Data 159 Signature verifiers are neither required to retrieve certificate 160 data referenced in a Key Record nor accept certificate data 161 retrieved as authoritative. 163 Signature verifiers SHOULD NOT treat certificate data as 164 authoritative if: 166 . The subject public key algorithm of the certificate does not 167 match the public key algorithm specified in the Key Record. 169 . The subject public key value of the certificate does not match 170 the public key value specified in the Key Record. 172 . The signature verifier is unable to establish the 173 trustworthiness of the certificate by forming a certificate 174 trust path to a trusted root as described in section 6 of [3] 176 A Signature verifier MAY verify the current status of the 177 certificate by reference to a certificate status mechanism such as 178 a CRL[] or OCSP[]. 180 A Signature verifier MAY make use of a delegated certificate path 181 discovery algorithm such as XKMS[] or SCVP[] 183 A certificate that meets the trustworthiness criteria required by 184 this section and any additional trustworthiness criteria determined 185 by the signature verifier is said to be trusted by the signature 186 verifier. 188 4. Security Considerations 190 4.1 Trustworthiness of Certificate Data 192 The data provided by a TTP is no more trustworthy than TTP that 193 provided it and the procedures employed to verify it. The 194 publication of a certificate in a DKIM key record does not mean 195 that a relying party can trust it: 197 . A certificate MUST NOT be relied upon as an authentic 198 assertion by the purported issuer until their provenance has 199 been established by applying the standard PKIX rules for 200 establishing the validity of a certificate. 202 . A certificate MUST NOT be relied upon as trustworthy until it 203 has been established as an authentic assertion by a 204 certificate issuer that has previously been determined to be 205 trustworthy. 207 4.2 Establishing the Trustworthiness of Certificate Issuers 209 Relying parties MUST establish the trustworthiness of a certificate 210 issuer before relying on information provided by the issuer. 212 If the relying party makes use of a feedback mechanism to rate a 213 certificate issuer by reference to past performance an attacker 214 might attempt to establish a good reputation by acting honestly for 215 a period of time before defecting. 217 In practice the cost of establishing a significant position as a 218 certificate issuer is unlikely to make this form of attack 219 attractive to an attacker unless they are able to devise a new form 220 of attack that is considerably more profitable in a short space of 221 time than those seen thus far. 223 4.3 Presentation of Logotype information 225 If information from a logotype attribute is to be displayed to an 226 end user (e.g. by a mail user agent) the verifier MUST ensure that 227 the issuing TTP offers procedures that are trustworthy for this 228 particular purpose. The verifier SHOULD perform certificate status 229 checking. 231 4.4 Security of Retrieval Protocol 233 Verifiers SHOULD determine the trustworthiness of a certificate by 234 verifying the X.509 trust chain and not rely on the security of the 235 location mechanism to determine the trustworthiness of the 236 certificate. 238 5. IANA Considerations 240 This document has no actions for IANA. 242 References 244 1 Bradner, S., "Key words for use in RFCs to Indicate Requirement 245 Levels", BCP 14, RFC 2119, March 1997 247 2 DKIM 248 3 PKIX 249 4 X.509 250 5 Logotype cert 252 Acknowledgments 254 TBS 256 Copyright 258 Copyright (C) The Internet Society (2005). 260 This document is subject to the rights, licenses and restrictions 261 contained in BCP 78, and except as set forth therein, the authors 262 retain all their rights." 264 This document and the information contained herein are provided on 265 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 266 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 267 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 268 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 269 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 270 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 271 PARTICULAR PURPOSE. 273 Author's Addresses 275 Phillip Hallam-Baker 276 VeriSign Inc. 277 Email: pbaker@verisign.com