Replace recommended lifetime of client cert with period of 30 years

[JamesGibo]

Remove the current recommended lifetime of 99991231235959Z with a with a minimum of 30 years. This is due to issue with generating CA's, intermediates and clients certs with the a notAfter date of 99991231235959Z and lifetime of products unlikely to be over 30 years.

Highlights that the Client certificate's chain of trust must also be valid for the lifetime of the certificate for the chain to valid.

Makes it clear that EST must check revocation status of TLS Client Certificates.

Closes #6

[JamesGibo]

If the devices and EST server may be in an air-gapped network, can we require the revocation check?

Maybe the wording needs to change slighty, there still needs to be a process to prevent an EST Server from trusting a compromised Manufacturer certificate even in an air-gapped network, that could be removing the Root CA for that manufacturer, but if it is only one certificate that has been compromised that seems excessive.

Would changing MUST to a SHOULD be better here or as it does not specify the mechanism (CRL, OCSP , ACL) the revocation checking can be changed depending on the use case? "The EST Server MUST check the validity of the EST Client's TLS Certificate before responding to its request, including checking the TLS certificate's revocation status."

[prince-chrismc]

To follow up on Jame's comment

Would changing MUST to a SHOULD be better here or as it does not specify the mechanism (CRL, OCSP , ACL) the revocation checking can be changed depending on the use case?

In the draft we currently have https://github.com/AMWA-TV/nmos-certificate-provisioning/blob/v1.0-dev/docs/1.0.%20Certificate%20Provisioning.md#est-client-1

It is RECOMMENDED that manufacturers maintain a public Certificate Revocation List (CRL) and OCSP server.

If there's an ambiguity perhaps we could say "MUST check where applicable"?