Details

    • Type: Epic
    • Status: Open
    • Priority: Critical
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Epic Name:
      Revocation of Throwaway Certificates

      Description

      We require a method with which to be able to revoke throwaway certificates. 

      Basic Customer Requirements:

      • Throwaway CA certificates must be available for revocation checking by OCSP and CRL.
      • The certificateProfileId that was originally used to issue the throw away certificate must propagate to VAs.
      • Async replication between sites uses "last write wins" and running active-active on CertificateData used by other projects imposes a too great risk.
      • CertificateData.rowProtection is not used on VAs
      • No requirement to store actual X.509 certificate in database.
      • Need to supply meta data (at least certificateProfileId for now)

      PrimeKey's Requirements:

      • Reusable long term solution for running active-active over async replication when customers prioritize availability over perfect consistency at each point in time.
      • Safe changes that
        • will not impact performance of existing installations.
        • are easy to test and maintain

      Suggested Implementation:

      New append-only table NoConflictCertificateData that is a clone of CertificateData with a new primary key column.

       Per CA configuration (on the CA cluster):

      • which table should be used (CertificateData | NoConflictCertificateData) [feature scope: only make available for throw-away-CAs for now]
      • accept revocations for non-existing entries in XCertificateData (true|false)
      • if accept revocations for non-existing entries enabled: certificateProfileId to assign to revocations when there is no XCertificateData entry (interger:drop down selection of existing CP name) [skip this if this is supplied in new WS call]

      Internal CRUD logic for NoConflictCertificateData will deliver a regular CertificateData/CertificateDataWrapper object to upper layers based on all currently available information. Best available information should always be used for each column. It should for example be sufficient to append b64Certificate, subjectDn and subjectAltName once to limit used storage space. Revocations status should be derived using the latest available status or the first permanent revocation

      Publishing certificates from PublishQueueServiceWorker will check CA configuration and retrieve CertificateData/CertificateDataWrapper from matching CRUD logic. Publishing will still be made to the VA's main CertificateData table (and VA will still use regular CertificateData table for lookups.) Publishing of CertificateData created from a limited "limited" CertificateData/NoConflictCertificateData must be verified.

      CRL generation will check CA configuration and retrieve Collections<RevokedCertInfo> from matching CRUD logic. CRL generation needs to be able to handle creation of CRLs based on RevokedInfo based on "limited" CertificateData/NoConflictCertificateData.

      Previous EJBCA WS revokeCert call will check CA configuration and allow creation of "limited" CertifiateData entry in the configured CertificateData or NoConflictCertificateData table enriched with CA configured certificateProfileId and the expireDate (based on CP configuration like validity or keep revocations forever on CRLs). 

      New EJBCA WS revokeCert call as above, but also supplies additional meta data (in a format that can handle additional fields in the future). CertificateProfileId should be accepted in the first version of this implementation.

      Additional Clarifications and Scope:

      • OCSP service of CA cluster will not take existence of NoConflictCertificateData into account. (Could be implemented in the future.)
      • Searching for certificates in RA GUI using new table. (Could be implemented in the future.)
      • No use of a separate Base64CertData table in conjuction with NoConflictCertificateData. (Would require another NoConflictBase64CertData.)
      • Billion certificate scale NoConflictCertificateData CRUD logic for scenarios where more than one entry per issuerDn,serialNumber exists.
      • Retrieving more data from the db and iterating over it will always be slower than a single query.
      • Retrieving a single row and "iterating" over it should still be of similar effort as the single query case.
      • No hybrid or switching of CRUD logic.
        • A CA always uses a single table for it's leaf certificates.
        • The CA certificates stays in regular CertificateData.
        • Could be tricky to implement in the future and keep performance for existing uses. (Concurrent async db reads would probably be required or complex SQL.)
      • Access rules for inserting a limited entry should also require that the client is allowed to issue certificates from the CA using the cetificateProfileId
      • The NoConflictCertificateData might need a new column in a future version of EJBCA with a random "ticket" associated with End Entity status NEW to detect double-dipping issuance in an active-active async environment.)
      • Don't allow creation of limited entries during revocation with a certificateProfileId that do not allow the requested CA.

      Required changes to EJBCA and related work:

      • New DB table 
      • New CRUD SSB (this is probably the hardest part if this ticket)
      • CA config changes + Admin GUI mods
      • Changes in certificate lookup from PublishQueueServiceWorker (to optionally use new CRUD) and should work with "limit" entries.
        • Problem: PublisherQueueData currenlty only has fingerprint and no IssuerDN which makes it hard to know which table to do this lookup.
          • Alt1: Define new “PublisherConst.PUBLISH_TYPE_CERT2"
          • Alt2: Start using PublisherQueueData.fingerprint="NoConflictCertificateData:fingerprint" for these entries
          • Alt3: New nullable column
      • Changes in CRL generation logic (to optionally use new CRUD) and should work with "limit" entries.
      • Modify EjbcaWS.revoceCert call (to optionally create a limited CertificateData entry with cpId and insert using CA configured CRUD)
      • EjbcaWS.revokeCert call as above, but also accept more meta data from client
      • Tests (especially manual tests of publishing)
      • Junit tests
      • System tests.
      • Performance testing.
      • Documentation

        Attachments

          Activity

            People

            • Assignee:
              mikek Mike Agrenius Kushner
              Reporter:
              mikek Mike Agrenius Kushner
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:

                Time Tracking

                Estimated:
                Original Estimate - 12 weeks
                12w
                Remaining:
                Remaining Estimate - 12 weeks
                12w
                Logged:
                Time Spent - Not Specified
                Not Specified