Internet DRAFT - draft-dkim-pkix
draft-dkim-pkix
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]
