Affects Version/s: EJBCA 6.8.0
Fix Version/s: EJBCA 6.8.0
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.
"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.