Clarification of Certification Revocation Techniques

#1

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:

  1. 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.

  2. Following from above, this has privacy implications for the recipient of the certificate because a third party is involved in the verification process.

  3. 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

  4. You cannot assume, over a long time, that the issuer will continue to exist, and have in place up to date to CRL

  5. 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?

Using IPFS to reduce Issuer hosted data dependence
#2

Could not each certificate have its own unique revocation address. I know this might be more for the issuer to manage, but in my view, this is preferable to a CRL. As, well, if a revocation key is compromised, it applies only to the certificate, not an entire class of certificates.

#3

Also, if the revocation key is shared between issuer and recipient, either can revoke. There may be an instance where the recipient no longer trusts the issuer and wants the certificate revoked.

#4

Hi Tim,
These are great questions, and this decision was one of the biggest sticking points. This is a good example of discussion that until now has been buried in github issues, so I’m glad you asked here.

Ultimately: CRL is not the Blockcerts revocation technique. This was an intermediate step to move forward with V2 OBI compliance while allowing the Blockcerts standard to make fewer assumptions about implementations (such as choice of blockchain). In OBI, revocation is implemented as a CRL, and this is the option you see here.

The problem with reliance on spent outputs for revocation is:

  • assumes UTXO model (a complication for alternative blockchain models)
  • revocation address key rotation infeasible (described here)
  • cost is proportionate to number of certificates, making this infeasible for very large batches (for more economical issuers)
  • cost of revocation for recipient depends on transaction fees (which have raised dramatically recently) – one option is to pad the recipient outputs to cover this, but this increases the cost even more.

In the past, we’ve considered multisig approaches and others that involve the recipient participating in the transaction, but so far they’ve been infeasible from a usability and (recipient) cost perspective.

Finding a better revocation solution is a primary focus post-v2 (i.e. now). We want a solution that combines:

  • economic for large batches
  • blockchain agnostic: in Ethereum, for example, a more natural solution would be smart contract-based, and would have more natural economic model for revocation. (I.e. the v1.2 Blockcerts model plans for the worst case, in which any one of the certificates in the batch may be revoked. Clearly at some point it makes sense to revoke the whole batch).
  • recipient-centric: the recipient must be able to curate and control the credentials presented. It is not clear yet at which layer this must occur; for example, we are also actively investigating Verifiable Claims/Decentralized ID approaches

On a related note, another problem we are investigating is reducing reliance on issuer-hosted data, and improving longevity and availability. In all versions of Blockcerts, the hosted issuer identification is required for verification. We want to find a way to avoid all such points of failure, and are pursuing a range of solutions, including IPFS/IPNS.

This is very much under investigation now, and any suggestions and collaborations are encouraged.

1 Like
#5

Thanks Kim,

Lots to think about. One of the most attractive aspects of the Blockcerts scheme is the ability to have a singular dependency on a blockchain (Bitcoin blockchain - accessible by everyone, controlled by no one) that you know will still be around after the issuers have long disappeared (including governments). By singular dependency, I mean no dependencies on issuers, CRLs, etc - only the blockchain.

I may be looking at an edge case here, but the scenario I am contemplating, is the ability to verify a certificate, years, maybe decades in the future (and with a local version of the blockchain). The certificate might be in an electronic form, but it could also be in paper form (read in electronically by QR code).

What might be needed is to further abstract revocation in a way that the revocation could be implemented in different ways depending on the backbone used (UTXO, Smart Contracts, CRLs, etc.). Further, revocation could be initiated in different ways - by the issuer, by the recipient, or both (multi-sig). Finally, revocation methods might apply to individual certificates, or to entire batches.

Anyway, I will reflect more on this. Thanks again for the comments.

1 Like
#6

I absolutely agree this is the right approach:

What might be needed is to further abstract revocation in a way that the revocation could be implemented in different ways depending on the backbone used (UTXO, Smart Contracts, CRLs, etc.). Further, revocation could be initiated in different ways - by the issuer, by the recipient, or both (multi-sig). Finally, revocation methods might apply to individual certificates, or to entire batches.

I’m interested to hear your thoughts as you reflect on it. Let me know if you’d like to chat and brainstorm about this at some point.

#7

I think we need to flesh out the process for: 'Check Certificate Revocation" that works for Open-Badges, Bitcoin, Ethereum, HyperLeder, etc -

Also revocation could be triggered either by the Issuer or the Recipient (or both)

Some hokey pseudocode:

BEGIN Check Certificate Revocation

IF (Open-Badges) check CRL END IF
IF (Bitcoin)
– check Issuer Revocation Key (UTXO not spent)
– check Recipient Revocation Key (UTXO not spent)
END IF
IF (Ethereum)
… smart contract stuff
END IF
IF (Hyperledger)
… whatever hyperledger does
END IF

END Check Certificate Revocation

In the end, the Blockcert standard needs to be backbone agnostic. But the use case I am looking for right now is the one that utilizes the Bitcoin blockchain as the one and only dependency for issuance and verification. (no issuer CRLs)

Tim

2 Likes
#8

Hello, Kim,

I am now working on my MSc dissertation and am very interested in contributing to this project. I’m considering focusing on two topics:

  1. Certificate Revocation

Finding a better revocation solution is a primary focus post-v2 (i.e. now). We want a solution that combines:

  • economic for large batches
  • blockchain agnostic: in Ethereum, for example, a more natural solution would be smart contract-based, and would have more natural economic model for revocation. (I.e. the v1.2 Blockcerts model plans for the worst case, in which any one of the certificates in the batch may be revoked. Clearly at some point it makes sense to revoke the whole batch).
  • recipient-centric: the recipient must be able to curate and control the credentials presented. It is not clear yet at which layer this must occur; for example, we are also actively investigating Verifiable Claims/Decentralized ID approaches

  1. Reducing reliance on issuer-hosted data

On a related note, another problem we are investigating is reducing reliance on issuer-hosted data, and improving longevity and availability. In all versions of Blockcerts, the hosted issuer identification is required for verification. We want to find a way to avoid all such points of failure, and are pursuing a range of solutions, including IPFS/IPNS.

Regarding 1), I am aware of the github issue. Is there any other place where this is being discussed?
Regarding 2), is there a place where a discussion is taking place?

At this point in time I am drafting the proposal for what my project will be so I am really interested in understanding the problem and analysing the possible proposed solutions.

Thank you :slight_smile:

– João

#9

Hi João,
It would be great to have you involved. This forum is a great place to have those discussions.

I can start by drafting up some samples (in the coming weeks) and as always, any ideas/suggestions are appreciated.

Thanks,
Kim

#10

Sounds great! :slight_smile:

I have only discovered Blockcerts about 3 days ago (so far I had been focusing on blockchain and reputation systems ), so I’m still speed reading as much as I can in order to better understand the problems and the proposed solutions.
I’ll make sure to stay active in this forum.

Thank you for the quick reply,

– João

#11

Tim – I’m curious if you’ve looked into into decentralized ids (DIDs), in particular methods such as BTCR. Some of the details of how it would work with revocation were in-person discussions at the last Rebooting Web of Trust – I’ll review to see if anything big is missing.

To me, this enables a more natural model for revocation that is transaction based, but avoids the pitfalls of the v1 approach. In particular for Bitcoin, it could avoid the worst case (i.e. large number of tied-up UTXOs allowing revocation of any single certificate in the batch).

  • Kim
#12

Hi João,

Could you tell a little bit more about your research project? I am working in an MSc dissertation too with topic about blockchain and reputation systems, so maybe we can share some knowledge!

cheers,
Daniel

#13

Hi Kim,

I am familiar with DIDs but I have to reflect a little bit more on how this might relate to the issuance/control/revocation of certificates.

I believe there is an opportunity to explore a generalized issuance/control/revocation model.

In particular revocation
Revoked by Issuer
Revoked by Recipient
Revoked by Authorized Third Party
Any combo of the above (multi signature)

We also might need to explore an active/inactive state. That is, a certificate is issued/valid, but cannot be used once activated by the certificate. This is similar to having a valid credit card issued, but it cannot be used until it is activated by the user. Furthermore, there might be a requirement where a recipient might be able to ‘freeze’ a certificate for a period of time.

Anyway, lots to think about.

Tim

1 Like
#14

Hello, Daniel,

I started out as looking at how to improve current reputation systems by leveraging blockchain technology, more specifically Ethereum smart-contracts.
During my research I came across Open Badges and saw there an amazing oportunity for a blockchain application. I researched a little about it and found Blockcerts.
So my project is going to be a contribution for this platform. It’ll most likely be related to the issues regarding Certificare Revocation, as discussed by @kim and @Tim as well using a decentralised storage system to store all the data that is currently hosted by the Issuers.

#15

Hello Daniel, João, others,

Awesome to see there are others actively working on these issues/research topics. I am also in the process of writing my MSc dissertation, and stumbled upon the efforts by blockcerts today. The specific topic I’m most interested in is how to validate the improvement this technology offers in practice. In other words: is it (potentially) cost effective to use such a system for employers.
However, before today, I had expected to need to build the full system myself from scratch, so the thesis would consist mostly of the design process.

Your work will in the very least provide with pointers, but in the coming days/weeks I will look into contributing to the project directly.

My unfinished, unpolished design idea before reading the blockcerts design was to have issuers transact a certificate hash through an Ethereum smart contract. The public address of the sender can then also be a resolved .eth domain. Revoking/accounting for confiscation or loss of private keys and even the other contents of the smart contract were still open issues in my brain. (so sorry for going a bit off topic)

If Ethereum tackles zero-knowledge proof in some way, (zkSNARK’s or other methods) it would be a great improvement to privacy for certificate recipients as opposed to the openness of the current ethereum/bitcoin transactions (although hashed). I have an idea about improving privacy even more after implementation of zero-knowledge proof, but perhaps that’s better for an other day/topic.

Anyways, would love to brainstorm/contribute either here or via any other way.

2 Likes