PR #96 boulder-incompatible change enforcement

[milux]

We could ignore this if sent (and that's what Boulder will do) but for Pebble we'd like to be more aggressive about pushing clients implementations in the right direction, so we treat this as a malformed request.

What seems to be a good idea on the first glimpse, as discussed in shred/acme4j#59, doesn't push clients "in the right direction", it enforces LE-/boulder-incompatible changes, which is rather horrible...
I suggest to silently ignore the KeyAuthorization field until live LE boulder instances properly support ACME v2 draft 10.

[cpu]

I added a flag in #102 that can be used to selectively enable/disable the strict enforcement of the keyAuthorization field. This will let existing code that worked with Pebble continue to work while also providing an easy way to check whether upcoming changes will break client code.

Generally speaking, Pebble is not intended to serve as a 1:1 model for checking compatibility with Boulder and Let's Encrypt's staging/production environments. If that's your goal I recommend you run a Boulder instance to test against.

The README says this too:

The goal is to emphasize client specification compatibility and to avoid "over-fitting" on Boulder and the Let's Encrypt production service.

In this case we made a choice to emphasize client specification compatibility and it broke clients that were over-fitting Boulder. I'm happy to add something like -strict to make this easier to navigate but the intention is always to make Pebble more aggressive than Boulder in rolling out protocol changes.

[milux]

Understood and agreed. Thank you! 👍

[cpu]

@milux Thanks for the feedback here and on ACME4J. I appreciate hearing from folks using Pebble.

#102 is merged so I'm going to close this issue now. Thanks!