check crl/ocsp against *now* by default instead of context.moment

[kak-bo-che]

• adjust moment date for revocation checks
• handle unauthorized ocsp response
• optionally check for csrl/ocsp next_update
• Added failure fields to SoftFailError
• Added Tests related to CRL check and nextUpdate missing @wbond this is a new PR based on a previous one, that is cleaner to see what is going on.

[codecov[bot]]

Codecov Report

Merging #7 into master will increase coverage by 1.05%. The diff coverage is 92.18%.

@@            Coverage Diff             @@
##           master       #7      +/-   ##
==========================================
+ Coverage   81.46%   82.52%   +1.05%     
==========================================
  Files          12       12              
  Lines        1430     1465      +35     
==========================================
+ Hits         1165     1209      +44     
+ Misses        265      256       -9

Impacted Files	Coverage Δ
certvalidator/errors.py	100% <100%> (ø)	:arrow_up:
certvalidator/ocsp_client.py	76.08% <50%> (-1.19%)	:arrow_down:
certvalidator/context.py	79.22% <89.47%> (+3.96%)	:arrow_up:
certvalidator/validate.py	87.08% <95.12%> (+0.32%)	:arrow_up:
certvalidator/crl_client.py	59.61% <0%> (+9.61%)	:arrow_up:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 4383a4b...f5754c2. Read the comment docs.

[pkill37]

I think this might be a fix for my issue in #9. Can we merge this @wbond?

[mttcpr]

If I'm reading your changes correctly, you've created a validation mode that isn't described in the standards. Point in time validation requires valid revocation data from that point in time, not some future time where the revocation status may have changed. The obvious case is where a certificate in the path expired and the revocation entry was removed from the CRL. A less obvious case is the signer could have been on hold at the time of signing and subsequently removed from hold. My take is if you are generating signatures that need to be point in time validated in the future, those signatures should carry the revocation data with them. Acrobat is an example of an app that does this.

[kak-bo-che]

@mttcpr The target application for my point in time validation is Microsoft Authenticode. Which is essentially a CMS/PKCS#7 validation with a counter signing signature. The counter signature establishes the point in time which the file signature was known to be valid and the signing chain was within its period of validity. Certificate revocation is therefore checked years after the certificate itself has expired, due to the counter signature. This situation does occur when for instance the private key was stolen.

[stevemk14ebr]

+1 please revisit this

[wbond]

Unfortunately I don't currently have the bandwidth to work on this package.

[stevemk14ebr]

would you be able/willing to assign a new maintainer so that these PRs can be closed?

[wbond]

Not at this point - no one has shown an understanding of the topic and/or codebase. No one has ever submitted more than one PR.

You are certainly welcome to fork, rename and distribute as you see fit, as long as you respect the license.