On Thu, 2015-07-23 at 00:29 +0200, Kurt Roeckx wrote: > On Wed, Jul 22, 2015 at 10:34:53PM +0100, David Woodhouse wrote: > > On Wed, 2015-07-22 at 23:29 +0200, Kurt Roeckx wrote: > > > On Wed, Jul 22, 2015 at 09:56:24PM +0100, David Woodhouse wrote: > > > > > > The whole point of this signed timestamp is that the signature > > > doesn't expire and that you don't have to care about the wall > > > clock. > > > > ... which is much more simply achieved by just not caring about the > > validity times of the certificate in the first place. > > In case of a timestamp you can reduce the check to verify that the > timestamp was in the validity period of the certificate.
Yes. You can. But it's still pointless complexity in a use case where *every* valid signature would need a corresponding timestamp to ensure its validity. I can kind of understand why we might want the timestamp scheme in circumstances where *some* signatures should be infinitely valid, and others not. But in the case where *all* signatures should be infinitely valid, it just seems entirely gratuitous. And retrofitting it into a model where the validity is *already* not being checked is a inviting a whole bunch of breakage for precisely zero benefit. -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
