On Tue, 9 Aug 2005, Eric Allman wrote:
It seems like the obvious place to store revocation information is in DNS (so
that you don't start having to add additional ports, which is a problem from a
firewall perspective). If you don't store the revocation ids in DNS then you
have substantially raised the bar for using DKIM. But if you do store them in
DNS, aren't you actually trashing DNS in exactly the same way as with per-user
keys?
I'll just state my understanding of Doug's suggestion in a briefer form:
The advantage of fine-grained revocation IDs over fine-grained keys is
that a negative cache entry is much smaller than a key. Revocation IDs
only have a DNS entry when they have been revoked, which should be rare.
Key IDs will usually have a relatively large DNS entry.
Doug also suggests an optimisation based on when you could reasonably
expect that checking for revocation would be unnecessary: if the message
came directly from the signing domain (which you could detect using CSA,
and which is the common case) you can skip the revocation check because
it's unlikely that a message would be signed then revoked before it even
travelled one hop.
Tony.
--
f.a.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.
_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim