Uploaded image for project: 'EJBCA'
  1. EJBCA
  2. ECA-5873

Re-implement EFF ACME protocol support


    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: EJBCA 6.8.0
    • Fix Version/s: EJBCA 6.8.0
    • Component/s: None
    • Labels:
    • Epic Link:
    • Sprint:
      6.8.0 QA Sprint 2


      The initial implementation under ECA-4222 requires additional work to for even a PoC release.

      It has been decided during todays development meeting to

      • potentially exclude the ACME implementation from the 6.8.0 release entirely.
      • not make this part of the released RaMasterApi until the implementation is in a reliable state

      This ticket will aim at (if possible) to improving the quality sufficiently for at least a PoC release for EJBCA 6.8.0 by:

      • Ensure that we don't have that we need to be backwards compatible with
        • RaMasterApi bindings from calls that have not yet been properly vetted
        • database schema changes (this seems to be ok, since outsourced implemented just stored stuff in memory)
      • Use JEE6 and Java 7 that is our current baseline
        • JAX-RS 1.0 + Servlets 3.0.
        • Use Java 7 generics for type safety
        • ...but keep the soon to be future JEE7 in mind (JAX-RS 2.0, API for JSON Serialization)
      • Isolate dependencies that we might want to upgrade or replace
        • Convert input and output data from the API to Java POJOs that we can handle with type safety and write proper object oriented code with (ideally using JAX-B annotiated POJOs)
        • Try to use a single JSON library instead of 2 different (JSON Smart is a dependency Nimbus JOSE that we use for JWS, but we also have JSON Simple bundled now.)
      • Provide JUnit tests and workflow tests to run under the normal system test framework and continuous integration environment
      • Clearly document in the code from which section of the RFC draft it is based on to make comparison feasible
      • Ensure that the implementation has potential to adapt to the still evolving protocol
      • Improve style so other devs can read the code:
        • Follow our coding conventions and normal Java naming conventions
        • Remove useless boiler plate code that provides no valuable abstraction
        • Add comments that describe what is not clear in the code and remove comments that provide no information
      • Implement the API properly
        • Implement JWS signature validation! (The wrong client being able to issue a cert for a domain is worse, than being able to issue no certs at all.)
        • Perform other request data validations mandated by the standard.

      ...to allow integration testing of ACME clients with EJBCA in non-external-RA mode.

      https://tools.ietf.org/html/draft-ietf-acme-acme-01 has
      "DANGER: Do not implement this specification. It has a known signature reuse vulnerability. For details, see the following discussion: https://mailarchive.ietf.org/arch/msg/acme/F71iz6qq1o_QPVhJCV4dqWf-4Yc "
      which so draft-ietf-acme-acme-02 seems like a reasonable baseline for EJBCA support.



          Issue Links



              johan Johan Eklund
              johan Johan Eklund
              Verified by:
              Mike Agrenius Kushner
              0 Vote for this issue
              4 Start watching this issue