Re: Scope for self-destructing email?

[Ted Hardie <[e-mail]>]

On Tue, Aug 15, 2017 at 9:50 PM, vaibhav singh <[e-mail]>
wrote:

>
> 4.) A really boiled down version of ephemeral mails could just mark the
> mail "outdated" if the information provided in the mail is not expected to
> hold good after some time, instead of actually expunging the mail.
>
>
>
> *why not try to accommodate both realitys and define a feature which is
> called "Invalidation of Messages" or similar instead of "Destructible
> Messages". The goal of this feature should be to mark messages in a way,
> that the client somehow can mark the message as "not being relevant
> anymore" or something like that. So it could still be displayed but grayed
> out for example telling the receiver that the message can be ignored.
> Additionally there could then be added an attribute "deletionrequest" which
> can be set for clients which really want to have destructible messages like
> Signal does.*
>
> Any thoughts?
>
>
I think there are two potential lines of development here, though I confess
I am skeptical of the value of either.

The first is providing a facility that declares a particular message to be
automatically overcome by events at a particular time, leaving it
completely up to the recipient how to process the message based on that
metadata.  There are simple message types (today's weather, lunch
availability, etc.) that could be thus set to be marked OBE when no longer
relevant.  Some clients might choose to auto-delete them or auto-archive
them when the time is reached, but this would be because of their preferred
handling and not a guarantee to the sender that the sender's intent is
being honored.  A message header like OBE-At: could be registered
provisionally without much hassle, and you could see if it saw
implementation and use.

The second is a trickier question:  is it possible to construct a message
such that it is cryptographically non-repudiable within a set time frame
but repudiable thereafter?  I think the answer to this is yes, but it
relies on a carefully crafted interaction among the use of limited validity
certificates, requirements to confirm validity with a CA, and CA behavior.
You could deploy that in a limited environment, in other words, and see if
it was useful enough to make the behavior standard.  It's less clear to me,
though, why it would be useful.  The one scenario I can construct is
financial, as part of the flow for placing a time limited order, but the
flow seems strictly worse that a simpler flow that includes the time limit
for the order within a message which is permanently non-repudiable.

regards,

Ted