By itself, verification of a digital signature only allows the verifier to conclude with a very high degree of certainty that the signature was created by a party with access to the corresponding private signing key. It follows that a verifier requires means to (1) obtain the public key for the purpose of verification and (2) infer useful attributes of the key holder.
In a traditional Public Key Infrastructure (PKI), the functions of key distribution and key accreditation are separated. In DKIM, these functions are both performed through the DNS [RFC4871] (Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, “DomainKeys Identified Mail (DKIM) Signatures,” May 2007.).
In either case, the ability to infer semantics from a digital signature depends on the assumption that the corresponding private key is only accessible to a party with a particular set of attributes. In traditional PKI a Trusted Third Party (TTP) vouches that the key holder has been validated with respect to a specified set of attributes. The range of attributes that may be attested in such a scheme is thus limited only to the type of attributes that a TTP can establish effective processes for validating.
In DKIM, TTPs are not employed and the functions of key distribution and accreditation are combined. Consequently there are only two types of inference that a signer may make from a key published in a DKIM Key Record:
That a party with the ability to control DNS records within a DNS zone intends to claim responsibility for messages signed using the corresponding private signature key.
That use of a specific key is restricted to a particular subset of messages.
The ability to draw any useful conclusion from verification of a digital signature relies on the assumption that the corresponding private key is only accessible to a party with a particular set of attributes. In the case of DKIM, this means that the party that created the corresponding DKIM key record in the specific zone intended to claim responsibility for the signed message.
Ideally we would like to draw a stronger conclusion, that if we obtain a DKIM key record from the DNS zone example.com, that the legitimate holder of the DNS zone example.com claims responsibility for the signed message. In order for this conclusion to be drawn it is necessary for the verifier to assume that the operational security of the DNS zone and corresponding private key are adequate.
Access to signing keys must be carefully managed to prevent use by unauthorized parties and to minimize the consequences should a compromise occur.
While a DKIM signing key is used to sign messages on behalf of many mail users, the signing key itself should be under direct control of as few key-holders as possible. Should a key-holder leave the organization, all signing keys held by that key holder should be withdrawn from service and if appropriate, replaced.
If key management hardware support is available, it should be used. If keys are stored in software, sppropriate file control protections must be employed and any location in which the private key is stored in plaintext form should be excluded from regular backup processes and should not be accessible through any form of network including private local area networks. Auditing software should be used periodically to verify that the permissions on the private key files remain secure.
Wherever possible a signature key should exist in exactly one location and be erased when no longer used. Ideally a signature key pair should be generated as close to the signing point as possible and only the public key component transferred to another party. If this is not possible, the private key MUST be transported in an encrypted format that protects the confidentiality of the signing key. A shared directory on a local file system does not provide adequate security for distribution of signing keys in plaintext form.
Key escrow schemes are not necessary and should not be used. In the unlikely event of a signing key becomming lost, a new signature key pair may be generated as easily as recovery from a key escrow scheme.
Responsibility for the security of a signing key should ultimately vest in a single named individual. Where multiple parties are authorized to sign messages, each signer should use a different key to enable accountability and auditing.
Best practices for management of cryptographic keying material require keying material to be refreshed at regular intervals, particular where key management is achieved through software. While this practice is highly desirable it is of considerably less importance than the requirement to maintain the secrecy of the corresponding private key. An operational practice in which the private key is stored in tamper proof hardware and changed once a year is considerably more desirable than one in which the signature key is changed on an hourly basis but maintained in software.
In order to use DKIM a DNS domain holder requires (1) the ability to create the necessary DKIM DNS records and (2) sufficient operational security controls to prevent insertion of spurious DNS records by an attacker.
DNS record management is usually operated by an administrative staff that is different from those who operate an organization's email service. In order to ensure that DKIM DNS records are accurate, this imposes a requirement for careful coordination between the two operations groups. If the best practices for private key management described above are observed, such deployment is not a one time event, DNS DKIM selectors will be changed over time signing keys are terminated and replaced.
At a minimum, a DNS server that handles queries for DKIM key records must allow the server administrators to add free-form TXT records. It would be better if the the DKIM records could be entered using a structured form, supporting the DKIM-specific fields.
Ideally DNSSEC [] should be employed in a configuration that provides protection against record insertion attacks and zone enumeration. In the case that NSEC3 [RFC 5155] records are employed to prevent insertion attack, the OPT-OUT flag must be set clear.
Selectors are assigned according to the administrative needs of the signing domain, such as for rolling over to a new key or for delegating of the right to authenticate a portion of the namespace to a trusted third party. Examples include:
jun2005.eng._domainkey.example.com
widget.promotion._domainkey.example.com
It is intended that assessments of DKIM identities be based on the domain name, and not include the selector. While past practice of a signer may permit a verifier to infer additional properties of particular messages from the structure DKIM key selector, unannounced administrative changes such as a change of signing softeware may cause such heuristics to fail at any time.
While a signer may establish business rules, such as issue of individual signature keys for each end-user, DKIM makes no provision for communicating these to other parties. Out of band distribution of such business rules is outside the scope of DKIM. Consequently there is no means by which external parties may make use of such keys to attribute messages with any greater granularity than a DNS domain.
If per-user signing keys are assigned for internal purposes (e.g. authenticating messages sent to an MTA for distribution), the following issues need to be considered before using such signatures as an alternative to traditional edge signing at the outbound MTA:
External verifiers will be unable to make use of the additional signature granularity without access to additional information passed out of band with respect to DKIM-base.
If the number of user keys is large, the efficiency of local caching of key records by verifiers will be lower.
A large number of end users may be less likely to be able to manage private key data securely on their personal computer than an administrator running an edge MTA.
A DKIM key record only asserts that the holder of the corresponding domain name makes a claim of responsibility for messages signed under the corresponding key. In some applications, such as bulk mail delivery it is desirable to delegate the ability to make a claim of responsibility to another party. In this case the trust relationship is established between the domain holder and the verifier but the private signature key is held by a third party.
Signature keys used by a third party signer should be kept entirely separate from those used by the domain holder and other third party signers. As with any other private key, the signature key pair should be generated by the third party signer and the public component of the key transmitted to the domain holder rather than have the domain holder generate the key pair and transmit the private component to the third party signer.
Domain holders should adopt a least privilege approach and grant third party signers the minimum access necessary to perform the desired function. Limiting the access granted to Third Party Signers serves to protect the interests of both parties. The domain holder minimizes their security risk and the Trusted Third Party Signer avoids unnecessary liability.
In the most restrictive case a domain holder maintains full control over the creation of key records and employ appropriate key record restrictions to enforce restrictions on the messages for which the third party signer is able to sign. If such restrictions are impractical, the domain holder should delegate a DNS subzone for publishing key records to the third party signer. The domain holder should not allow a third party signer unrestricted access to their DNS service for the purpose of publishing key records.
Deployments should establish, document and observe processes for managing the entire lifecycle of a public key pair.
When it is determined that a new key pair is required:
A Key Pair is generated by the signing device
A proposed key selector record is generated and transmitted to the DNS administration infrasrtructure.
The DNS administration infrastructure verifies the authenticity of the key selector registration request. If accepted
A key selector is assigned.
The corresponding key record published in the DNS.
Wait for DNS updates to propagate (if necessary).
Report assigned key selector to signing device.
Signer verifies correct registration of the key record.
Signer begins generating signatures using the new key pair.
Signer terminates any private keys that are no longer required due to issue of replacement.
When it is determined that a private signature key is no longer required:
Signer stops using the private key for signature operations.
Signer deletes all records of the private key, including in-memory copies at the signing device.
Signer notifies the DNS administration infrasrtructure that the signing key is withdrawn from
service and that the corresponding key records may be withdrawn from service at a specified future date.
The DNS administration infrastructure verifies the authenticity of the key selector termination request. If accepted
The key selector is scheduled for deletion at a future time determined by site policy.
Wait for deletion time to arrive
The key selector is deleted