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.
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:
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.
The domainHash parameter MUST be the hash of the lowercase domain name or subdomain name. For example:
The registry MUST treat each domain and subdomain as a distinct entity. This means that:
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.
The DKIM public key MUST follow the format specified in RFC 6376. Here are the key requirements:
Key Format:
Key Requirements:
Key Registration Process:
Key Validation:
Example with keccak256:
Given the following DKIM DNS record from RFC 6376:
The process to register this key would be:
Calculate the keccak256 hash of the public key:
This event MUST be emitted when a new DKIM public key hash is registered for a domain.
This event MUST be emitted when a DKIM public key hash is revoked for a domain.
This function MUST return true if the provided key hash is valid for the given domain hash, and false otherwise.
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.
This EIP introduces a new interface and does not affect existing contracts or standards.
domainHash and keyHash algorithms carefully. Upgrading the hash function must be thoughtfully planned.Copyright and related rights waived via CC0.