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

Re-implement EFF ACME protocol support

    Details

    • 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:
      None
    • Epic Link:
    • Sprint:
      6.8.0 QA Sprint 2

      Description

      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.

      https://tools.ietf.org/rfcdiff?url1=draft-ietf-acme-acme-02.txt&url2=draft-ietf-acme-acme-06.txt

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                johan Johan Eklund
                Reporter:
                johan Johan Eklund
                Verified by:
                Mike Agrenius Kushner
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: