Test failure of ‘chainverify’

[Nikos Mavrogiannopoulos]

Daniel Kahn Gillmor wrote:

>> I do not think
>> that certificates which are directly on the trusted list should be
>> rejected if they are expired or signed with a weak algorithm. There
>> might be a slight argument for the expiry check because the expiration
>> might happen behind the notice of the user who put it to the trusted
>> list and arguably the expiration time signals that the
>> private-key/certificate should not be used after the time.
>
> I think that trusting listed certificates after their internally-stated
> expiry could be a surprising experience for users (in a bad way).
>
> Maybe we need a way for a user to communicate to the library that she
> wants to trust a given certificate beyond its internal expiry?

I've thought of it and the less intruding change that I found, that
could solve this issue, is the introduction of a flag to disable time
checks for the trusted certificate list. Otherwise always check the
trusted list certificates for expiration during verification.
I've committed it with 897cbce62c0263a498088ac3e465aa5f05f8719c.

I thought it was quite important to be included to the release.

> However, ignoring weak digests does not mean we should ignore *all* weak
> algorithm checks for these certificates.  For example, if a 512-bit RSA
> key would not be acceptable elsewhere in the chain, we should not accept
> it in the trusted root list.

This is a different issue. Current we have no such checking...

regards,
Nikos