Certificate Revocation List

[szerge]

Great work, yet I was surprised to read that you planned to use Certificate Revocation List, while other technologies, fully in line with distributed ledger technologies like https://guardtime.com/blt-technology are available and offer "Simplified revocation management : In BLT, signing key status is checked at the signature issuance, and then the signature is sealed using KSI. There’s no need to find and check a Certificate Revocation List (CRL) when verifying the signature in the future."

CRL are a potential weak point if they are not systematically enforced. Using something like BLT would remove that weak point.

Is it something that you might want to add to your roadmap?

[tuand27613]

@binhn @elli @adecaro

[ghaskins]

While I am not familiar with the BLT technology cited above, I do echo a similar concern with the choice of CRLs if there are still talks of using them in OBC. CRLs and CAs, IMO, are actually a poor choice in the permissioned ledger space. CAs are designed to be an extrinsic, one step removed identity provider, and CRLs are a blacklisting mechanism. The problem with blacklists (distribution, omission, etc) are well known, but I would summarize the concern with the CA/CRL mechanism as one that has limited upside (an accurate opt-out list) and unlimited downside (the CA is free to create as many implicitly whitelisted identities as it wants as long as they aren't already on the blacklist or expired). I would argue that permissioned ledgers would be most appropriately governed by an intrinsic whitelist mechanism rather than an extrinsic blacklist, ideally with the whitelist managed right on the chain and agreed upon via consensus. To this point, throw out the CA and the CRLs. x509s themselves are still fine, but just self-sign them and use them as a convenient identity container. The self-signed x509 itself becomes "the identity", and existing tools exist to create/process them. The whitelist is then simply the list of x509s (or, more appropriately, a list of hashes of the x509). There is a prototype of this design baked into this POC: https://github.com/ghaskins/go-cluster

[jvsteiner]

Hi, Jamie Steiner from Guardtime here. Indeed, BLT is designed to solve this exact problem. BLT signatures are server assisted. During this process, the public key is verified to be valid/not revoked, and the signature is only created if the key is valid. The signature is linked to the KSI blockchain, proving the time of signing. Since it is impossible to make a signature with a revoked key, the need for a CRL is removed. If the signature verifies, it is valid. I'd be happy to provide additional detail on how this works, and Guardtime would be interested in providing access to KSI to support an integration into this project.