ACMEv2: "orders" field missing in account info

[joernheissler]

trafficstars

When I POST an empty update to my account URL I get this:

{
    "id": 5337306,
    "key": {
        "kty": "RSA",
        "n": "<redacted>",
        "e": "AQAB"
    },
    "contact": [
        "mailto:<redacted>"
    ],
    "agreement": "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf",
    "initialIp": "<redacted>",
    "createdAt": "2018-01-05T01:29:21Z",
    "status": "valid"
}

There is no orders field as required by https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.html#rfc.section.7.1.2

[cpu]

We should implement this field - @jsha @rolandshoemaker ~I remember the question of pagination/truncation of the "orders" field came up before w.r.t this spec feature. What are your thoughts about that here? Should we expect to return all orders? all unexpired orders? The first n unexpired orders?~ I was remembering a point in the spec where the orders field was itself an array of URLs instead of a URL from which one can retrieve URLs.

[buschtoens]

https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-7.1.2

orders (required, string): A URL from which a list of orders submitted by this account can be fetched via a GET request, as described in Section 7.1.2.1.

https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-7.1.2.1

Each account object includes an "orders" URL from which a list of orders created by the account can be fetched via GET request. The result of the GET request MUST be a JSON object whose "orders" field is an array of URLs, each identifying an order belonging to the account. The server SHOULD include pending orders, and SHOULD NOT include orders that are invalid in the array of URLs. The server MAY return an incomplete list, along with a Link header with a "next" link relation indicating where further entries can be acquired.

  HTTP/1.1 200 OK
  Content-Type: application/json
  Link: <https://example.com/acme/acct/1/orders?cursor=2>, rel="next"

  {
    "orders": [
      "https://example.com/acme/acct/1/order/1",
      "https://example.com/acme/acct/1/order/2",
      /* 47 more URLs not shown for example brevity */
      "https://example.com/acme/acct/1/order/50"
    ]
  }

[buschtoens]

Considering that ACME v2 was scheduled to go live yesterday, is there currently a way to retrieve a list of pending orders?

I'm sure you're busy with getting boulder ready, in order to ship ACME v2 for Let's Encrypt, so please don't feel pressured. I just happened to trip over this again.

[cpu]

@buschtoens We still have not implemented the "orders" field on account objects and we're not considering this a required feature for the V2 launch. I expect it will be a little bit after the launch before we implement it. I recommend that your client maintain the IDs of orders it creates with the newOrder endpoint in the meantime.

The best way to watch for progress is to keep an eye on this issue, particularly when it gets assigned to a milestone for a sprint. Thanks for your patience!

[bkromhout]

@cpu, can we expect to see any movement on this anytime soon? The ACME spec draft appears to be quite close to its final form, pending the whole process of making it an actual RFC. While I agree the "orders" field is a convenience, it is still a required part of the spec, yet this has been sitting idle for months now.

[cpu]

@cpu, can we expect to see any movement on this anytime soon?

Unlikely. It's a non-trivial amount of work for a convenience and there is still substantial higher priority work to be done in other areas.

this has been sitting idle for months now.

@bkromhout PRs are welcome.

[mschristiansen]

Is there no alternative to tracking the order ids client side currently?

[jsha]

That's correct.

[colintoal]

It'd be swell if Boulder supported this. Pebble does. I've implemented a client to spec, and this is the last step I need to work around. I'm happy to help if I can.

[igor-nav]

I recommend that your client maintain the IDs of orders it creates with the newOrder endpoint in the meantime.

Edit: Took me a while to figure out where to get the order ID. It's in the "Location" header returned by the call to newOrder.

[cowwoc]

@jsha @aarongable @beautifulentropy Can one of you please pick up this issue? Per RFC 8555 this information is mandatory.

[beautifulentropy]

@jsha @aarongable @beautifulentropy Can one of you please pick up this issue? Per RFC 8555 this information is mandatory.

Hi @cowwoc,

Appreciate your focus on RFC compliance. Indeed, we sometimes vary from this RFC 8555, more divergences are documented here. Implementing this feature has not been a priority thus far, but we do keep public feedback in mind when deciding what to work on next. Thanks for your patience and understanding!

[sinback]

I work on an acme client at Akamai and we would really love this feature so that we can understand our account's status better, as well as to keep our open-orders footprint lower! It would help us do more traffic with LE before getting rate-limited, which we would all be happy about.

LE suggests in the Rate-Limiting page that if an ACME client builds up a lot of pending orders it knows it will never succeed on, it is encouraged to clear them out by manually attempting open orders' challenges, even if the client knows they will fail. Right now, we don't keep data about every single order and authorization associated with our account, and even though the RFC says Boulder should, Boulder doesn't either... given how the RFC is written, it seems to me like it should be a higher priority for us to get Boulder to be able to make these lists than our client.