On Sun, 2005-03-06 at 09:42 -0800, william(at)elan.net wrote:
If you're seriously considering revocation, then please make it optional,
i.e. it is used ONLY IF revocation tag is present in the signature header
and that tag value is then revocation id, which format is not specified
and depending on what is preferred the signing system can use sha1(userid)
or sha1(messageid) or whatever else naming system works for them.
I agree this should be made optional to avoid overhead that would be of
little value, as within small secure communities without a history of
trouble. Should there be trouble detected, switching over to using a
revocation-identifier should not be as difficult as adding per-user
A requirement that the opaque identifier represents only a single domain
label would keep this mechanism simple. Allowing use of multiple labels
could provide an administrative advantage by being able to kill a single
message rather than a whole account, as Phillip suggests. The selector
could be included within this path as well to allow immediate reuse of
account numbers, as example. An opaque identifier definition would
allow greater complexity without constraints. In an effort to ensure
simplicity, one or two labels could be a limit. This is a trade-off.
There is another cost savings, by authenticating the HELO and finding
that it is within the signature domain, a revocation record check could
be skipped. Even when everyone published revocation-identifiers, the
traffic should remain small by being generated when the message is being
forwarded or sent unaltered from a list server.