I haven't tested this at all yet. But I'm wondering whether I can send both newkey and oldkey in the inner JWS and have it effectively be compatible with both drafts. Has anyone tried it? Does it throw an error today or does Boulder ignore fields it's not expecting (like clients are supposed to do).
If things are going to break, I'm trying to figure out how to time the updated release of my client. Do I just wait until the Production live date and have people testing against staging be broken after the change goes live there? Do I release a beta version with draft-13 support that people can opt into? What do people normally do in situations like this?
I've implemented that several months ago (when I saw the discussion about whether to change this) for Ansible's acme_account module, and it worked great for me so far. I guess I'll find out soon (on August 14th) whether this also works with the draft-13 version of Boulder, but I'm optimistic it will. And looking at the implementation, I think my optimism is correct
Nice. Just did a quick test myself against staging where I sent both newKey and oldKey in the inner JWS. It did not throw an error and appears to have completed the rollover successfully. So yay! Perhaps there was nothing to worry about.
If this continues through the draft-13 implementation, it seems like I can release an interim version of my client that includes both. Then once the draft-13 is live everywhere, release another version that removes the legacy field.
These are good questions and I'm interested in hearing the perspective of client developers. I definitely try to think about these things when planning the server side change.
I wrote the implementation intending that this would work. It looks like I missed testing this concrete case in the unit tests (doh!) I will fix that and update the API announcement. Thanks for asking!
I definitely try to think about these things when planning the server side change.
Out of curiosity: why not support both ways simultaneously, at least for some time (at least on production, I'd disable the old way pretty quickly on staging)? That would give client developers a bit more time to adjust their clients and get the new versions distributed.
I thought about this but there aren't very many clients that have implemented ACME v2 and key rollover. In practice in the production environment we get <30 successful ACME v2 key rollover requests in a month. With that in mind I wanted to move fairly aggressively on this change because there is a burden (both in code, configuration and in brains!) for having to support both.
If there's significant outcry from users and developers we could definitely revisit the timeline. Overall it's a fairly minor change and shouldn't require gnarly code changes.
