Two questions regarding "directory object" and "orders lists"

Issuance Tech
1

I'm reading the ACME RFC, I see some weird things. bear in mind I'm not a professional, just an inexperienced student. I'm also NOT looking for help, I'm just curious.

section 7.1.1. Directory

is there some real life use case where customization of "URLs for each ACME operation" is needed? I mean, this RFC is already reserving fields/items such as "newNonce", "newAccount", "termsOfService" etc., so why not make them mandatory hardcoded URLs and not have the "directory object" altogether?

section 7.1.2.1 Orders list

why is this a linked list? why not make it mandatory to send a complete list every time? is there some real life use case a server would return an incomplete list? why? something DoS, something rate limits?

thanks in advance. I will proceed reading the spec.

2

Using a Link header is optional. I'm guessing its for ACME clients that are handling large amounts of orders for some reason where it would perhaps take too much effort to handle it at once.

Note that Let's Encrypt does not even use this orders field in the account object.

With regard to the directory object: I guess it's just to have the specs flexible. Of course one can hardcode the URIs, but then someone would eventually complain about this hardcoding and request more flexibility.

For example, ssl.com uses this flexibility. Their directory at https://acme.ssl.com/sslcom-dv-ecc shows:

{
  "newNonce": "https://acme.ssl.com/ejbca/acme/sslcom-dv-ecc/newNonce",
  "newAccount": "https://acme.ssl.com/ejbca/acme/sslcom-dv-ecc/newAccount",
  "newOrder": "https://acme.ssl.com/ejbca/acme/sslcom-dv-ecc/newOrder",
  "revokeCert": "https://acme.ssl.com/ejbca/acme/sslcom-dv-ecc/revokeCert",
  "keyChange": "https://acme.ssl.com/ejbca/acme/sslcom-dv-ecc/keyChange",
  "meta": {
    "termsOfService": "https://legal.ssl.com/documents/SSLcom-Subscriber-Agreement-v1.4.pdf",
    "website": "https://www.ssl.com",
    "caaIdentities": [
      "ssl.com"
    ],
    "externalAccountRequired": false
  }
}

Notice the different paths used between those values and the directory. You'd need to ask SSL.com for why they're doing that :wink:

2 Likes