On Mon, 2005-02-14 at 11:59 -0800, william(at)elan.net wrote:
On Mon, 14 Feb 2005 domainkeys-feedbackbase01(_at_)yahoo(_dot_)com wrote:
If the revocation id is not very cache-friendly, then it could be as
granular
as a message-id.
Message-ID could possibly be passed along as part of lookup for public key
or fingerprint. If key owner does not use revocation, they would provide
longer cache time for the answer, otherwise it would be shorter.
I do not understand this comment about the duration in cache. I think
you have this backwards.
I was not referring to use of the RFC2822 message-ID, but rather a
sequential message-ID generated by the signing SMTP server. This
message-ID would only need to be unique during the period a revocation
may be used. Not including the revocation-identifier should also be an
option.
Copying the RFC2822 message-id into a revocation-identifier field could
have problems not on your list. (Those on your list did not seem to be
major problems however.) One, the size of this RFC2822 message-id could
exceed a valid label. The RFC2822 message-id allows characters not
legal as a domain label. Periods and at symbols would be problematic,
as example. The intent should be to ensure an expedient query, by
constraining the identifier to a single label.
Although this sequential id approach may be allowed for special cases,
the normal approach should be persistent identifiers created from the
authentication process granting access to the server.
-Doug