What will need to implement draft-acme-ip on boulder?

Feature Requests
5

Thanks for the summary @orangepizza, (and of course for your Pebble work!).

Not sure if this was rhetorical but Pebble only support is useful as a reference implementation for a new draft (rough consensus and running code!). It's already being used by down-stream ACME client implementors like Ansible.

I think this sort of planning/discussion would be best in a Boulder issue. We already have (a very lightly described) issue for this that could be a good place to consolidate the discussion: Boulder Issue 2706. @orangepizza Would you like to move some of your post to that issue?

The original issue calls out a few things that aren't captured in your list:

  • We'd need to update our CP and CPS.
  • Unlike Pebble there would need to be robust unit and integration tests (this might translate into needing to do some acme python module work as well).
  • We would want to restrict IP subject certificate lifetime to <90days.

That last point about certificate lifetime is itself a small project. The Henry Ford model of certificate lifetime (You can have any lifetime as long as it's 90 days...) has been a long-standing part of Boulder's design and there are likely a few places where we rely on this in performance sensitive request paths.

Supporting ACME-IP in Boulder and the production Let's Encrypt service is something we want to do but it's a major project that is likely to be scheduled behind some other larger projects with more pressing need. We talked internally and the Boulder team thinks that given the overall complexity of the project and the number of areas of Boulder it will impact we feel most comfortable implementing ACME-IP ourselves. I don't think we have the resources to coach an external contributor through this project end-to-end.

@roland had given some thought to this as well when working on the ACME-IP draft. I believe there may be some older discussion on the ACME WG mailing list about it. The tl;dr is that the work was put aside after there was limited interest within the IETF in using the reverse zones for CAA or anything related to security.

Thanks for opening this thread @orangepizza. While its unlikely to be something we can figure out in the short term I definitely think it's valuable to keep refining the plan to implement ACME-IP and would love to help keep that discussion moving in Implement draft-ietf-acme-ip · Issue #2706 · letsencrypt/boulder · GitHub

Thanks again!

4 Likes