ietf-mailsig
[Top] [All Lists]

Re: Good as the enemy of OK

2005-01-12 15:52:52

On Wed, 2005-01-12 at 15:41 -0500, John R Levine wrote:
Do you think closing the account is enough or should there be a means
within the signature mechanism to invalidate known bad accounts/messages
within a time period shorter than a week?

I don't think much of revocation lists; how many does your web browser
check?

Unlike a Digital Certificate that may have a long life span, these keys
should be relatively short lived, such that a list of bad accounts
should be brief.  Adding this query would allow a means to revoke
authorization and thus employ a much smaller amount of additional data.

Domain Keys permits an arbitrary number of keys per domain, anywhere from
a single permanent key per domain to (probably needing a custom DNS
server) a key per message.  My guess is that domains who have enough
misbehaving users to need to cancel keys for individual users or messages
have bigger problems than key revocation will solve, so I don't see that
as an important criterion for a mailsig scheme.

The selector mechanism in DK could allow each user to have an individual
key, although done at this scale, fingerprints look better.  Each user
would then require a "set" of individual keys within the DNS structure.
The normal use of the selector mechanism offers a means to transition
key sets.  Using the 768 bit example, each user would consume about 340
bytes of data.  Practical aspects of administrating this amount of data
via DNS would tend to constrain the number of users such a scheme could
support and represents a sizeable growth in the amount of data
exchanged.

Mechanical schemes for canceling keys checked "too many" times are
unlikely to work unless your key checker has an oracle to tell it which
senders and recipients are mailing lists or distribution lists or
remailers to lists.

This check would be done commensurate with obtaining a public key.
Large sites with potential account problems could flag within their
headers the availability of this feature.  A lack or presents of an
account revocation record (A 127.0.0.1) would be much smaller than
offering unique keys per user and should help thwart an obvious spam
technique.

Surely this approach would do better than attempting to send individual
keys for these situations?

-Doug







<Prev in Thread] Current Thread [Next in Thread>