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 <[EMAIL PROTECTED]> http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD. _______________________________________________ ietf-dkim mailing list [email protected] http://mipassoc.org/mailman/listinfo/ietf-dkim
