The c= tag is a small but vital component of an ARC signature. To understand its role, you first need a basic grasp of what Authenticated Received Chain (ARC) is. ARC provides an authenticated "chain of custody" for an email message. It's designed to solve a common problem where legitimate authentication methods like SPF and DKIM fail when a message is forwarded, for example, through a mailing list. ARC preserves the initial authentication results as the email travels through different servers.
At the heart of this system are the ARC headers, which are added by each server (or "hop") that handles the message. The ARC-Message-Signature is one of these headers, and it contains a digital signature very similar to a DKIM signature. This is where the c= tag comes into play.
What is canonicalization?
The c= tag stands for "canonicalization". This is the process of converting the email's headers and body into a standardized, or canonical, format before the cryptographic signature is applied. This step is crucial because email servers often make small, harmless changes to a message as it passes through. These modifications could include wrapping long lines or changing the case of header fields. Without canonicalization, these minor alterations would change the content of the message and cause the digital signature to fail validation, even though the message content is fundamentally the same.
The canonicalization algorithm defined in the c= tag tells the verifying server exactly how to prepare the message before it attempts to check the signature, ensuring both the signing and verifying servers are working from the same playbook.
Canonicalization algorithms: simple vs relaxed
The c= tag specifies two algorithms, one for the header and one for the body, in the format c=<header>/<body>. There are two possible values for each part:
- simple: This algorithm is very strict. The simple header canonicalization tolerates almost no changes to the headers. The simple body canonicalization only allows for the removal of trailing empty lines at the end of the message body. It is brittle and rarely used for headers in modern email.
- relaxed: This is a more tolerant algorithm. The relaxed header canonicalization allows for common modifications like converting header field names to lowercase and folding or unfolding header line whitespace. The relaxed body canonicalization ignores changes in whitespace and blank lines. This makes it much more resilient to changes made by intermediate mail servers.
Therefore, a tag like c=relaxed/relaxed is extremely common. It means that both the header and the body were canonicalized using the more forgiving relaxed algorithm. This is the recommended setting for both ARC and DKIM because it provides the best chance for the signature to survive the journey across the internet.
The connection to DKIM
If this all sounds familiar, it's because it is. ARC did not invent the concept of canonicalization. Instead, it reuses the exact same mechanisms defined in the DKIM (DomainKeys Identified Mail) standard. The ARC specification directly references the DKIM specification for these definitions.
The c= tag in an ARC-Message-Signature is syntactically and functionally identical to the c= tag in a DKIM-Signature. This makes perfect sense, as ARC is designed to preserve DKIM (and SPF) results. By using the same signing and verification logic, ARC ensures consistency and avoids reinventing the wheel.
In summary, the c= tag is a borrowed, yet critical, piece of the ARC puzzle. It defines how a message is normalized before signing, ensuring that the digital signatures that form ARC's chain of custody are robust enough to withstand the rigors of email transport.
