On 21/12/10 5:46 AM, [email protected] wrote:
So a co-worker ran into this lately;
libnss, at least on Linux, checks that the signing cert (chain) is valid
at the time of signature - as opposed to present time. (It may check
present time as well - not sure on that).
This makes for problems if you renew the cert, since the new cert will
have a creation date of the current time, after the object was signed.
Can anyone think of why this would be a good thing?
It's because much of the work on digsigs assumed that the reverse
encryption operation in a public-private key pair operation is in some
sense analogous to a human signing operation, as in,
read/intent/understand/bind a human to a claim.
A human signing operation (known technically as manuscript signing)
typically only has a context of value within the time the signature was
made. So the check of any ancillary information is grounded in that
time, establishing that as well as read/intended/understood/bound.
By this, we mean, "sign and *date* the form..."
Where it goes wrong of course is that a digsig is pretty remote from a
human signing, and this flaw has echoed through countless systems to
undermine their capabilities. In some cases to kill them with
implausible demands.
But leaving aside the effect of architectural cancer, if you are going
to build a digital signing application, and use digsigs as some form of
human signing operation, you have to ground the results in the time of
signing. Which means, typically, that any such digital signing has to
preserve the entire chain at the time, as part of the signature, and get
it timestamped in some sense to preserve the moment. Then, later on,
you have to check the chain, as it appeared at that time.
iang
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
