ietf-dkim
[Top] [All Lists]

[ietf-dkim] First cut on certificate extensions draft

2008-12-16 17:03:57
An update of the extensions draft that focuses exclusively on the X.509 certs 
extensions is attached.
 
Note that even though this is intended to be an individual submission, comments 
from others are welcome. The point of not making it a WG charter item is that 
this work item is not sufficient by itself to justify rechartering.
 
 
This has undergone substantial modification as a result of Paul's input at the 
meeting. In particular I realized that there are significant use cases for both 
'call by reference' and 'call by value'.
 
Another major modification is that in this draft, ALL certificates are encoded 
as a MIME application/pkix-pkipath object as described in the TLS extensions 
RFC. So even if you have a single self-signed cert, you have tio wrap it in a 
path.
 
The reason for this is that in the context of DKIM, a self-signed cert offers 
no real advantage over a DNS accredited key, other than an even lower barrier 
to entry. As with SSL, I tend to think that self-signed end-entity certs should 
be banned anyway, if someone wants to certify themselves they should set up a 
CA and have one self signed issuing cert and chain end-entity certs off it.
 
Having only one data object to manage is a lot simpler than having separate 
provision for certs and cert paths.
 
The choice of pkix-pkipath as the path representation is because this is a 
bona-fide IETF standard and the CMS encapsulation is not. Also, there is a 
significant chance that at least some CAs have already built out the 
pkix-pkipath logic to support OMA applications.
 
 
I have not filled out the security considerations, just given headlines as it 
is usually best to discuss the architecture and get that settled first.
 
 
 TOC 
Internet Engineering Task ForceP. Hallam-Baker
Internet-DraftVeriSign Inc
Intended status: InformationalDecember 5, 2008
Expires: June 8, 2009 


Use of X.509 Certificates with Domain Keys Identified Mail (X-DKIM)
draft-hallambaker-dkim-pkix-00

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 on June 8, 2009.

Abstract

The base DKIM protocol is not designed to meet the needs of applications that require non-repudiation or external accreditation services. The combination of a DKIM message signature and an X.509v3 certificate permits these use cases to be met by the existing infrastructure of Trusted Third Parties.

Mechanisms for using an X.509v3 certificate to provide accreditation for the public key used to sign a DKIM signed message are described. A certificate may be passed by value as a message header or passed by means of a URI reference in either the message header or the DKIM key record. The different mechanisms meet the different needs of different use cases.



Table of Contents

1.  Introduction
    1.1.  Requirements Language
2.  Requirements
    2.1.  External Accreditation
    2.2.  Persistent Signatures
    2.3.  Mail User Agent Signatures
3.  Technical Considerations
    3.1.  Certificate Contents
        3.1.1.  Representation of Certificate Paths
        3.1.2.  Issuer Accreditation
    3.2.  Retrieval
        3.2.1.  Retrieval by Value
        3.2.2.  Retrieval by Reference
            3.2.2.1.  Denial of Service Amplification Attack
        3.2.3.  Processing Model
4.  X509 Certificate Path Binding Syntax
    4.1.  DKIM-PKIX-PKIPATH Header
    4.2.  DKIM Key Record by URI Reference
5.  Acknowledgements
6.  IANA Considerations
7.  Security Considerations
    7.1.  Trustworthiness of Accreditation Providers
    7.2.  Use of Self-Signed Certificates
    7.3.  Denial of Service Attack
    7.4.  Message Modification
    7.5.  Signature Semantics and Ceremony
8.  Normative References
§  Author's Address
§  Intellectual Property and Copyright Statements




 TOC 

1.  Introduction



 TOC 

1.1.  Requirements Language

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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].



 TOC 

2.  Requirements

Domain Keys Identified Mail (DKIM) RFC 4871 (Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, “DomainKeys Identified Mail (DKIM) Signatures,” May 2007.) [RFC4871] provides a means by which the holder of a domain name may make a claim of responsibility for a message to intended recipients.

While this assurance is considerably narrower than the range of assurances that traditional email authentication protocols have sought to achieve, it is sufficient to meet the needs of accountability based approaches to reducing email abuse. Consequently, these needs may be met through a lightweight, DNS based key distribution architecture which does not provide for persistent signatures or third party accreditation of key holders.

In order to meet such needs using DKIM it is necessary to supplement or replace the DNS based key distribution scheme with a Public Key Infrastructure (PKI) that is capable of meeting these requirements. This document describes the use of DKIM with X.509v3 certificates as described in RFC 5280 (Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” May 2008.) [RFC5280].



 TOC 

2.1.  External Accreditation

A digital signature establishes a relatinship between a signed document and a public key. A PKI establishes a relationship between a public key and a public key holder.

The base DKIM specification provides a key distribution mechanism that only establishes a relationship between a public key holder and a DNS name. In many applications it is desirable to establish other attributes of the key holder, as assesed by a trusted third party, such as:

  • The verified identity of the key holder
  • The verified brand of the key holder
  • The assessed reputation of the key holder



 TOC 

2.2.  Persistent Signatures

It is frequently desirable to verify a message signature after a period of weeks, months or years. In such circumstances, the key distribution infrastructure MUST be capable of allowing key discovery to take place even if the original signatory is either unable or unwilling to assist.

While the term 'non-repudiation' is frequently used to describe a technical requirement for persistent signatures, the term is also used in a legal context that is out of scope of this document.



 TOC 

2.3.  Mail User Agent Signatures

DKIM provides for email message accountability at the domain level. Within organizations it is frequently desirable to provide finer grained accountability and emplopy signatures that can be tracked back to specific users and/or machines.

While the DKIM key distribution infrastructure is technically capable of supporting uses in which each end user has a personal signing key registered in the DNS, the primary function of the DNS is to provide discovery information for Internet hosts and Internet services. DNS deployments do not typically carry information relating to individual end users. Use of a separate infrastructure designed for the purpose is greatly preferred.



 TOC 

3.  Technical Considerations



 TOC 

3.1.  Certificate Contents



 TOC 

3.1.1.  Representation of Certificate Paths

Certificate paths are represented using the application/pkix-pkipath content type described in RFC 3546 (Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, “Transport Layer Security (TLS) Extensions,” June 2003.) [RFC3546].



 TOC 

3.1.2.  Issuer Accreditation

The means of determining the capabilty and fitness of purpose of certificate issuers is outside the scope of this document.



 TOC 

3.2.  Retrieval

Certificate path data MAY be passed by reference or by value.



 TOC 

3.2.1.  Retrieval by Value

Passing certificate path value by value in the signed message itself allows the message to provide a self-contained authentication package requiring no additional information to be specified other than the ultimate roots of trust.

The cost of passing certificate path data in the message itself is that every message must contain the complete path data (typically in the region of 4,000 bytes), leading to redundant data exchange. Nor is this quantity of data compatible with use of DNS as a distribution mechanism.



 TOC 

3.2.2.  Retrieval by Reference

Retrieval by reference has negligible impact on applications that do not support the use of DKIM with certificates as a URL locator for a certificate path can be encoded in 40 bytes rather than 4000.

The disadvantage of using retrieval by reference is that faulty implementation can provide an opportunity for a denial of service attack.



 TOC 

3.2.2.1.  Denial of Service Amplification Attack

A denial of service attack is of particular concern when it provides a means of amplification. The effort required to resolve an arbitrary URI reference is potentially much greater than the effort required to send an email message causing the recipient to resolve the URI reference.

Relying parties MUST employ effective measures to prevent an attack applification opportunity being presented to an attacker. For example a relying party MAY avoid presenting an attack amplification opportunity by limiting the amount of data accepted to no more than 16,000 bytes.



 TOC 

3.2.3.  Processing Model

A full feature PKI such as X.509v3/PKIX necessarily requires more processing steps and more resources than the minimal key discovery mechanism supported by DKIM. Fortunately the impact of these greater processing demands MAY be effectively reduced in many circumstances by amortising processing steps over multiple key query operations.

For example, it is only necessary for a certificate path URI reference to be retrieved the first time it is encountered. Subsequent references MAY make use of a locally cached copy of the certificate path data. The same condideration applies in turn to certificate path processing, once the path itself is validated, a verifier need only perform certificate status checking and only then if the reported status is likely to have changed since the last status update was received.



 TOC 

4.  X509 Certificate Path Binding Syntax

A DKIM signer MAY provide a verifier with details of a certificate path by means of:

  • A message header specifying the certificate path by value.
  • A message header specifying the certificate path by URI reference.
  • A DKIM key record attribute specifying the certificate path by reference.

In each case the certificate path is offered to provide the end-recipient with additional information.



 TOC 

4.1.  DKIM-PKIX-PKIPATH Header

The DKIM-PKIX-PATH header is used to pass a PKIX-PKIPATH, either by URI reference or by value.

d=
The domain component of the key selector for the corresponding signature. (plain-text; REQUIRED).
s=
The selector component of the key selector for the corresponding signature.(plain-text; REQUIRED).
uri=
A URI specifying a location from which the corresponding PKIX-PATH may be retrieved. (plain-text; OPTIONAL). The URI value specified SHOULD resolve to a data object with a MIME type of application/pkix-pkipath containing a certificate path accrediting the signing key specified using the d= and s= attributes.
value=
The value of the corresponding PKIX-PATH (base64; OPTIONAL). If specified SHOULD contain a pkix-pkipath object containing a certificate path accrediting the signing key specified using the d= and s= attributes.

A DKIM-PKIX-PKIPATH header that does not contain a uri= attribute MUST contain a value= attribute.

If both a uri= attribute and a value= attribute are present, the certificate path may be split between the two pkix-pkipath objects returned. For example the end-entity certificate MAY be specified by value and the issuer chain information by reference.

A DKIM signature MAY be used in combination with the normal DNS based query method or as a replacement. If the key can only be obtained through the DKIM-PKIX-PATH header mechanism, the signing application MUST specify the query method q=header/pkix-pkipath in the corresponding DKIM signature header.



 TOC 

4.2.  DKIM Key Record by URI Reference

A DKIM Key record may specify a certificate path by reference using the pkix_pkipath attribute:

pkix_pkipath
A URI specifying a location from which the corresponding PKIX-PATH may be retrieved. (plain-text; REQUIRED). The URI value specified SHOULD resolve to a data object with a MIME type of application/pkix-pkipath containing a certificate path accrediting the signing key specified using the d= and s= attributes.



 TOC 

5.  Acknowledgements

The ideas in this document arose from extensive discussions with the DKIM working group, in particular Paul Hoffman, Hector Santos and others.



 TOC 

6.  IANA Considerations

This document requests allocation of a DKIM key record tag 'pkix-pkipath'

This document requests allocation of an SMTP header tag 'DKIM-PKIX-PKIPATH'



 TOC 

7.  Security Considerations



 TOC 

7.1.  Trustworthiness of Accreditation Providers



 TOC 

7.2.  Use of Self-Signed Certificates



 TOC 

7.3.  Denial of Service Attack



 TOC 

7.4.  Message Modification



 TOC 

7.5.  Signature Semantics and Ceremony



 TOC 

8. Normative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, “Transport Layer Security (TLS) Extensions,” RFC 3546, June 2003 (TXT).
[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, “DomainKeys Identified Mail (DKIM) Signatures,” RFC 4871, May 2007 (TXT).
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” RFC 5280, May 2008 (TXT).


 TOC 

Author's Address

  Phillip Hallam-Baker
  VeriSign Inc
Email:  pbaker(_at_)verisign(_dot_)com


 TOC 

Full Copyright Statement

Intellectual Property

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html
<Prev in Thread] Current Thread [Next in Thread>