Douglas Otis wrote:
A technique based upon the current widespread practice of blackhole
listing would allow rapid revocations to occur, while still allowing a
common signature. The provider would not need to do anything, but they
could publish this information themselves, as the authoritative, least
expensive, and hopefully the fastest method to distribute this
information.
The information could take the form:
<opaque-identifier>._rl.<signature-domain>
or
<opaque-identifier>._rl.<signature-domain>.<third-party-domain>
One problem I see is that the verifier of a signature needs to make this
additional DNS request, which does not have very good cacheing
properties (since the opaque-identifier would typically allocated per
user address), before considering a signature to be valid.
Another way to approach this is to just allocate more keys. There is an
expense there, too, due to the volume of data in DNS and the poorer
cacheing of the keys.
I think it just comes down to an optimization problem: is it better to:
(1) Support fewer keys and revocation lists, with the need for a
verifier to make two DNS queries
(2) Support more keys (for domains that need it) and no revocation
lists, with only one DNS query but a larger volume of data in DNS
(because a key retrieval would be larger than a revocation result)
Would a DNS record be published for each unique identifier or would the
lack of a response indicate the authorization hasn't been revoked?
It's important that we not burden domains that won't have a significant
replay problem (small, well-controlled domains, for example) in order to
deal with this problem. So it needs to be possible for the
opaque-identifier to be at a coarser granularity than individual
addresses. But the second DNS query still bothers me.
-Jim