zigbee-alliance/distributed-compliance-ledger

DA PKI Revocation: Design

ashcherbakov opened this issue · 1 comments

ashcherbakov commented

User stories:

  • Revocation of PAI (by proof of key possession): Member who can prove ownership of PAA private key can submit a transaction to publish the location of the CRL distribution point for that PAA. This information can be updated by the member using the same proof.
  • Revocation of a DAC (by proof of key possession): Member who can prove ownership of PAI private key can submit a transaction to publish the location of the CRL distribution point for that PAI. This information can be updated by the member using the same proof.
  • Revocation of PAI (by Trustees): A Trustee can propose a transaction to publish the location of the CRL distribution point for a PAA. This SHALL require approval of two thirds of the trustees vote.
  • Revocation of DAC (by Trustees): A Trustee can propose a transaction to publish the location of the CRL distribution point for a PAI. This SHALL require approval of two thirds of the trustees vote.

Notes:

  • PAA = Root certificate
  • PAI = Intermediate certificate
  • DAC = Leaf certificate
  • CRL = Certificate Revocation List

Acceptance criteria:
Create a design doc that addresses the following:

  • Design the API, model and state (key-value)
  • Design Auth rules
  • Consider a model from https://csamembers.slack.com/archives/C025PQ6RMRA/p1678980910132059
  • Think if subject is needed (we use subject for all certificate models, but the proposal above has only subjectKeyID)
  • Think if we need to validate vid field somehow
  • Think what GET (Read) API we need. Think if we need some additional indices in the state for this.
  • Think if existing models/states need to be adjusted. Think if we need to update existing entires in the Main Net (and hence migration of data is needed).
  • If migration of data is needed, think how it should be done via standard Cosmos/cosmovisor/upgrade module means.
  • How this new functionality should affect existing certificate "revocation" logic of DCL. For example, if a certificate is revoked (by the current DCL means), should the corresponding CRL endpoints be removed?
  • Think how to properly do "proof of possession" stories. Usually some "nonce" needs to be used to avoid replay attacks, so the DCL API needs to designed correspondingly (DCL: generate nonce -> User: sign nonce by the key -> DCL: verify signature)
  • Consider reading the RFC 5280 CRL spec: https://www.ietf.org/rfc/rfc5280.txt