I am looking at the revised verification process at http://www.blockcerts.org/guide/verification-process.html
I have some concerns and clarifications:
First, a certificate revocation list (CRL) introduces a direct dependency on the issuer. The verification process requires a query back to the certificate issuer to determine if the certificate is revoked or not. This raises several issues:
The issuer or the holder of the CRL now has knowledge on how the certificate is being used as it must be checked backed at the issuer during the verification process.
Following from above, this has privacy implications for the recipient of the certificate because a third party is involved in the verification process.
The CRL contains other revoked certificates, and reasons for revocation. Even though the identity the certificate recipients are not apparent, this is information still can be considered as personal information and therefore has privacy implications
You cannot assume, over a long time, that the issuer will continue to exist, and have in place up to date to CRL
You cannot assume that the issuer will have an available endpoint for verification
I believe that what is what is particularly attractive with Blockcerts, it is singular dependency on blockchain for all states of the certificate, including revocation (which uses the UTXO of the certificate to determine if revoked or not ). The use of a CRL process reduces this attractiveness.
As I may have mentioned before , we are contemplating use cases, where verification is required when there is limited or no network connectivity (just a local copy of the blockchain is downloaded for verification purposes). Checking CRLs from issues will not be possible.
Can you confirm the revocation and verification process in V2?