Summary:
x= is needed to offer a major DKIM verifier optimization to
address expiring or revoked keys.
Background:
Overall we have this basic key rollover, revocation and removal time model
such as:
DAY T1 : First day mail is signed with KEY1
DAY T2 Last day mail is signed with KEY1, and
first day mail is signed with KEY2
DAY X1 : KEY1 is revoked (p= is empty)
DAY Y1 : KEY1 domain selector is removed from DNS.
Based on this, we can defined what "x=" means by what it COULD be:
- x=T2
The time that the signature may verify but no longer consider
valid? Currently, per specs, T2 is X1-7.
- x=X1
The time that the signature will no longer verify because it
was revoked (p= set to empty).
- x=Y1
The time that the selector itself is removed from DNS.
The main difference?
In the first two cases, a DNS query is successful and in the last case,
we have NXDOMAIN result.
This NXDOMAIN result is a major protocol DNS consideration for the verifiers
as well as for the wide-scale adoption network considerations.
Regardless of the true intent of the signer, avoiding DNS lookups, when
possible, is an important consideration that should not be ignored.
The preference would be for the responsible key domain to provide
information to fail a transaction without looking up this selector.
I understand that we still have the issue of the time-shifted applications.
I don't think much can be done about this to solve the issue 100% but
signers can do wonders to reduce the problem.
From a key management standpoint, I think x= includes the representation and
sum of two times:
x = f(R1 + R2)
where
R1 = X1-T2
Key retention time before key is revoked
R2 = Y1-X1
Revoked key selector domain DNS retention time.
R1 and R2 is based on the domain's key management/rotation policy, if
any, that has only meaning to the signer.
The point of all this is that from a signer standpoint, it helps to
have a model for rollover and rotations that will help domains decide how to
best manage keys to provide enough retention time for verifiers, including
MUAs.
But from an verifier standpoint, regardless of the domain key policy, if a
x=tag is not provided in the signature, the verifier is left with an high
overhead situation where the only way to determine if a key is valid or not
is by performing the lookup. I don't think this would be desirable in a
wide-scale DKIM network.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html