Internet Draft P. Hallam-Baker Document: draft-dkim-pkix-00.txt VeriSign Inc. Expires: January 2006 September 2005 Use of PKIX Certificates in DKIM Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire in January 2006. Abstract This document describes a mechanism for using X.509v3 certificates that comply with the PKIX profile with Domain Keys Identified Mail (DKIM). An email signer MAY inform potential relying parties that a key described in a DKIM key record has a corresponding PKIX certificate or certificate path by means of an attribute in the key record that provides the URL of the certificate data. An email verifier MAY choose to make use of this information in deciding the disposition of the signed email message. Conventions used in this document Hallam-Baker Expires - March 2006 [Page 1] Use of PKIX Certificates in DKIM September 2006 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. Table of Contents 1. Introduction...................................................2 2. Key Record.....................................................3 2.1 The Key Record Attribute x509..............................3 2.2 Certificate Path URL.......................................4 3. Interpreting Certificate Data..................................4 4. Security Considerations........................................5 4.1 Trustworthiness of Certificate Data........................5 4.2 Establishing the Trustworthiness of Certificate Issuers....5 5. IANA Considerations............................................6 References........................................................6 Acknowledgments...................................................6 Copyright.........................................................6 Author's Addresses................................................6 1. Introduction Domain Keys Identified Mail [2] (DKIM) defines a mechanism for authenticating an email message against a key record stored in the DNS. Although DKIM by design does not require use of a Trusted Third Party (TTP) the use of TTP services with DKIM increases the range of assurances that can be provided to a relying party. This document describes the use of DKIM with digital certificates that comply with the PKIX [3] profile of the X.509v3 [4] specification. The DKIM core and DNS based key retrieval mechanism provides the relying party with a robust assurance that an email message was signed by a party authorized to do so by the domain name owner. This allows email spoofing attacks against a particular domain name to be detected but does not prevent the use of ‘disposable’ domain names to send spam or ‘cousin’ (also known as look-alike) domain names for phishing. Accreditation by a TTP may provide a relying party with valuable additional information that allows the relying party to evaluate a DKIM signature more accurately. For example many Certificate Authorities offer a certificate that is only issued after verifying ‘proof of right’ documentation provided by the applicant that establishes that the applicant is a bona-fide registered business in some locale. While a verified business registration does not in itself guarantee that a business is honest it does demonstrate a likelihood that the registered Hallam-Baker Expires - March 2006 [Page 2] Use of PKIX Certificates in DKIM September 2006 party can be held accountable through civil or criminal process should the need arise. In the wake of criminal prosecutions and civil litigation the vast majority of spammers attempt to avoid these forms of accountability. A verified business registration is therefore significant when evaluating the probability that an email message was sent by a spammer. Accredited data supplied by a TTP may also be employed to control certain types of phishing attack. While an unaccredited DKIM signature can allow detection of an attempt to impersonate a domain name, an email phishing attack is an attack against a trusted brand. The use of cousin addresses in phishing attacks such as security-bigbank.com in place of bigbank.com is already common. The accountability established through existing TTP verification of proof of right documentation provides a significant control against this form of attack. A commercial TTP has a vested interest in maintaining the trustworthiness of their brand and the introduction of more stringent verification procedures may be anticipated in the event that existing procedures prove inadequate. The effectiveness of cousin addresses may be further reduced through the introduction of TTP services that provide for verification of the trusted brand that is being attacked in addition to the domain name. For example a CA might publish a verified brand in the certificate issued by means the PKIX Logotype extension [5]. 2. Key Record The DKIM Key Record contains a public key value and related attributes. This specification defines attributes that allow the location of certificate information related to the public key value to be declared. 2.1 The Key Record Attribute x509 The key record attribute x509 specifies the location of a PKIX compliant X.509 certificate by means of a URL. Verifiers MUST support version 3 of the X.509 profile as required by PKIX. A version 1 certificate offered by the signer MAY be accepted as minimally compliant with the version 3 specification but this use is now considered obsolete. For example the following key record declares that a certificate may be obtained using the URL http://pki.example.com/certs/182871282.cer: Hallam-Baker Expires - March 2006 [Page 3] Use of PKIX Certificates in DKIM September 2006 x509=http://pki.example.com/certs/182871282.x509 2.2 Certificate Path URL The key record attribute x509path specifies the location of a certificate path encapsulated in a PKCS#7 binding. For example the following key record declares that a certificate path may be obtained using the URL http://pki.example.com/certs/182871282.p7c: x509path=http://pki.example.com/certs/182871282.pkcs7 3. Interpreting Certificate Data Signature verifiers are neither required to retrieve certificate data referenced in a Key Record nor accept certificate data retrieved as authoritative. Signature verifiers SHOULD NOT treat certificate data as authoritative if: . The subject public key algorithm of the certificate does not match the public key algorithm specified in the Key Record. . The subject public key value of the certificate does not match the public key value specified in the Key Record. . The signature verifier is unable to establish the trustworthiness of the certificate by forming a certificate trust path to a trusted root as described in section 6 of [3] A Signature verifier MAY verify the current status of the certificate by reference to a certificate status mechanism such as a CRL[] or OCSP[]. A Signature verifier MAY make use of a delegated certificate path discovery algorithm such as XKMS[] or SCVP[] A certificate that meets the trustworthiness criteria required by this section and any additional trustworthiness criteria determined by the signature verifier is said to be trusted by the signature verifier. Hallam-Baker Expires - March 2006 [Page 4] Use of PKIX Certificates in DKIM September 2006 4. Security Considerations 4.1 Trustworthiness of Certificate Data The data provided by a TTP is no more trustworthy than TTP that provided it and the procedures employed to verify it. The publication of a certificate in a DKIM key record does not mean that a relying party can trust it: . A certificate MUST NOT be relied upon as an authentic assertion by the purported issuer until their provenance has been established by applying the standard PKIX rules for establishing the validity of a certificate. . A certificate MUST NOT be relied upon as trustworthy until it has been established as an authentic assertion by a certificate issuer that has previously been determined to be trustworthy. 4.2 Establishing the Trustworthiness of Certificate Issuers Relying parties MUST establish the trustworthiness of a certificate issuer before relying on information provided by the issuer. If the relying party makes use of a feedback mechanism to rate a certificate issuer by reference to past performance an attacker might attempt to establish a good reputation by acting honestly for a period of time before defecting. In practice the cost of establishing a significant position as a certificate issuer is unlikely to make this form of attack attractive to an attacker unless they are able to devise a new form of attack that is considerably more profitable in a short space of time than those seen thus far. 4.3 Presentation of Logotype information If information from a logotype attribute is to be displayed to an end user (e.g. by a mail user agent) the verifier MUST ensure that the issuing TTP offers procedures that are trustworthy for this particular purpose. The verifier SHOULD perform certificate status checking. Hallam-Baker Expires - March 2006 [Page 5] Use of PKIX Certificates in DKIM September 2006 4.4 Security of Retrieval Protocol Verifiers SHOULD determine the trustworthiness of a certificate by verifying the X.509 trust chain and not rely on the security of the location mechanism to determine the trustworthiness of the certificate. 5. IANA Considerations This document has no actions for IANA. References 1 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 2 DKIM 3 PKIX 4 X.509 5 Logotype cert Acknowledgments TBS Copyright Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights." This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Author's Addresses Phillip Hallam-Baker VeriSign Inc. Email: pbaker@verisign.com Hallam-Baker Expires - March 2006 [Page 6] Use of PKIX Certificates in DKIM September 2006 Hallam-Baker Expires - March 2006 [Page 7]