[cryptography] validating SSL cert chains & timestamps

Ian G iang at iang.org
Mon Dec 20 13:58:01 EST 2010

On 21/12/10 5:46 AM, travis+ml-rbcryptography at subspacefield.org 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.


More information about the cryptography mailing list