ERC-7969: DomainKeys Identified Mail (DKIM) Registry

Abstract

---

This EIP proposes a standard interface for registering and validating DomainKeys Identified Mail (DKIM) public key hashes on the Ethereum blockchain. The interface allows domain owners to register their DKIM public key hashes and enables third parties to verify the validity of these hashes.

The registry operates by storing hashes of both domain names and DKIM public keys, creating a mapping that enables on-chain verification of DKIM signatures. Domain owners register their DKIM public key hashes by extracting the public key from their DNS TXT records (as specified in RFC 6376), computing the hash, and submitting it to the registry. DKIM clients can then query the registry to verify that a given public key hash is authorized for a specific domain, enabling trustless email ownership verification for applications such as account abstraction and social recovery mechanisms.

Motivation

---

With the growing adoption of Account Abstraction ERC-4337 and the emergence of ZK Email Technology, there is a need for a standardized way to verify email ownership on-chain. This EIP provides a crucial building block for these technologies by enabling the verification of DKIM signatures through on-chain registries.

This standard enables several important use cases:

1. Account Abstraction: When combined with zkEmail, this registry enables email-based account abstraction. Users can prove ownership of their email address through DKIM signatures, allowing them to:
   • Create and manage smart contract wallets
   • Sign transactions using their email credentials
   • Implement social recovery mechanisms
2. Account Recovery: The registry facilitates secure account recovery mechanisms:
   • Users can recover their wallet access by on-chain proving email ownership
   • The process is trustless and secure due to the cryptographic nature of DKIM

Specification

---

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.

Interface

Domain Hash

The domainHash parameter MUST be the hash of the lowercase domain name or subdomain name. For example:

• For the domain "example.com" using keccak256:

• For the subdomain "mail.example.com" using keccak256:

The registry MUST treat each domain and subdomain as a distinct entity. This means that:

1. A key hash registered for "example.com" does not automatically apply to its subdomains
2. Each subdomain can have its own independent DKIM key hash registration
3. The full domain name (including subdomain if present) must be hashed as a single string

Key Hash

The keyHash parameter MUST be a cryptographic hash of the DKIM public key. The public key should be in the standard DKIM format as specified in RFC 6376.

Implementations MAY choose any cryptographically secure hash function for computing the key hash. Common choices include keccak256, Poseidon (for zk-friendly applications) or other hash functions.

DKIM Public Key Specification

The DKIM public key MUST follow the format specified in RFC 6376. Here are the key requirements:

1. Key Format:

   • The public key MUST be in the format specified in the DKIM DNS record (p=PUBLIC_KEY)
   • The key MUST be base64 encoded
   • The key MUST NOT include the PEM headers or any other formatting
   • The key MUST be the raw public key data as specified in the DKIM DNS record

2. Key Requirements:

   • The key MUST be a valid RSA public key
   • The key MUST be in the format as published in the domain's DNS TXT record
   • The key MUST be the exact value from the p= parameter in the DKIM DNS record
   • The key MUST NOT include any whitespace or line breaks

3. Key Registration Process:

   1. Obtain the DKIM public key from the domain's DNS TXT record
   2. Extract the value from the p= parameter
   3. Calculate the hash of the raw public key using the implementation's chosen hash function
   4. Register the hash in the DKIM registry

4. Key Validation:

   • The registry MUST verify that the provided key hash corresponds to a valid DKIM public key
   • The key MUST be in the correct format as specified in RFC 6376
   • The key MUST be the exact value as published in the domain's DNS record

5. Example with keccak256:

   Given the following DKIM DNS record from RFC 6376:

   The process to register this key would be:

   1. Extract the public key value from the p= parameter:

6. Calculate the keccak256 hash of the public key:

   3. Calculate the domain hash:
   4. Register the key hash in the registry:

Events

KeyHashRegistered

This event MUST be emitted when a new DKIM public key hash is registered for a domain.

KeyHashRevoked

This event MUST be emitted when a DKIM public key hash is revoked for a domain.

Functions

isKeyHashValid

This function MUST return true if the provided key hash is valid for the given domain hash, and false otherwise.

Rationale

---

The interface is designed to be simple and focused on the core functionality of DKIM public key hash registration and validation. The use of keccak256 hashing for both domain names and public keys ensures consistent and secure handling of the data.

The events allow for efficient tracking of key registrations and revocations, which is important for maintaining the integrity of the registry.

Backwards Compatibility

---

This EIP introduces a new interface and does not affect existing contracts or standards.

Reference Implementation

---

Security Considerations

---

1. Domain owners must ensure they have control over their private keys and domain names.
2. The registry implementation should include proper access control mechanisms to prevent unauthorized registrations.
3. The registry should implement a mechanism to handle key rotation and revocation.
4. Implementations should consider rate limiting to prevent spam registrations.
5. Registries should select the domainHash and keyHash algorithms carefully. Upgrading the hash function must be thoughtfully planned.

Copyright

---

Copyright and related rights waived via CC0.