StephenCleary
commented
7 years ago The new revocation system creates a hard dependency on the issuer's website. Currently, with all revocation part of the chain itself, the only issuer verification necessary is a matching of the issuer address with their identity. So, it becomes possible (in theory) for issued certificates to always be valid, without the need to talk to the issuer directly - as long as the validator is willing to accept that the issuer's address does represent a particular issuer identity.
With the issuer-hosted revocation model, any issuer-related service problems would "invalidate" all certificates:
- Going out of business
- Changing (domain) names
- Discontinuing the use of blockchain certificates and reclaiming those server resources
Even temporary interruptions - like an improperly configured new proxy - could cause cert validation to fail until it's brought to their attention.
I'm not saying revocation lists are the wrong direction; just pointing out that it is exchanging one set of problems for another. With the new revocation scheme, we're taking a step away from the blockchain and a step towards something more like PKI, where every issuer is a CA.
kimdhamilton
Velofisch
Revocation Improvements
TL;DR: Jump to the end if you are interested in just the v2 changes
Goals
Non-goals
Current revocation technique
There is a practical complication with the current revocation technique of spending outputs: once a revocation key is rotated, it can never be used to revoke a certificate.
This first explores with the issuer global revocation address.
Context
The issuer's global revocation address is the revocation address listed in the Issuer Identification endpoint. When issuing Blockchain Certificates, the transaction includes an output to this address; spending this address revokes the entire batch.
The current verification standard assumes 1 active global revocation address. Previous revocation addresses are associated with an
invaliddate.What happens if the private key is leaked
Suppose the private key corresponding to the issuer's global revocation address is leaked. This allows an attacker to revoke any certificate batches associated with that revocation address.
Since the revocation event is timestamped with the blockchain transaction, this timestamp, along with the Issuer Identification timestamps, could be used to effectively discard (by convention) the revocation event. However, there are practical concerns with that; consider all options:
Furthermore, given the current verification standard, only 1 revocation address is effectively active at a given time. This means that the issuer must reissue certificates ever issued (if they want to retain the ability to revoke in the future).
One (discarded) option was to allow multiple active revocation keys, and rotate them frequently on a planned basis. However, this complicates the revocation convention even more, as all revocation keys the issuer even used must be considered during verification.
Similar reasoning applies to per-recipient revocation. And in fact, it's messier since the per-recipient revocation addresses would not have a natural timestamp for comparison.
Why the existing revocation technique was chosen
The current revocation technique of spending outputs is symmetric in the sense that either the issuer or the recipient can revoke a certificate. This characteristic strikes many as unintuitive; there is no analog for recipient revocation in well-known credentialing systems.
In fact, this has been the most debated aspect of the design, because it additionally introduces the following consequences:
Let's unpack the recipient revocation scenario. Blockchain certificate transactions are structured as follows:
input:
output:
The original concern is that, since the addresses are part of the public ledger, a bad actor could also issue a certificate to the recipient's address (discovered either because the recipient attached the address to an identity, or through graph analysis), which the recipient would want to disavow. This is a theoretical concern, but a primary design principle of Blockchain Certificates is recipient control.
Alternative transaction structure
input:
output:
By removing the recipient address and revocation addresses from the transaction, a recipient can still prove ownership of the address, as long as the address is in the certificate, which is hashed and placed on the blockchain.
This means the recipient address is not part of the public ledger. But the recipient can disclose the contents and prove ownership of the address by signing a message.
This has additional benefits:
Impact on recipient revocation
While this removes the ability for a recipient to explicitly revoke a certificate, the following mitigations are available:
Revocation in the next version
In the next version of the schema, the revocation technique will be explicit so it may vary during the Blockcerts verification process. For example, revocation could be published as a list in IPNS, implemented as a smart contract in Ethereum, or published in a issuer-hosted revocation list, as used in the OBI standard.
For now, the default implementation will use an (URI) issuer-hosted revocation list, for practical concerns (and given that Blockcerts uses the Bitcoin blockchain).
The OBI schema has a
revocationListfield, which will be used to store this URI.Details of impact to schema are provided in #23 and #28.