Cryptography implementation in Revocation

[joaosantos15]

This is a summary of a recent discussion I had with prof. Nuno Santos regarding revocation. In the current implementation of the revocation application, revocation proofs are nothing but a string that says issuer_key or receiver_key (mocking issuer and receiver digital signatures, respectively) and the revocation rules file simply lists what strings should exist in the revocation proofs to determine that a certificate is revoked. For instance, for the following certificate_revocation_rules.json file with the content

{ "revocation_rules":["issuer_key","receiver_key"] }

the required certificate_revocation_proofs.json file should contain

{ "proofs":[ "issuer_key","receiver_key" ] }

for that certificate to be revoked. What the Verify function does is essentially make sure that all the items incertificate_revocation_rules.json are in certificate_revocation_proofs.json.

Obviously this is an over simplification made to expedite the prototype creation. This issue was created to discuss how the revocation should be implemented.

[joaosantos15]

@nuno-santos fica aqui a referência que tinha pedido sobre DIDs (distributed identifiers), na semana passada. ;) Está conciso, mas explica muito bem o conceito, entrando em alguns detalhes de implementação. Worth the read. https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/topics-and-advance-readings/did-primer.md

[joaosantos15]

Since we're moving towards a different model of revocation, it does not make sense to keep this issue. Closing.