Where is the specification for the changes?
Internet Draft P.
Hallam-Baker
Document: draft-dkim-pkix-00.txt
VeriSign Inc.
Expires: January 2006
August 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 - February !Undefined Bookmark, SAVEDATE
[Page 1]
Use of PKIX Certificates in DKIM
August 2005
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.......................................3
3. Interpreting Certificate
Data..................................4
4. Security
Considerations........................................4
4.1 Trustworthiness of Certificate
Data........................4
4.2 Establishing the Trustworthiness of Certificate
Issuers....5
5. IANA
Considerations............................................5
References........................................................5
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-BakerExpires - February !Undefined Bookmark, SAVEDATE
[Page 2]
Use of PKIX Certificates in DKIM
August 2005
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.509v3 certificate by means of a URL.
For example the following key record declares that a
certificate
may be obtained using the URL
http://pki.example.com/certs/182871282.x509:
x509=http://pki.example.com/certs/182871282.x509
2.2
Certificate Path URL
Hallam-BakerExpires - February !Undefined Bookmark, SAVEDATE
[Page 3]
Use of PKIX Certificates in DKIM
August 2005
The key record attribute x509 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.pkcs7:
x509=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 XXX 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.
4.
Security Considerations
4.1
Trustworthiness of Certificate Data
Hallam-BakerExpires - February !Undefined Bookmark, SAVEDATE
[Page 4]
Use of PKIX Certificates in DKIM
August 2005
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.
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
Hallam-BakerExpires - February !Undefined Bookmark, SAVEDATE
[Page 5]
Use of PKIX Certificates in DKIM
August 2005
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(_at_)verisign(_dot_)com
Hallam-BakerExpires - February !Undefined Bookmark, SAVEDATE
[Page 6]
_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim