[ietf-dkim] First cut on certificate extensions draft2008-12-16 17:03:57An 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 |
TOC |
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 |
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 |
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:
TOC |
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 |
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 |
TOC |
TOC |
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 |
The means of determining the capabilty and fitness of purpose of certificate issuers is outside the scope of this document.
TOC |
Certificate path data MAY be passed by reference or by value.
TOC |
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 |
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 |
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 |
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 |
A DKIM signer MAY provide a verifier with details of a certificate path by means of:
In each case the certificate path is offered to provide the end-recipient with additional information.
TOC |
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 |
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 |
The ideas in this document arose from extensive discussions with the DKIM working group, in particular Paul Hoffman, Hector Santos and others.
TOC |
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 |
TOC |
TOC |
TOC |
TOC |
TOC |
TOC |
[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 |
Phillip Hallam-Baker | |
VeriSign Inc | |
Email: | pbaker(_at_)verisign(_dot_)com |
TOC |
Copyright © The IETF Trust (2008).
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, THE IETF TRUST 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.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr(_at_)ietf(_dot_)org.
_______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
<Prev in Thread] | Current Thread | [Next in Thread> |
---|---|---|
|
Next by Date: | [ietf-dkim] Next steps for draft-ietf-dkim-ssp, Pasi(_dot_)Eronen(_at_)nokia(_dot_)com |
---|---|
Next by Thread: | Re: [ietf-dkim] First cut on certificate extensions draft, Charles Lindsey |
Indexes: | [Date] [Thread] [Top] [All Lists] |