Eliot,
Thanks for this. It helps. It highlights that meaning, usefulness,
heuristics, etc, all depends on the disciplines and roles. We have
security, network, application developers, protocol developers, support
people, managers, QA people and possibly even users, each with there own
(and correct in their right) ideas.
What I am commenting on is that there is a natural protocol here that we
need to work out that needs to fit with the current infrastructure.
Specifically, if expiration is a natural part or security consideration of
the technology being explored, removing it for consideration probably isn't
a good idea.
If the semantics is the problem, then lets fix the semantics.
I think the questions that need to be ask is:
a) Is Expiration applied to key validity?
b) Is Expiration applied to transient only time verification?
c) Is Expiration applied to Message "Death-Dates"?
The information note should be, in my opinion, is that it shouldn't matter
once the message has been received *by* the user. This is consistent with
Dave's "Car in the Intersection - Light Turning Red" metaphor.
I also think, as my proposal highlights, there are two cases here:
- Expired Valid Signature
- Expired Bad Signature
The current semantics excludes the validity of the signature and probably
this is because the semantic is associated with option (a) above.
---
Hector
----- Original Message -----
From: "Eliot Lear" <lear(_at_)cisco(_dot_)com>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
Cc: "Mark Delany" <MarkD+dkim(_at_)yahoo-inc(_dot_)com>;
<ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Wednesday, April 12, 2006 7:27 AM
Subject: Why I think there's something wrong with Expiration
Hector,
Thanks for your note. Please see below.
By the way, I am curious. I am wondering why is there is a resistance
to a
expiration concept? Isn't expiration an inherent attribute in security
and
in a crypto key concept?
Yes, it is. However, such expiration is usually associated with a key
as part of a certificate for purposes of truncating revocation lists or
otherwise limiting the damage that could be caused due to lost or stolen
private keys. Under the cryptographic systems I understand a signature
will verify as valid so long as the input was signed prior to a key's
expiration. Put another way, you normally can validate a signature long
after the key used to generate it has expired, so long as the key was
valid when the signature was made.
The problem here is that we are associating the expiration time with a
message that is signed with such a key, and not the key itself. And so
the semantics are different. x= says that the verifier should not try
to retrieve a key from DNS past a certain date. If the purpose is to
simply not have the message validate at all at some period of time, that
is fine but that should be documented clearly (and further justified
IMHO).
Eliot
ps: thanks to Landon Noll for providing me some guidance on the nature
of cryptographic signatures.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html