Closed dirkx closed 3 years ago
Given the rush - I would suggest we say:
I think it is important to state exactly what validation rules must be implemented by the verifier. In this we currently say that all keys in the trusted list may be used, but that key usage may have to be verified. And keep this separate from the key management practices put in place by the issuer of the CSCA/DSC certificates.
An issuer of HCERTs could have a key management practice in place where a new key is introduced for. for example, each quarter, and used to issue HCERT's with a validity period of 3 months. Which means a signing key can be withdrawn 6 months after it has been introduced (3 months after its operational period has ended). This type of key management scheme would make sense if an issuer is not able to use an HSM.
Regardless it seems dangerous to try to indicate what key management practices are in place by using Not valid before/Not valid after in the X.509 certificate. And key management practices may change down the road. But yes, we should give some kind of recommendation on reasonable timings and considerations tied to this that must be made by each issuer.
I agree with @fredriklj - once a key published on the trusted list, verifiers should be allowed to use it to verify signatures. If the trusted list issuer don't want verifiers to use a key, don't put it on the list.
Can you folks Merge and Close this one if you feel this is now well enough described ?
I think this was address in the merging of PR #16 .
We currently say:
We have the worry that MS get this wrong in the tail of the pandemic - and continue issuing right up to the end of the DSC validity.
We can forego all dates in the DSC -- and only look at 'esp' in claim 4.
We could change this to
But this has the risk that implementors get it wrong ? So this is about an ops/governance mistake v.s. a implementor mistake.