Getting back to the original question, why reject a signature because it
claims to be signed in the future in the first place?
One of the things that held back use of S/MIME was idiot MUAs which would
shout WARNING THIS MESSAGE IS DIGITALLY SIGNED. Use of TLS with self signed
certificates resulted in warnings when visiting sites without TLS did not.
It is highly unlikely that the time value in the document is relevant at
all. So forget 5 minute windows. Applications SHOULD NOT reject messages
unless they have a really good reason.
The fact that a document is signed tells us nothing about the truth value
of the claims made inside the document. So while I have a really hard time
believing that the purported time stamp value actually matters, it is in
any case the wrong technology to use in the case that it actually does.
The only circumstances where a signing time is likely to matter in a
protocol is when it is necessary to determine whether event A happened
before or after event B. And for the reasons outlined by Jon, the only tool
that is going to be able to provide that assurance reliably is some form of
notary agent. There is no a priori ordering of events. It is always
necessary to specify the frame of reference.
OpenPGP provides a cryptographic message syntax. It is not designed to
provide a security assertion capability. If people want that capability,
they should use SAML (or something like it) which was built on a framework
originally designed to support transactional applications. That is what the
conditions and advice slots were originally designed to support in the TAXI
(Trust Assertion XML Infrastructure) scheme.
So just stop checking the timestamps at all. Best case is it provides no
value.
On Mon, Nov 18, 2019 at 4:50 AM Benjamin Kaduk <kaduk(_at_)mit(_dot_)edu> wrote:
On Sat, Nov 16, 2019 at 03:06:13PM -0800, Jon Callas wrote:
In the general case, you can't consider a time measurement to be a
scalar, it has to be at the very least a complex number of the form [time,
skew]. As Derek noted, Kerberos used a skew of five minutes. While Neal
Walfield noted in his original post that he's seen skew of 20min, I concur
that that seems a bit long. My naive home set-up commonly has alarms across
devices being ±2s or less, but that's because they're all getting time from
some combination of NTP and cellular network time, which is ultimately GPS
time (and of course, skew). I think five minutes is likely reasonable, but
*some* skew is unavoidable. Moreover, anyone who's on satellite networks is
seeing latency of over a second and once you throw in normal exponential
backoff, five minutes seems about as short as is reasonable.
I believe that if Kerberos was starting over now, the 5 minutes would be
seen as excessively long, FWIW.
-Ben
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp