This is actually a repost of an idea I sent out earlier but I have since
refined and revised it.
I believe that it is possible to support per user and per message
revocation without making any changes to the existing protocol.
The first observation I make is that there is an important distinction
between KEY revocation and SELECTOR revocation. It is quite possible for
a sender to create individual key selectors for every one of their users
that all contain the same key value. I suggest that people avoid the
term 'key revocation' as it is misleading.
The second observation is that hierarchical selectors allow wildcards to
be used to specify the default key record. It is only necessary to
insert entries for revoked keys.
Let us imagine that example.com is a huge Isp with 10 million users, it
creates a selector hierarchy as follows:
{message}.{user}.{key}._domainkey.example.com
It starts off by populating the key values as wildcards:
*.keya._domainkey.example.com TXT "v=aaaaaaaa"
*.keyb._domainkey.example.com TXT "v=bbbbbbbb"
etc
Each key is used for a large number of users but each user and each
message has a unique selector:
{user} = HMAC (username, secret)
{message} = HMAC (messageid, secret)
A person skilled in the art will note that some portion of the message
itself or a hash of it can be used as an alternative means of generating
the selector.
This scheme allows the sender to revoke a single message or every
message sent by a user by defining the appropriate records.
User revocation:
*.xxxxxx.keya._domainkey.example.com TXT "v=NUL
status=revoked"
Message revocation:
yyyyy.xxxxxx.keya._domainkey.example.com TXT "v=NUL
status=revoked"
This mechanism does not require an excessive number of public key
entries. It does enforce a per message lookup but that is inevitable in
a scheme of this type.
It is not necessary for the mail servers to use a common key or maintain
any additional state to implement this scheme.
There is a caching implication here of course, but we are talking about
wildcard lookups here and DNS is already designed to deal with them and
avoid bad caching.
_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim